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

From: Dmitry Gutov <[email-masked]>
Date: Tue, 31 Jan 2023 17:58:44 +0200

On 31/01/2023 14:14, Eli Zaretskii wrote:
>> Date: Mon, 30 Jan 2023 23:07:22 +0200
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>> 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.