On 2022-11-29 20:32, Bart Schaefer wrote:
I'm capturing both PRESSED and CLICKED, the former being a slow click in practice. I had the same idea tho, the mouse-up is dangling. What's puzzling is that I can't force the error. I can press and hold the button, wait for the program to end (so far mouse clicks always make a selection from a list and return) and then release the button and, again, maybe one time in 20 I'll get the bogey. I've tried variation on click speed but nothing makes it better or worse. You don't suppose it could be a mechanical issue with the mouse? You know how they sometimes get sticky and mouse clicks are poorly registered? I've had mice that tended to return two clicks when only one was made. A mechanically unclean release seems to confuse the computer.perhaps 'zcursesend' should take more care to clean up?I suspect that your program is taking action on mouse-down, so it really is up to you to also handle the following mouse-up.
There's no way for curses endwin() or by extension "zcurses end" to know that the extra characters were generated by the terminal or were typed by you (with the expectation that they'd go to the regular shell input).
Well, so far the 'timeout' is working 100%, still I myself would sorta build that in to 'zcurses end'. While in zcurses,it owns all inputs so on quitting the idea that some input would be 'forwarded' to the terminal seems strange. Dunno, maybe such a thing could be wanted but ... well, could it ever be wanted? As you say there are these 'generated by the terminal' ... but I don't know anything about such things. Seems to me the terminal receives input, not makes input but I suppose an xterm is itself a program that writes to hardware so ... But this is the only time I've ever seen ghost-writing to zle.
BTW you were right about ERR_EXIT, sheesh, it nukes the whole terminal. I had something like ERR_RETURN in mind but I guess we don't have that.