GNU bug report logs -
#43373
28.0.50; Regression: Unrecognized style region in mhtml-mode
Previous Next
To reply to this bug, email your comments to 43373 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43373
; Package
emacs
.
(Sun, 13 Sep 2020 11:33:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Simen Heggestøyl <simenheg <at> runbox.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 13 Sep 2020 11:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The following bug is a regression since 27.1 introduced on master by
commit eae028b9e2c23f84dbd130d49da65f9db1db932f (found by bisection).
To reproduce, open the attached file 'mhtml-test.html' from
'emacs -Q'. The region from position 516 to 558 (approximately the
"button {cursor: pointer; }" part) is not recognized as being part of
the style block, and doesn't receive the correct mode (HTML+CSS).
[mhtml-test.html (text/html, inline)]
[Message part 3 (text/plain, inline)]
-- Simen
Added tag(s) confirmed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 13 Sep 2020 13:38:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43373
; Package
emacs
.
(Wed, 27 Jan 2021 06:10:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 43373 <at> debbugs.gnu.org (full text, mbox):
Simen Heggestøyl <simenheg <at> runbox.com> writes:
> The following bug is a regression since 27.1 introduced on master by
> commit eae028b9e2c23f84dbd130d49da65f9db1db932f (found by bisection).
>
> To reproduce, open the attached file 'mhtml-test.html' from
> 'emacs -Q'. The region from position 516 to 558 (approximately the
> "button {cursor: pointer; }" part) is not recognized as being part of
> the style block, and doesn't receive the correct mode (HTML+CSS).
I was able to reproduce this in September, but I'm no longer able to (in
Emacs 28), so perhaps it has been fixed in the meantime? Do you still
see this problem?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 27 Jan 2021 06:10:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43373
; Package
emacs
.
(Wed, 27 Jan 2021 08:25:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 43373 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I was able to reproduce this in September, but I'm no longer able to (in
> Emacs 28), so perhaps it has been fixed in the meantime? Do you still
> see this problem?
Hi Lars.
Just checked this from master at 9d50d7a0c6, still seeing the same error
as before.
-- Simen
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 28 Jan 2021 02:55:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43373
; Package
emacs
.
(Thu, 28 Jan 2021 02:59:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 43373 <at> debbugs.gnu.org (full text, mbox):
Simen Heggestøyl <simenheg <at> runbox.com> writes:
> Just checked this from master at 9d50d7a0c6, still seeing the same error
> as before.
Sorry; I should have checked with emacs -Q -- with that I can indeed
reproduce the bug, so I started bisecting my .emacs to see why I
couldn't in my normal Emacs.
And it is, bizarrely enough, this:
./src/emacs --eval '(global-so-long-mode 1)' /tmp/mhtml-test.html
With global-so-long-mode switched on, mhtml-mode correctly switches to
"HTML+CSS" as soon as I move point into "button" part of the CSS
section!
Which is just bizarre, because that shouldn't be triggering at all in
this file (and isn't, as far as I can tell).
Before I start trying to find out what's going on here, because this is
just all to odd -- are you seeing the same?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43373
; Package
emacs
.
(Thu, 28 Jan 2021 07:27:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 43373 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Before I start trying to find out what's going on here, because this is
> just all to odd -- are you seeing the same?
Yup.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43373
; Package
emacs
.
(Fri, 29 Jan 2021 05:29:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 43373 <at> debbugs.gnu.org (full text, mbox):
Simen Heggestøyl <simenheg <at> runbox.com> writes:
>> Before I start trying to find out what's going on here, because this is
>> just all to odd -- are you seeing the same?
>
> Yup.
It appears that if I say
(defun so-long-detected-long-line-p () nil)
then the problem can be reproduced, but something in that function is
doing something to the buffer which makes font locking happen
correctly... I think it's probably the narrow-to-region things that
makes Emacs re-fontify the buffer at opportune moments, which somehow
makes the multi-mode thing trigger from a better context... or
something...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
This bug report was last modified 4 years and 136 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.