GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked
 locked narrowing.
Date: Fri, 03 Feb 2023 09:39:22 +0200

> Date: Fri, 03 Feb 2023 00:20:40 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> By definition, this cannot be unsafe for any buffer, except those in which 
> long_line_optimizations_p is set.  So the worst that could possibly happen 
> is that Emacs would hang in some buffers in which 
> long_line_optimizations_p is set, which is not a regression: Emacs 28 and 
> earlier would have hanged under the same conditions.

Given the fanfare we announced the solution to long-line problems, the
above is precisely the definition of "not safe" from my POV.

> > Then please do.  This is one of a small number of issues whose 
> > resolution delays the pretest ATM.  Which is why I pinged you several 
> > times over the last month about it.
> 
> I know.  Unfortunately (or perhaps fortunately?) my time to hack on Emacs 
> is limited.

I'm sorry I have to insist, but does this mean you will be able to fix
these documentation issues in less than a week?  I don't think I can
wait any longer than that.

TIA

Previous Next

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