GNU bug report logs -
#61514
30.0.50; sadistically long xml line hangs emacs
Previous Next
Reported by: "Mark A. Hershberger" <mah <at> everybody.org>
Date: Tue, 14 Feb 2023 21:05:02 UTC
Severity: normal
Found in version 30.0.50
Done: Gregory Heytings <gregory <at> heytings.org>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 61514 <at> debbugs.gnu.org (full text, mbox):
On Tue, 2023-02-14 at 22:05 +0000, Gregory Heytings wrote:
> You jump to a conclusion a bit too fast. It's not a bug in Emacs in
> general, it's a bug in nXML, and specifically in its fontification
> routines. Try the same recipe, but with fontification turned off:
>
> emacs -Q
> M-x global-font-lock-mode
> C-x C-f a.xml
The bug is not (only) in nXML.
If I run =emacs30 -Q= but alter the load path to use emacs28's nxml, it
still hangs when I try to load the file with the long line. (Yes, this
is a silly way to test if the bug is in nxml itself, but it was the
quickest I could come up with.)
In =emacs28 -Q=, when I try to load file, I see various errors, but it
still load the file and I can edit it.
Perhaps the bug is in fontification.
Perhaps the bug is in how emacs handles whatever errors it is
encountering when loading the file.
The point is that whether it is a bug in emacs "in general", in nXML,
or in glibc. The point is that there is a regression in how emacs
behaves when loading this file with long lines.
It "worked" better in Emacs28.
This bug report was last modified 2 years and 147 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.