bug#29159: 27.0.50; Hang in HTML/CSS code

bug#29159: 27.0.50; Hang in HTML/CSS code

[Lars Ingebrigtsen]

If I put the following into a file called foo.html:

<style>
@keyframes dropFlowParticles {
  0% { background-position: 0 0, 0 0, 30px 40px, 0 0, 10px 0; }
}
</style>

End then delete the 0%, and then start typing "top", then Emacs will
hang kinda hard.  A C-g will eventually break out and the "t" will be
inserted, but then Emacs hangs again.

Setting debug-on-quit doesn't give me a backtrace, so I'm not sure where
it's hanging.


In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-11-03 built on mouse
Repository revision: 620247ac205b80ceb142ee70500ab2c3ffa46fe2
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description:	Ubuntu 17.04


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

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

[Olaf Rogalsky]

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

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

[Alex]

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.

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

[Olaf Rogalsky]

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

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

[Eli Zaretskii]

> From: Olaf Rogalsky <olaf.rogalsky@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.

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

[Olaf Rogalsky]

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

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

[Eli Zaretskii]

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

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

[Alex]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Eli Zaretskii <eliz@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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: drag-secondary --]
[-- Type: text/x-diff, Size: 394 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 537 bytes --]


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.

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

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: Olaf Rogalsky <olaf.rogalsky@t-online.de>,  29150@debbugs.gnu.org, Stefan Monnier <monnier@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.

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

[Alex]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Eli Zaretskii <eliz@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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: secondary2 --]
[-- Type: text/x-diff, Size: 525 bytes --]

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

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

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: olaf.rogalsky@t-online.de,  29150@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.

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

[Olaf Rogalsky]

Eli Zaretskii writes:
>> From: Alex <agrambot@gmail.com>
>> Cc: Olaf Rogalsky <olaf.rogalsky@t-online.de>,  29150@debbugs.gnu.org, Stefan Monnier <monnier@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

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

[Eli Zaretskii]

> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
> Cc: Alex <agrambot@gmail.com>, 29150@debbugs.gnu.org, monnier@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.

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

[Olaf Rogalsky]

> 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

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

[Stefan Monnier]

> 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

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

[Stefan Kangas]

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

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

[Lars Ingebrigtsen]

Alex <agrambot@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@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#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

[Alex]

Olaf Rogalsky <olaf.rogalsky@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'?

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

[Alex]

Alex <agrambot@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?

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

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

[Alex]

Stefan Monnier <monnier@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.

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

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

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: Olaf Rogalsky <olaf.rogalsky@t-online.de>,  Eli Zaretskii <eliz@gnu.org>,  29150@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.

bug#29159: 27.0.50; Hang in HTML/CSS code

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

The bug is also present in Emacs 26.

It looks like `mhtml--extend-font-lock-region' and
`font-lock-extend-region-multiline' are squabbling about where to
leave `font-lock-beg'.

In this particular example, `mhtml--extend-font-lock-region' wants to
leave `font-lock-beg' at 40 while `font-lock-extend-region-multiline'
wants it at 39, resulting in an endless back and forth.

CC-ing Tom in case he has some insight into how it should be fixed.

-- Simen

[-- Attachment #2: Type: text/html, Size: 638 bytes --]

bug#29159: 27.0.50; Hang in HTML/CSS code

[Tom Tromey]

>>>>> "Simen" == Simen Heggestøyl <simenheg@gmail.com> writes:

Simen> CC-ing Tom in case he has some insight into how it should be fixed.

Stefan found another bug in mhtml--extend-font-lock-region, so I sort of
suspect it needs a rethink.

However, in this case, I wonder why font-lock-extend-region-multiline is
even needed.  What about removing it?  I don't remember why I put it in
there in the first place.

This seems to fix the problem for me.  Though I wonder if it is actually
needed for something.

Tom

diff --git a/lisp/textmodes/mhtml-mode.el b/lisp/textmodes/mhtml-mode.el
index 5854167750..bdb95887c1 100644
--- a/lisp/textmodes/mhtml-mode.el
+++ b/lisp/textmodes/mhtml-mode.el
@@ -367,7 +367,8 @@ mhtml-mode
               #'mhtml--submode-fontify-region)
   (setq-local font-lock-extend-region-functions
               '(mhtml--extend-font-lock-region
-                font-lock-extend-region-multiline))
+                ;; font-lock-extend-region-multiline
+                ))
 
   ;; Attach this to both pre- and post- hooks just in case it ever
   ;; changes a key binding that might be accessed from the menu bar.

bug#29159: 27.0.50; Hang in HTML/CSS code

[Stefan Monnier]

> In this particular example, `mhtml--extend-font-lock-region' wants to
> leave `font-lock-beg' at 40 while `font-lock-extend-region-multiline'
> wants it at 39, resulting in an endless back and forth.

Could you give some details?
Functions on font-lock-extend-region-functions should *never* shrink
a region (since that risks inf-looping, obviously).  After all, it's
called "...-extend-...", right?

So if font-lock-extend-region-multiline puts beg at 39, it's incorrect
for mhtml--extend-font-lock-region to move it back to 40.


        Stefan

bug#29159: 27.0.50; Hang in HTML/CSS code

[Simen Heggestøyl]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Could you give some details?
> Functions on font-lock-extend-region-functions should *never* shrink
> a region (since that risks inf-looping, obviously).  After all, it's
> called "...-extend-...", right?
>
> So if font-lock-extend-region-multiline puts beg at 39, it's incorrect
> for mhtml--extend-font-lock-region to move it back to 40.

`font-lock-beg' got set back to 40 from 39 at line 184 from the call to
`previous-single-property-change'.

-- Simen

bug#29159: 27.0.50; Hang in HTML/CSS code

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> So if font-lock-extend-region-multiline puts beg at 39, it's incorrect
Stefan> for mhtml--extend-font-lock-region to move it back to 40.

What I did is set it up to do the multiline extension at the end of
mhtml--extend-font-lock-region.  I think this should make it work correctly
now.

Tom

bug#29159: done

[Tom Tromey]

I've checked in a patch to fix this problem.

Tom