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

[Dmitry Gutov]

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.