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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 30 Jan 2023 20:56:15 +0200
> Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 30/01/2023 19:11, Eli Zaretskii wrote:
> >> Date: Mon, 30 Jan 2023 15:03:54 +0000
> >> From: Gregory Heytings<gregory@heytings.org>
> >> cc:56682@debbugs.gnu.org,monnier@iro.umontreal.ca
> >>
> >>> What exactly will that remove? only what's on the feature branch, or
> >>> also some stuff on the emacs-29 branch?
> >> The "locked narrowing" feature, IOW, the portions of editfns.c in which it
> >> is implemented, and its use around pre-command-hook, post-command-hook and
> >> fontification-functions.
> >>
> >>> And what are your reasons for removing this?  It is hard to tell whether
> >>> or not I agree without knowing to what I should agree 😉
> >>>
> >> The reason is that I'm now convinced that it is not a good solution to the
> >> problem of ill-behaving modes in the presence of long lines.
> > 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?
> 
> More than one, FTR.
> 
> I'm not 100% sure what Gregory's plan is, but note that a significant 
> part of the redisplay slowdowns wasn't caused by font-lock, and thus the 
> removal of locking will not regress those performance improvements.
> 
> And for those (potential?) cases where font-lock is a real problem for 
> performance, we could stop it from widening using an existing knob.

Yes, this is an old and known disagreement between us.  But this is my
decision to make, not anyone else's.