bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 31 Jan 2023 15:14:14 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> > So we are removing all the stuff that prevented font-lock from slowing 
> > down redisplay when long lines are in the buffer?  IOW, something which 
> > we have for several months, and which so far brought up only one 
> > complaint?  Frankly, this makes no sense to me, unless we delay the 
> > pretest for another half year or so.  It's too late for such changes.
> >
> > Or am I missing something?
> 
> I looked with a critical eye at the code I wrote, and concluded that the 
> cure is worse than the disease.
> 
> It's true that some slowdowns caused by font-locking are prevented by 
> locked narrowing, but:
> 
> 1. The slowdowns caused by font-locking were not the major cause of 
> slowdowns in buffers with long lines.  They were the "last step" to make 
> editing operations in such buffers as fast as possible, and my opinion now 
> is that that last step was a step too far.  Efficiency issues in font 
> locking routines are the responsibility of mode authors.  Efficiency 
> issues in the redisplay routines are the responsibility of Emacs, and have 
> been dealt with.
> 
> 2. Locked narrowing does not prevent all slowdowns caused by font-locking.
> 
> 3. Locked narrowing can create slowdowns (e.g. infinite loops) that do not 
> exist when it is not present.
> 
> 4. Mode authors who do care about efficiency will update their modes to 
> deal with problematic buffers, and do not need to be incited by locked 
> narrowing to do so.
> 
> 5. Mode authors who do not care about such problematic buffers will simply 
> replace calls to "(widen)" by "(narrowing-unlock 'fontification-functions) 
> (widen)" in their code, and the situation will not have improved.

I must admit that it's very strange to hear this from you.  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.

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.

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...