GNU bug report logs - #29150
26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Cc: 29150 <at> debbugs.gnu.org
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 <at> t-online.de>
> Cc: 29150 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.