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

[Gregory Heytings <gregory@heytings.org>]

>> Why do you think it's not useful?  It is meant to be used for example 
>> in a function that is called in fontification-functions to temporarily 
>> escape the narrowing set around fontification-functions, when its 
>> author has determined that it is safe to do that, like this:
>>
>> (without-narrowing
>>    :label long-line-optimizations-in-fontification-functions
>>    ... some code ...)
>
> I'm thinking about code that doesn't necessarily run only from 
> fontification-functions.  If the code is low-level enough, it is quite 
> possible that it will be called in many different contexts by many 
> different callers.  Think about stuff like forward-sexp, and imagine 
> some major mode where doing that needs for some reason to look far back 
> in the buffer, or start from the beginning of a line.  Functions like 
> that cannot know where they are called, and if they want to modify their 
> behavior depending on the caller's context, they cannot do it without 
> knowing the label.
>

They cannot do that themselves, indeed, but the idea is/was not to do that 
in some low-level code, but around some portions of code at a higher 
level, e.g. around a portion of a fontification function that would need 
for some reason to access the whole buffer (e.g. to check what the first 
few characters of the buffer or of the current line are).

If escaping such narrowings should be possible in some low-level code, it 
is not necessary or useful to return the label.  Instead another macro, 
say 'without-any-narrowings', should be added.  The reason is that 
narrowing locks can be nested, which means that using 'without-narrowing' 
with the label of the innermost such narrowing does not guarantee that the 
whole buffer will be accessible.

>
> From where I stand, the locked narrowing is there to prevent slowdown 
> due to Lisp programs that are either unaware of special long-line 
> handling, or are deliberately ignoring it.  It is IMO okay for a Lisp 
> program that is aware of the issue to adapt its behavior by widening the 
> buffer; if it does so indiscriminately or in a way that hurts 
> performance, we can consider that a bug and expect the developers to fix 
> it.
>

Yes, that is what the without-narrowing macro is for.

>> Don't worry, I don't feel accused at all.  I was only expressing that 
>> I'm reasoning against my intuition here.
>
> It is trivially correct that removing some code removes also the need to 
> discuss it.  This discussion would have not happened if we were to 
> decide to remove the narrowing in fontificiations and pre/post-command 
> hooks.
>

Just in case, so that you can study and try it, I created a 
scratch/remove-locked-narrowing branch, with four commits: commit 1 
deactivates the two places where it is used, commit 2 removes the core 
functions in which it is implemented, commit 3 removes the other functions 
used by the core functions, and commit 4 updates the documentation.

I also fixed another bug in the scratch/fix-locked-narrowing branch.

Again these commits pass make bootstrap and make check, with and without 
native-compilation.