bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xte


From: Eli Zaretskii
Subject: bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sat, 11 Nov 2017 11:15:50 +0200

> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
> Cc: 29150@debbugs.gnu.org
> Date: Mon, 06 Nov 2017 22:43:11 +0100
> 
> > Thanks.  Do you understand why read-key-sequence-vector works with
> > xt-mouse, while read-event doesn't?  If so, can you elaborate on that?
> Unlike read-key-sequence and read-key-sequence-vector, read-event does
> not use input-decode-map.

Using or not using input-decode-map is exactly one reason of subtle
inconsistencies between the results.  I understand why using it would
be TRT for xterm-mouse-mode, but I'm afraid the consequences of using
input-decode-map for all the other input kinds is understood well
enough for us to do this, certainly not on the release branch.

> If you are still not convinced, that read-key-sequence-vector is
> harmless, then please find a modified patch below.

Thanks, I installed that patch on the release branch.  Should we close
this bug now, or is there anything else to do with it?

Btw, it seems like "C-h k" is not really working for complex mouse
clicks even without xterm-mouse-mode.  For example, try this:

  C-h k C-mouse-3

This pops up a menu; select any item from that menu.  The expected
result is to get the description of the menu item you selected, but
instead you get the prompt for "following key, mouse click, or menu
item" anew.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]