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

Previous Next

Package: emacs;

Reported by: Alex <agrambot <at> gmail.com>

Date: Sun, 5 Nov 2017 07:43:02 UTC

Severity: normal

Tags: patch

Found in version 26.0.90

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29150 in the body.
You can then email your comments to 29150 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Sun, 05 Nov 2017 07:43:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alex <agrambot <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 05 Nov 2017 07:43:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 05 Nov 2017 01:42:02 -0600
I don't know how to reproduce this outside of `xterm-mouse-mode', but
this seems to be an issue with `input-decode-map' in TTY.

Examples (from emacs -Q -nw with `xterm-mouse-mode' enabled):

1. C-h k <mouse-1>

This will open the help buffer for the click, but also insert the
control sequence for the click.

This also happens when modifying the click with Alt xor Ctrl.

2. <M-mouse-1>

This will insert the click control sequence when releasing the button.

3. I'm not sure, but I wouldn't be surprised if Bug#29143 is also an
example of this. I don't know why it only happens in evil-mode, though.


I don't see anything on the `xterm-mouse-mode' side that would cause the
above since in `turn-on-xterm-mouse-tracking-on-terminal' "\e[<" (the
prefix of the control sequences inserted above) is added to
`input-decode-map', and its binding, `xterm-mouse--read-event-sequence',
isn't called whenever the sequence is inserted.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Sun, 05 Nov 2017 20:35:02 GMT) Full text and rfc822 format available.

Message #8 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
To: 29150 <at> debbugs.gnu.org
Subject: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 05 Nov 2017 21:34:30 +0100
Hi,

in case of a button down event, `describe-key' has some trickery to also
read the forthcoming up event. The following patch makes this trickery
work with xterm-mouse-mode.

I don't have write permission to the repositiory. I therefore would
appreciate it very much, if someone else could review und submit the
patch.

PS: It would be nice, if that person also can have a look at patch #29104

PSS: I don't think, that #29143 is related. Both, `Evil-mode' *and*
     `xterm-mouse-mode' fool around with the ?\e prefix in the
     `input-decode-map', but they obviously do it in an incompatible
     way.


diff --git a/lisp/help.el b/lisp/help.el
index bc8035db0e..247f060f24 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -753,7 +753,7 @@ help-read-key-sequence
                     (and (> (length key) 1)
                          (eventp (aref key 1))
                          (memq 'down (event-modifiers (aref key 1)))))
-                (read-event))))
+                (aref (read-key-sequence-vector nil) 0))))
       ;; Put yank-menu back as it was, if we changed it.
       (when saved-yank-menu
         (setq yank-menu (copy-sequence saved-yank-menu))

-- 
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 06 Nov 2017 16:00:02 GMT) Full text and rfc822 format available.

Message #11 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Cc: 29150 <at> debbugs.gnu.org
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 06 Nov 2017 17:59:50 +0200
> From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
> Date: Sun, 05 Nov 2017 21:34:30 +0100
> 
> in case of a button down event, `describe-key' has some trickery to also
> read the forthcoming up event. The following patch makes this trickery
> work with xterm-mouse-mode.

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?

Also, I take it that you assume there will be only one element in the
array returned by read-key-sequence-vector, is that right?  If so, how
sure are we that this will always be the case?  Because if the
assumption could be false, this change will have Emacs wait for some
other input, and the user might think that Emacs hanged.

Anyway, in general, I'm wary of such changes, which replace one API
for reading input by another, which works subtly differently.  We had
in the recent past several incidents where similar changes seemed to
work, only to reveal many moons later that some rarely-used but useful
functionality stopped working or became semi-broken.  So I think I'd
prefer a fix that is specific to xt-mouse (assuming that we can
reliably detect that the clicks come from xt-mouse), and leave the
other use cases alone.  If such a solution is possible and makes
sense, we could even install it on the release branch.

> PS: It would be nice, if that person also can have a look at patch #29104

It's in my queue, if no one else beats me to it.  And there, too, more
detailed description of what you saw and what led you to your proposed
solution might go a long way towards admitting the change sooner.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 06 Nov 2017 21:44:01 GMT) Full text and rfc822 format available.

Message #14 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29150 <at> debbugs.gnu.org
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 06 Nov 2017 22:43:11 +0100
Eli Zaretskii writes:

>> in case of a button down event, `describe-key' has some trickery to also
>> read the forthcoming up event. The following patch makes this trickery
>> work with xterm-mouse-mode.
>
> 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.  xterm-mouse-mode relies on input-decode-map to
convert special byte sequences (starting with "\e[") into proper mouse
events. read-event stops reading after the first character ("\e") of the
byte sequence -- the remaining charcters are then inserted into the
current buffer.

> Also, I take it that you assume there will be only one element in the
> array returned by read-key-sequence-vector, is that right?  If so, how
> sure are we that this will always be the case?  Because if the
> assumption could be false, this change will have Emacs wait for some
> other input, and the user might think that Emacs hanged.
Yes, that was my assumption. read-key-sequence-vector is called after a
mouse-down event was read.  If someone presses a prefix key before
releasing the mouse or if the up event is a prefix to some binding, then
strange things may happen.  I wasn't able to think of and construct a
case, in which, after the user releases the mouse button,
read-key-sequence-vector still tries to read additional characters. In
any case, \C-g will interrupt read-key-sequence-vector.  But see below.

> Anyway, in general, I'm wary of such changes, which replace one API
> for reading input by another, which works subtly differently.  We had
> in the recent past several incidents where similar changes seemed to
> work, only to reveal many moons later that some rarely-used but useful
> functionality stopped working or became semi-broken.  So I think I'd
> prefer a fix that is specific to xt-mouse (assuming that we can
> reliably detect that the clicks come from xt-mouse), and leave the
> other use cases alone.  If such a solution is possible and makes
> sense, we could even install it on the release branch.
If you are still not convinced, that read-key-sequence-vector is
harmless, then please find a modified patch below.  There I check, as
suggested, that the mouse-down event under consideration was generated
by xterm-mouse-mode.  This is quite easy to accomplish, because
xterm-mouse anyway remembers the last mouse-down event in a terminal
paramerter.

diff --git a/lisp/help.el b/lisp/help.el
index bc8035db0e..fbb9fc8cbe 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -717,7 +717,7 @@ help-read-key-sequence
         (cursor-in-echo-area t)
         saved-yank-menu)
     (unwind-protect
-        (let (key)
+        (let (key down-ev)
           ;; If yank-menu is empty, populate it temporarily, so that
           ;; "Select and Paste" menu can generate a complete event.
           (when (null (cdr yank-menu))
@@ -743,17 +743,21 @@ help-read-key-sequence
                 (let ((last-idx (1- (length key))))
                   (and (eventp (aref key last-idx))
                        (memq 'down (event-modifiers (aref key last-idx)))))
-                (or (and (eventp (aref key 0))
-                         (memq 'down (event-modifiers (aref key 0)))
+                (or (and (eventp (setq down-ev (aref key 0)))
+                         (memq 'down (event-modifiers down-ev))
                          ;; However, for the C-down-mouse-2 popup
                          ;; menu, there is no subsequent up-event.  In
                          ;; this case, the up-event is the next
                          ;; element in the supplied vector.
                          (= (length key) 1))
                     (and (> (length key) 1)
-                         (eventp (aref key 1))
-                         (memq 'down (event-modifiers (aref key 1)))))
-                (read-event))))
+                         (eventp (setq down-ev (aref key 1)))
+                         (memq 'down (event-modifiers down-ev))))
+                (if (and (terminal-parameter nil 'xterm-mouse-mode)
+                         (equal (terminal-parameter nil 'xterm-mouse-last-down)
+                                down-ev))
+                    (aref (read-key-sequence-vector nil) 0)
+                  (read-event)))))
       ;; Put yank-menu back as it was, if we changed it.
       (when saved-yank-menu
         (setq yank-menu (copy-sequence saved-yank-menu))

>> PS: It would be nice, if that person also can have a look at patch #29104
>
> It's in my queue, if no one else beats me to it.  And there, too, more
> detailed description of what you saw and what led you to your proposed
> solution might go a long way towards admitting the change sooner.
Thanks a lot.  I will comment on that patch in a separate email.

Olaf

-- 
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Wed, 08 Nov 2017 20:58:01 GMT) Full text and rfc822 format available.

Message #17 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29150 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Wed, 08 Nov 2017 14:57:45 -0600
Olaf Rogalsky <olaf.rogalsky <at> t-online.de> writes:

> Hi,

Hi,

Thanks for looking into this. It looks like the only issue remaining is
#2 (M-mouse-1).

> PSS: I don't think, that #29143 is related. Both, `Evil-mode' *and*
>      `xterm-mouse-mode' fool around with the ?\e prefix in the
>      `input-decode-map', but they obviously do it in an incompatible
>      way.

It's not that. I checked out evil-mode's code and found out that it uses
a modified ~6 year old version of `mouse-drag-track', which evidently
doesn't play too well with recent Emacs versions.

For example, try using the definitions of `mouse-drag-region' and
`mouse-drag-track' of Emacs 24 in Emacs 25/26. Then in
`xterm-mouse-mode', releasing `mouse-1' inserts the control sequence
into the current buffer (which is what Bug#29143 is, except in
evil-mode, the characters in the sequence are not all bound to
`self-insert-command').

This old code uses `read-event', which, as you mentioned in your other
reply, doesn't use `input-decode-map'. Replacing it with:

  (aref (read-key-sequence-vector nil) 0)

fixes Bug#29143.

Eli, Stefan, does it make sense that `read-event' doesn't take into
account `input-decode-map'? If so, then is there a better alternative to
the above workaround? Perhaps there could be a new optional argument to
`read-event'?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Wed, 08 Nov 2017 21:31:01 GMT) Full text and rfc822 format available.

Message #20 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29150 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Wed, 08 Nov 2017 15:30:15 -0600
Alex <agrambot <at> gmail.com> writes:

> This old code uses `read-event', which, as you mentioned in your other
> reply, doesn't use `input-decode-map'. Replacing it with:
>
>   (aref (read-key-sequence-vector nil) 0)
>
> fixes Bug#29143.
>
> Eli, Stefan, does it make sense that `read-event' doesn't take into
> account `input-decode-map'? If so, then is there a better alternative to
> the above workaround? Perhaps there could be a new optional argument to
> `read-event'?

Wait, isn't this just `read-key'? So instead of the above
aref/read-key-sequence-vector, it should just be `read-key'?

Perhaps the docstring of `input-decode-map' should mention `read-key' as
well?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Wed, 08 Nov 2017 22:13:01 GMT) Full text and rfc822 format available.

Message #23 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Alex <agrambot <at> gmail.com>
Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, 29150 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Wed, 08 Nov 2017 17:13:32 -0500
> Wait, isn't this just `read-key'? So instead of the above
> aref/read-key-sequence-vector, it should just be `read-key'?

Most likely, yes.

> Perhaps the docstring of `input-decode-map' should mention `read-key' as
> well?

I'm not sure why, or what it would say.  `read-key` is a reasonably good
replacement for `read-event`, but it's still pretty brittle.
The better solution is to not "read" anything and let the main loop do
it for you (which is why I changed mouse-drag-track to use
set-transient-map instead of mucking with `read-event` or `read-key`).

In my experience, most uses of `read-event` are (latent) bugs, so maybe
it's in read-event's docstring that we should say something.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Thu, 09 Nov 2017 06:27:01 GMT) Full text and rfc822 format available.

Message #26 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, 29150 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Thu, 09 Nov 2017 00:26:44 -0600
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> I'm not sure why, or what it would say.  `read-key` is a reasonably good
> replacement for `read-event`, but it's still pretty brittle.
> The better solution is to not "read" anything and let the main loop do
> it for you (which is why I changed mouse-drag-track to use
> set-transient-map instead of mucking with `read-event` or `read-key`).

Assuming that no one ports evil-mode's code or updates the code in
`mouse-drag-secondary' (there's already a FIXME for this there), is
using `read-key' inside of `track-mouse' an acceptable stopgap solution?
Is it brittle enough to not apply the change to emacs-26?

> In my experience, most uses of `read-event` are (latent) bugs, so maybe
> it's in read-event's docstring that we should say something.

That sounds like a good idea.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Thu, 09 Nov 2017 08:22:01 GMT) Full text and rfc822 format available.

Message #29 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alex <agrambot <at> gmail.com>
Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, 29150 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Thu, 09 Nov 2017 03:21:47 -0500
>> I'm not sure why, or what it would say.  `read-key` is a reasonably good
>> replacement for `read-event`, but it's still pretty brittle.
>> The better solution is to not "read" anything and let the main loop do
>> it for you (which is why I changed mouse-drag-track to use
>> set-transient-map instead of mucking with `read-event` or `read-key`).

> Assuming that no one ports evil-mode's code or updates the code in
> `mouse-drag-secondary' (there's already a FIXME for this there), is
> using `read-key' inside of `track-mouse' an acceptable stopgap solution?

I'm not sure I understand the question, but I think so, yes.

> Is it brittle enough to not apply the change to emacs-26?

I think in the help.el case, it would be a clear improvement.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Thu, 09 Nov 2017 15:48:02 GMT) Full text and rfc822 format available.

Message #32 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: olaf.rogalsky <at> t-online.de, 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Thu, 09 Nov 2017 17:47:15 +0200
> From: Alex <agrambot <at> gmail.com>
> Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>,  Eli Zaretskii <eliz <at> gnu.org>,  29150 <at> debbugs.gnu.org
> Date: Thu, 09 Nov 2017 00:26:44 -0600
> 
> Assuming that no one ports evil-mode's code or updates the code in
> `mouse-drag-secondary' (there's already a FIXME for this there), is
> using `read-key' inside of `track-mouse' an acceptable stopgap solution?

It could be, but I don't think we understand all the consequences of
this to be sure.

> Is it brittle enough to not apply the change to emacs-26?

Yes, it's too risky for the release branch.  With all due respect to
xterm-mouse, it's a niche feature, so putting the vast majority of
mouse users at risk on its behalf doesn't sound justified.

So I think we should put that on master and see what happens.

> > In my experience, most uses of `read-event` are (latent) bugs, so maybe
> > it's in read-event's docstring that we should say something.
> 
> That sounds like a good idea.

Patches to this latter effect are welcome on emacs-26.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Sat, 11 Nov 2017 09:17:01 GMT) Full text and rfc822 format available.

Message #35 received at 29150 <at> debbugs.gnu.org (full text, mbox):

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Sun, 12 Nov 2017 08:26:02 GMT) Full text and rfc822 format available.

Message #38 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, 29150 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 12 Nov 2017 02:25:22 -0600
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, I installed that patch on the release branch.

Should it use `read-key' instead? See:
https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00245.html

Perhaps the patch should be replaced on the master branch with one that
uses `read-key' in all cases?

> Should we close this bug now, or is there anything else to do with it?

The first issue is fixed, but not the second (`mouse-drag-secondary'
uses `read-event'). Here's a diff for the second:

[secondary.diff (text/x-diff, inline)]
diff --git a/lisp/mouse.el b/lisp/mouse.el
index 5eeee1ec52..c165e1b0d2 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1740,7 +1740,7 @@ mouse-drag-secondary
       (let (event end end-point)
 	(track-mouse
 	  (while (progn
-		   (setq event (read-event))
+		   (setq event (read-key))
 		   (or (mouse-movement-p event)
 		       (memq (car-safe event) '(switch-frame select-window))))
 
[Message part 3 (text/plain, inline)]
Stefan, the above is what I meant by "is using `read-key' inside of
`track-mouse' an acceptable stopgap solution?".

> 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.

This worked fine in Emacs 25.2, FWIW.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Sun, 12 Nov 2017 11:19:02 GMT) Full text and rfc822 format available.

Message #41 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: olaf.rogalsky <at> t-online.de, 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 12 Nov 2017 13:17:52 +0200
> From: Alex <agrambot <at> gmail.com>
> Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>,  29150 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Date: Sun, 12 Nov 2017 02:25:22 -0600
> 
> > Thanks, I installed that patch on the release branch.
> 
> Should it use `read-key' instead?

If that does TRT for xt-mouse, I'm okay with doing that.  But please
wait for Olaf to respond, it's his code after all.

> Perhaps the patch should be replaced on the master branch with one that
> uses `read-key' in all cases?

Why the rush?

> > Should we close this bug now, or is there anything else to do with it?
> 
> The first issue is fixed, but not the second (`mouse-drag-secondary'
> uses `read-event'). Here's a diff for the second:

If you want this on the release branch, it should be affect only
xt-mouse.  If you propose this for master, see above.

> > 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.
> 
> This worked fine in Emacs 25.2, FWIW.

Right, I will file a bug report for this regression.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Sun, 12 Nov 2017 16:31:01 GMT) Full text and rfc822 format available.

Message #44 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alex <agrambot <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29150 <at> debbugs.gnu.org,
 Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 12 Nov 2017 11:30:36 -0500
> diff --git a/lisp/mouse.el b/lisp/mouse.el
> index 5eeee1ec52..c165e1b0d2 100644
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -1740,7 +1740,7 @@ mouse-drag-secondary
>        (let (event end end-point)
>  	(track-mouse
>  	  (while (progn
> -		   (setq event (read-event))
> +		   (setq event (read-key))
>  		   (or (mouse-movement-p event)
>  		       (memq (car-safe event) '(switch-frame select-window))))
>
> Stefan, the above is what I meant by "is using `read-key' inside of
> `track-mouse' an acceptable stopgap solution?".

Yes, it's better than nothing.
But maybe this can go to `master` since it's not an urgent matter, AFAIK.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 13 Nov 2017 00:02:01 GMT) Full text and rfc822 format available.

Message #47 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: olaf.rogalsky <at> t-online.de, 29150 <at> debbugs.gnu.org
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 12 Nov 2017 18:00:57 -0600
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Perhaps the patch should be replaced on the master branch with one that
>> uses `read-key' in all cases?
>
> Why the rush?

I don't mean to rush anything, but I figured that I should mention it
before I forget about it.

>> > Should we close this bug now, or is there anything else to do with it?
>> 
>> The first issue is fixed, but not the second (`mouse-drag-secondary'
>> uses `read-event'). Here's a diff for the second:
>
> If you want this on the release branch, it should be affect only
> xt-mouse.  If you propose this for master, see above.

Do you mean that I shouldn't rush the `read-key' change for
`mouse-drag-secondary' in master, either?

Would applying the previous diff for master and the following for
emacs-26 be acceptable?

[secondary.diff (text/x-diff, inline)]
diff --git a/lisp/mouse.el b/lisp/mouse.el
index 5eeee1ec52..b9ff71402f 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1740,7 +1740,9 @@ mouse-drag-secondary
       (let (event end end-point)
 	(track-mouse
 	  (while (progn
-		   (setq event (read-event))
+		   (setq event (if (terminal-parameter nil 'xterm-mouse-mode)
+                                   (read-key)
+                                 (read-event)))
 		   (or (mouse-movement-p event)
 		       (memq (car-safe event) '(switch-frame select-window))))
 

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 13 Nov 2017 15:52:01 GMT) Full text and rfc822 format available.

Message #50 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: olaf.rogalsky <at> t-online.de, 29150 <at> debbugs.gnu.org
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 13 Nov 2017 17:51:23 +0200
> From: Alex <agrambot <at> gmail.com>
> Cc: olaf.rogalsky <at> t-online.de,  29150 <at> debbugs.gnu.org
> Date: Sun, 12 Nov 2017 18:00:57 -0600
> 
> >> Perhaps the patch should be replaced on the master branch with one that
> >> uses `read-key' in all cases?
> >
> > Why the rush?
> 
> I don't mean to rush anything, but I figured that I should mention it
> before I forget about it.

The thing is, I'm not yet sure read-key is TRT in this case.  We have
a lousy record in our changes of input processing code: almost every
change caused subtle bugs that took many moons to find and fix.  I
think we should recognize this vulnerability and behave more
cautiously.

> > If you want this on the release branch, it should be affect only
> > xt-mouse.  If you propose this for master, see above.
> 
> Do you mean that I shouldn't rush the `read-key' change for
> `mouse-drag-secondary' in master, either?

I'd like first to see how it fares on the release branch (and on
master), when it is limited to xt-mouse.

> Would applying the previous diff for master and the following for
> emacs-26 be acceptable?

Looks OK for the release branch (from which it will be merged to
master).  I'd prefer to wait with a more radical change even on
master.  Maybe put a FIXME comment there, to the effect that we should
try removing the condition at some point.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 13 Nov 2017 18:16:01 GMT) Full text and rfc822 format available.

Message #53 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, Alex <agrambot <at> gmail.com>
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 13 Nov 2017 19:14:24 +0100
Eli Zaretskii writes:
>> From: Alex <agrambot <at> gmail.com>
>> Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>,  29150 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
>> Date: Sun, 12 Nov 2017 02:25:22 -0600
>> 
>> > Thanks, I installed that patch on the release branch.
>> 
>> Should it use `read-key' instead?
>
> If that does TRT for xt-mouse, I'm okay with doing that.  But please
> wait for Olaf to respond, it's his code after all.
Yes, it does TRT. I wasn't aware of read-key and have a better
understanding of what read-key-event is doing. But using (read-key)
instead of (aref (read-event-vector nil) 0) seems to work equally well.

>> Perhaps the patch should be replaced on the master branch with one that
>> uses `read-key' in all cases?
>
> Why the rush?
I personally have no urgent desires.

>> > 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.
>> 
>> This worked fine in Emacs 25.2, FWIW.
Hmm interesting.  There are quite a few differences between 25.2 and now
in mouse.el.

-- 
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 13 Nov 2017 18:32:02 GMT) Full text and rfc822 format available.

Message #56 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
Cc: 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, agrambot <at> gmail.com
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 13 Nov 2017 20:31:23 +0200
> From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
> Cc: Alex <agrambot <at> gmail.com>, 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
> Date: Mon, 13 Nov 2017 19:14:24 +0100
> 
> >> >   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.
> >> 
> >> This worked fine in Emacs 25.2, FWIW.
> Hmm interesting.  There are quite a few differences between 25.2 and now
> in mouse.el.

I think the problem is in help.el, not in mouse.el.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 13 Nov 2017 19:11:01 GMT) Full text and rfc822 format available.

Message #59 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29150 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, agrambot <at> gmail.com
Subject: Re: bug#29150: Fwd: 26.0.90;
 Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Mon, 13 Nov 2017 20:09:58 +0100
> I think the problem is in help.el, not in mouse.el.
Oh yes, I meant help.el.

-- 
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 10 Aug 2020 16:26:01 GMT) Full text and rfc822 format available.

Message #62 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29150 <at> debbugs.gnu.org,
 Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, Alex <agrambot <at> gmail.com>
Subject: Re: bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in
 TTY (xterm-mouse-mode)
Date: Mon, 10 Aug 2020 09:25:24 -0700
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> diff --git a/lisp/mouse.el b/lisp/mouse.el
>> index 5eeee1ec52..c165e1b0d2 100644
>> --- a/lisp/mouse.el
>> +++ b/lisp/mouse.el
>> @@ -1740,7 +1740,7 @@ mouse-drag-secondary
>>        (let (event end end-point)
>>  	(track-mouse
>>  	  (while (progn
>> -		   (setq event (read-event))
>> +		   (setq event (read-key))
>>  		   (or (mouse-movement-p event)
>>  		       (memq (car-safe event) '(switch-frame select-window))))
>>
>> Stefan, the above is what I meant by "is using `read-key' inside of
>> `track-mouse' an acceptable stopgap solution?".
>
> Yes, it's better than nothing.
> But maybe this can go to `master` since it's not an urgent matter, AFAIK.

(That was almost three years ago.)

This patch was never installed.  Is it still relevant?

Best regards,
Stefan Kangas




Added tag(s) patch. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Thu, 01 Oct 2020 12:51:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29150; Package emacs. (Mon, 10 May 2021 12:15:02 GMT) Full text and rfc822 format available.

Message #67 received at 29150 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alex <agrambot <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29150 <at> debbugs.gnu.org,
 Olaf Rogalsky <olaf.rogalsky <at> t-online.de>,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#29150: 26.0.90; Input decoding is sometimes skipped in TTY
 (xterm-mouse-mode)
Date: Mon, 10 May 2021 14:14:14 +0200
Alex <agrambot <at> gmail.com> writes:

>  	(track-mouse
>  	  (while (progn
> -		   (setq event (read-event))
> +		   (setq event (read-key))
>  		   (or (mouse-movement-p event)

It looks like this change was made as part of

commit c62ced5b4d48e5aeef9c3b4d9c6f1b687a9aaa79
Author:     Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
AuthorDate: Sun Dec 17 11:19:19 2017 +0100

a month after this discussion, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 29150 <at> debbugs.gnu.org and Alex <agrambot <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 10 May 2021 12:15:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 08 Jun 2021 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 293 days ago.

Previous Next


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