On Mon Sep 8, 2025 at 02:53:17 GMT +03, Thomas Dickey wrote: > On Sun, Sep 07, 2025 at 01:30:32AM +0300, Robin Haberkorn via Bug reports for > ncurses, the GNU implementation of curses wrote: >> Hello! >> >> I am trying to debug subtle mouse-related bugs in one of my projects >> (SciTECO). I wrote a small test program (see attachment). To my surprise for >> every KEY_MOUSE you actually may have to call getmouse() repeatedly - this >> was not obvious from curs_mouse(3X). In XTerm 400 (TERM=xterm-256color) and >> simpleterm (st) the middle mouse button click generates a BUTTON2_RELEASED, > > perhaps it's a bug in simpleterm > It's also in Xterm, where I confirmed that the terminal sends the press and released events in the correct order when in SGR mode. So it very much doesn't look like a st-issue.
>> Can you reproduce these issues? > > with xterm, I see press and release events in ncurses, > but with st, I see that some press events are lost With xterm the events are always in the correct order on your system? >> I have another problem that in my app horizontal scrolls generate unexpected >> BUTTON3_PRESSED events in XTerm and GNOME Console, but I cannot yet >> reproduce this with my test program. > > ncurses only knows about 5 buttons (a horizontal scroll probably sends > something like buttons 6 and 7) > Yes, see my last mail on this thread. If the terminal sends buttons 6 and 7 we shouldn't report it as BUTTON3_PRESSED, though. This issue is reproducible with Xterm and my mouse-test.c program. Try to left scroll as the very first thing. You should see the bogus press event. I do have a working patch for this one. Any hints on how to work around it in existing ncurses versions would be appreciated. In SciTECO I reset the mousemask() before any wgetch() which apparently resets the internal button states. Therefore left scrolling will issue right button press events repeatedly, which is very annoying. Okay, I can at least prevent the mousemask() resetting, which will make the issue less annoying. For the middle button problem described above I do have a workaround (ignore PRESSED and synthesize it when processing RELEASED), but I would like to find a real solution and submit a patch as well. I suspect that the MEVENT queue handling could be buggy. But it will require further investigation. btw. perhaps we should push KEY_MOUSE for every mouse event or is the current behavior that one KEY_MOUSE could mean multiple mouse events really the desired behavior? Best regards, Robin -- @ii._._.*.._+__.+_+.+...+.+.++..+*+.+._.+...*_*.*.__+__._._.++..+_*.++__+__ .+_..*...+.+_+__.+._.+...*_+_+__._ ...*_ +.+._.+.._+*+_+__._._ .+_..+.+***_ . *_+_+__.+.*.++..+_+.*.__+_ _.+...*_*_+__.++*.+...++..+* +.+.._+__._+_.+.. .++..+*_.*...+*+.+.*_ +*+i2^rj.u#__%uu#_.%uu#_+%uu#_*!+!0a"t1010^t^c^c'0a^# 1010"=d'0a-100000"=d'0auuqq*100+q[_^euu]uq-rq:^/100@oo,+,+,+oqq^t0uq@o*+*!!
signature.asc
Description: PGP signature
