Hi, thanks for your clarifications. On Mon, Oct 08, 2018 at 02:45:28AM +0200, Přemysl Janouch <[email protected]> wrote: > Buttons forward and backward. These seem to be 9 and 8 in X11, or
Not quite, buttons 8 and 9 are simply buttons 8 and 0 on the input device. They have no special meaning, other than that. > >> - 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? https://invisible-island.net/xterm/ctlseqs/ctlseqs.html > Indeed it's hard to find anything, but it's common > https://unix.stackexchange.com/q/20550 It's common, but neither a standard nor do all mice implement this, nor does X11 implement this. > 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. His mouse, yes. It's common. but there are also many mice who have "normal" buttons 6 and 7. > Let me change the question: why is it good to eat ButtonRelease for > unknown buttons as if they were the scroll wheel? I don't know, why do you think its a good thing in the first place? It's not how I would have designed it. > 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. Again, these are simply button events. There is no way for urxvt to know that some mouse maps these to another scroll wheel, and AFAIC there is no standard for this behaviour whatsoever. Lacking that, it would be best to treat all these buttons as buttons, then apps can decide how they want to react. > I don't think I'm asking for much. :) It's not quite clear what you are asking for though, exactly. The extra buttons are reported, and you can attach both mouse wheel and normal button clicks to it in a terminal app. You can't drag with them, because you don't have reliable release events, but that doesn't impede the usage for botht he scroll wheel and fwd/back buttons. > > 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. For most terminals, you can query their type and versions, which gives you this information and more, namely what tghe command sequences mean, which is not something you can find out by a terminal merely telling you which sequences it supports. Greetings, -- 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
