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

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Olaf Rogalsky-2
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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Eli Zaretskii
> From: Olaf Rogalsky <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Olaf Rogalsky-2

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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Alex-2
In reply to this post by Olaf Rogalsky-2
Olaf Rogalsky <[hidden email]> 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'?



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Alex-2
Alex <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Stefan Monnier
> 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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Alex-2
Stefan Monnier <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Stefan Monnier
>> 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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Eli Zaretskii
In reply to this post by Alex-2
> From: Alex <[hidden email]>
> Cc: Olaf Rogalsky <[hidden email]>,  Eli Zaretskii <[hidden email]>,  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Eli Zaretskii
In reply to this post by Olaf Rogalsky-2
> From: Olaf Rogalsky <[hidden email]>
> Cc: [hidden email]
> 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 | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Alex-2
Eli Zaretskii <[hidden email]> 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:


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

> 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.
Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: Olaf Rogalsky <[hidden email]>,  [hidden email], Stefan Monnier <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Stefan Monnier
In reply to this post by Alex-2
> 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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Alex-2
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> 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?


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))))
 
Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Eli Zaretskii
> From: Alex <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Olaf Rogalsky-2
In reply to this post by Eli Zaretskii

Eli Zaretskii writes:

>> From: Alex <[hidden email]>
>> Cc: Olaf Rogalsky <[hidden email]>,  [hidden email], Stefan Monnier <[hidden email]>
>> 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



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Eli Zaretskii
> From: Olaf Rogalsky <[hidden email]>
> Cc: Alex <[hidden email]>, [hidden email], [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

Olaf Rogalsky-2

> 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