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

[Dmitry Gutov]

On 31/01/2023 14:14, Eli Zaretskii wrote:
> > Date: Mon, 30 Jan 2023 23:07:22 +0200
> > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > With the previous change that Gregory had made (different limits for
> > different features, i.e. font-lock uses much wider narrowing bounds
> > which are also customizable) I don't have that much of a horse in that
> > race anymore.
>
> Which change is that?  I don't think I follow.

The addition of long-line-locked-narrowing-region-size, I think, 
separated the narrowing radius for font-lock from narrowing for the 
improvement of other display stuff. I could be wrong there, though.

> > Also note that previously, I'd never have suggested that redisplay code
> > changes the value of font-lock-dont-widen.
>
> Hmm... not sure how is that variable related to this particular
> thread.  Please elaborate.

If we drop the locking feature, the display engine could still apply 
narrowing around fontification functions (and hooks, and etc). And 
perhaps bind font-lock-down-widen to t. Or add a new variable, like 
Stefan suggested -- that would be tidier.

That would still not protect us from misbehaving modes, but modes that 
absolutely cannot work within a narrowing are a problem anyway.

And for the rest, we have an existing convention (discussed at length 
and rubber-stamped by the previous maintainer back then) that major 
modes shouldn't call 'widen' in font-lock-keywords. Nor in indentation 
code. That was part of the convention which made js-mode, python-mode, 
etc, work better with multil-major-mode packages, and it did.