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?
> 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)?
> - xterm: DEC 1000, 1006:
> ^[[<3;1;1M^[[<3;1;1M^[[<3;1;1M^[[<3;1;1M
This is quite correct, per the spec.
> - 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.
> 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.
> 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.
> 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.
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
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
