GNU bug report logs - #61514
30.0.50; sadistically long xml line hangs emacs

Previous Next

Package: emacs;

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 #50 received at 61514 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Wed, 15 Feb 2023 16:17:24 +0200
> Cc: "Mark A. Hershberger" <mah <at> everybody.org>, 61514 <at> debbugs.gnu.org
> Date: Wed, 15 Feb 2023 13:58:37 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> 
> 
> >
> > It sounds like the bug lies somewhere in the intersection of nXML and 
> > the new long line fontification handling in Emacs 29 (with narrowing, 
> > perhaps)?
> 
> Yes, it's an example in which the cure of narrowing around 
> fontification-functions could be considered worse than the disease.  In 
> this particular case however, the fontification routines already failed to 
> do their job in Emacs 28 (and 24, 25, 26 and 27): after opening this file, 
> errors are displayed in the echo area, and the buffer remains unfontified.

If fontification-functions failed regardless of the restriction, then
perhaps fixing them so that they don't fail will also solve the
greater problem?

Btw, how does the narrowing make the matters worse, exactly? what is
the mechanism of worsening the situation in this case?




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.