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

[Gregory Heytings]

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