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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 09 Feb 2023 20:47:11 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org
> 
> > We make a point of documenting these labeled narrowings in great detail, 
> > including the labels and their effects.  It makes no sense to describe 
> > them and not let programs adapt their behaviors to these situations. 
> > Without access to the label, the without-narrowing macro is not useful, 
> > so why provide such a macro at all if we really don't want Lisp programs 
> > to use it?
> 
> 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.

> IMO, if it becomes possible to escape the narrowing programmatically (IOW, 
> without even checking where and why the narrowing has been set), the 
> exercise becomes even more pointless.

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.

> (Also, in that case it seems to me that there is no reason anymore
> to label these narrowings: their label serves no real purpose.)

I think the label allows different methods of behavior adaptation.  No
one said that being called from fontification-functions calls for the
same behavior adaptation as being called from, say, post-command-hook.

> 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.