GNU bug report logs - #29159
27.0.50; Hang in HTML/CSS code

Previous Next

Package: emacs;

Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>

Date: Sun, 5 Nov 2017 17:41:02 UTC

Severity: normal

Found in version 27.0.50

Done: Tom Tromey <tom <at> tromey.com>

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 29159 in the body.
You can then email your comments to 29159 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#29159; Package emacs. (Sun, 05 Nov 2017 17:41:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lars Ingebrigtsen <larsi <at> gnus.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 05 Nov 2017 17:41:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Hang in HTML/CSS code
Date: Sun, 05 Nov 2017 18:39:29 +0100
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





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

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

From: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>
To: 29159 <at> debbugs.gnu.org
Subject: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Date: Sun, 05 Nov 2017 20:53:08 +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#29159; Package emacs. (Sun, 05 Nov 2017 21:57:01 GMT) Full text and rfc822 format available.

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

From: Simen Heggestøyl <simenheg <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Tom Tromey <tom <at> tromey.com>, 29159 <at> debbugs.gnu.org
Subject: Re: bug#29159: 27.0.50; Hang in HTML/CSS code
Date: Sun, 05 Nov 2017 22:55:59 +0100
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

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

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

From: Tom Tromey <tom <at> tromey.com>
To: Simen Heggestøyl <simenheg <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Tom Tromey <tom <at> tromey.com>,
 29159 <at> debbugs.gnu.org
Subject: Re: bug#29159: 27.0.50; Hang in HTML/CSS code
Date: Sun, 12 Nov 2017 11:50:05 -0700
>>>>> "Simen" == Simen Heggestøyl <simenheg <at> 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.




Reply sent to Tom Tromey <tom <at> tromey.com>:
You have taken responsibility. (Sat, 25 Nov 2017 20:50:02 GMT) Full text and rfc822 format available.

Notification sent to Lars Ingebrigtsen <larsi <at> gnus.org>:
bug acknowledged by developer. (Sat, 25 Nov 2017 20:50:02 GMT) Full text and rfc822 format available.

Message #19 received at 29159-done <at> debbugs.gnu.org (full text, mbox):

From: Tom Tromey <tom <at> tromey.com>
To: 29159-done <at> debbugs.gnu.org
Subject: done
Date: Sat, 25 Nov 2017 13:49:16 -0700
I've checked in a patch to fix this problem.

Tom




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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Simen Heggestøyl <simenheg <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Tom Tromey <tom <at> tromey.com>,
 29159 <at> debbugs.gnu.org
Subject: Re: bug#29159: 27.0.50; Hang in HTML/CSS code
Date: Sat, 25 Nov 2017 21:17:20 -0500
> 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




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

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

From: Simen Heggestøyl <simenheg <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: larsi <at> gnus.org, tom <at> tromey.com, 29159 <at> debbugs.gnu.org
Subject: Re: bug#29159: 27.0.50; Hang in HTML/CSS code
Date: Sun, 26 Nov 2017 15:52:38 +0100
Stefan Monnier <monnier <at> 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




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

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

From: Tom Tromey <tom <at> tromey.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Tom Tromey <tom <at> tromey.com>,
 Simen Heggestøyl <simenheg <at> gmail.com>, 29159 <at> debbugs.gnu.org
Subject: Re: bug#29159: 27.0.50; Hang in HTML/CSS code
Date: Sun, 26 Nov 2017 10:36:02 -0700
>>>>> "Stefan" == Stefan Monnier <monnier <at> 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 archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 25 Dec 2017 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 117 days ago.

Previous Next


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