On Sun Sep 7, 2025 at 01:30:32 GMT +03, Robin Haberkorn wrote: > 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.
Looking through the source code, I believe that this could be a bug in handle_wheel(). The left scroll generates e.g. `\e[<66;57;18M\e[<66;57;18m` in SGR mode, which is what Xterm uses. I confirmed with `tput XM 1`. 66&3 == 2, which will just be reported as a BUTTON3_PRESSED (cf. lib_mouse.c:987). The right scroll is 67, which will be reported as REPORT_MOUSE_POSITION. This is consistent with my observations. It seems that we need to check for "wheel" in `case 2` as well and return REPORT_MOUSE_POSITION. Or can we report buttons > 5 via bstate? At least we don't have BUTTON[67]_PRESSED macros etc. But it's hard to believe this went unnoticed considering that it's XTerm's behavior. And why don't I see these events in my test program? Is it possible that it uses a different mouse mode, e.g. 1005? XM is defined, though on xterm-256color. -- @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
