On 08/10/18 00:45, Marc Lehmann wrote: > On Sun, Oct 07, 2018 at 05:08:25PM +0200, Přemysl Janouch <[email protected]> > wrote: >> first of all, http://software.schmorp.de/pkg/rxvt-unicode.html links to >> http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.html which seems to be > Hi, thanks for bringing this to our attention, although the only link with > that target I can find is the FAQ link, which isn't outdated. Is this what > you meant?
I meant that the FAQ /target/ seems to be outdated since it's missing information that I find in newer man 7 rxvt, namely the 1015 mode. >> following are results from me clicking the fwd. mouse button, followed > Which button numbers are these? From your description, I would assume you > mean buttons 8 and 9 (the ones you call browser backwards/forward), but > from the output, it seems this is the vertical scroll wheel (which are > typically mapped to buttons 4 and 5)? Buttons forward and backward. These seem to be 9 and 8 in X11, or somewhere else in the Linux input stack. Note that my particular mouse doesn't even have buttons 7 and 6. Also look at the numbers again, there's a difference of four, since the wheel doesn't simply add 64: ^[[32;1;1M^[[34;1;1M^[[33;1;1M^[[96;1;1M^[[97;1;1M^[[100;1;1M^[[101;1;1M Left, right, middle, up, down, backward, forward. >> - xterm: DEC 1000, 1006: >> ^[[<3;1;1M^[[<3;1;1M^[[<3;1;1M^[[<3;1;1M > This is quite correct, per the spec. Can you tell me which specification? Under 1000 w/o extensions, it's release, release, release, release for two button clicks. Under 1006, it's 4 presses of a release code, though maybe it's also interpretable as button 4. Hm. In any case, it's not useful to the application if it wants to support extra buttons. (And not your issue.) >> - rxvt-unicode: DEC 1000, 1015: >> ^[[101;1;1M^[[100;1;1M > This seems to be mode 1015, not 1000. Mode 1000 should mostly be > compatible with suckless terminal (buttons > 3 are reported as button > number + 64), within the confines of the protocol. I was trying to say that I typed in echo $'\[[?1000h\[[?1015h'. >> Given that the general mouse button sequence in X11 seems to be: > Do you have a source for this? I am not aware of any official or even > semi-official assigment for buttons 6+, and even if there is one, real > world mice do not typically implement any common standard. Indeed it's hard to find anything, but it's common https://unix.stackexchange.com/q/20550 T. Dickey has also just confirmed to me that he never thought to push the scroll wheel left/right and it does really send 6/7 for him. Real world mice implement the USB HID specification, which doesn't help me without further research. Let me change the question: why is it good to eat ButtonRelease for unknown buttons as if they were the scroll wheel? It's this one change that would make urxvt's behaviour make more sense. I assumed that the wheel doesn't produce the release sequence since it can't be actually depressed in its vertical direction. Correct me if I'm wrong. I don't think I'm asking for much. :) >> it should be safe to treat 8 and 9 as clickable buttons, and perhaps 6 >> and 7 as well, though I don't have such a mouse and can't tell you >> whether X.org may produce a ButtonRelease event with a different timestamp. > xorg can and will report different timestamps for these buttons when a > mouse has these buttons. > > The deeper problem is that the xterm family protocols do not really > support mouse down events (e.g. when you press multiple buttons), so > this information is generally lost, and you cannot extract timestamp > information for these buttons, i.e. even with suckless terminal, you > cannot know when a button press stops, so you have practically have to > model all buttons > 3 as prsss/release events anyway, which is easily > possible with most terminals (specifically, urxvt and suckless). > >> Thus, rxvt-unicode should, given its preferred way of letting the >> application know that a mouse button has been depressed, follow its 101 >> and 100 sequences with ^[[35;1;1M upon ButtonRelease. > The problem is of course what the semantics should be, since these buttons > don't have well-defined behaviour and are rather outside the scope of the > mouse tracking protocol. Which is why I feel like nothing's going to break more than it is when stuff is "accidentally" unified or fixed. >> I've already mailed Dickey, maybe we can fix this. > I would welcome a new protocol which could iron out these issues once and > for all. So far, this area has suffered from every side acting on their > own and cheweing out broken-by-design protocols (a good example is xterms > utf-8-based protocol). > > I would happily offer this mailinglist as a place for all parties (ideally, > vte and other terminal's authors as well) to discuss and design a "final" > (for the time being) protocol. I guess a new protocol is a rather big undertaking for how fragmented the area is. Though from my application-side memories, the worst thing is that you can't even ask terminals about the specific protocols that they support, AFAIK. Just having such a mechanism would be awesome. > OTOH, given the assign you posted for mouse buttons, the current protocols > should still be adequate for close to 100% of all applications, with the > possible exception of xterm which doesn't report these extra buttons at > all, at least not in the examples your provided. > > Greetings, > Marc It seems that xterm has some issues with its Xt heritage, so it's not going to be as easy there, at least to fix it properly. But we'll see. Cheers, Přemysl Janouch _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
