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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.
Date: Wed, 01 Feb 2023 22:42:56 +0000

>
> I must admit that it's very strange to hear this from you.
>

When I erred, I have no problems whatsoever to admit that I erred.

>
> Those very opinions were voiced by several other people over the last 
> year, and you always disagreed with these very arguments in the 
> strongest terms, citing various use cases and data points, with several 
> relevant files and modes.  I wonder what have happened that you now see 
> in the code what you didn't see then, even when others told you they saw 
> it.
>

I don't think it's useful to start a discussion about what I said and 
meant to say, but FTR I do not agree with the above.  The only thing I 
strongly disagreed with is Dmitry's claim that the existing mechanisms are 
sufficient to limit the damage of ill-behaving modes.  For the rest, I 
tried to find the best compromise to handle buffers with long lines as 
well as possible.  As we all know, determining where to place the cursor 
is hard.  I did believe that adding a forced narrowing would be helpful, 
and in some cases it is, but in other cases it isn't, and all in all I now 
consider that Emacs would be in a better shape without that mechanism. 
In particular, the fifth point is the result of the (recent) addition of a 
mechanism to unlock a locked narrowing, which makes the exercise almost 
pointless.

>
> Anyway, after thinking about this, I cannot agree to removing what we 
> now have on emacs-29.  It's too late for that, and I'm not prepared to 
> delay the pretest for any significant time.  So we will go into the 
> pretest with what we have, and decide what to do with it in Emacs 29.2 
> and 30.1 according to how the chips will fall.
>

Okay, if that's your decision.  IMO just going back to what the code did 
earlier is (very) safe, but I cannot do that without your approval.

>
> I guess by suggesting to remove the code you were also telling me that 
> you won't be fixing those documentation issues, which you promised to 
> work on a month ago?  If so, I guess this is one more buck that stops 
> with me...
>

Even if I think it's not TRT to do, I can still do that.

Previous Next

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