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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 09 Feb 2023 16:11:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: akrl@sdf.org, monnier@iro.umontreal.ca, 56682@debbugs.gnu.org
> 
> >> (save-restriction (widen) (buffer-narrowed-p))
> >
> > We should add it and document it, but I'm surprised that there's no 
> > easier way.  One problem with the above is that it could cause a more 
> > thorough redisplay because it fiddles with buffer restrictions.
> >
> 
> If necessary, a specific function which does not widen could be added to 
> do that, using narrowing_lock_peek_tag:
> 
> DEFUN ("...", ...) (void)
> {
>    if (NILP (narrowing_lock_peek_tag (Fcurrent_buffer ())))
>      return Qnil;
>    else
>      return Qt;
> }

I don't see how we can get away without doing something like that.
And I think it should return the tag itself, not just a boolean flag.

> > Also, this doesn't return the label itself.
> >
> 
> Indeed, but returning the label would defeat the purpose of the tool.  If 
> a program can by itself determine that it is in a labeled narrowing and 
> get its label, it can escape that narrowing without much ado.

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?  I don't want to assume malice on behalf
of Lisp programs, I want to give well-meaning programs reasonable
means to adapt their behaviors to these narrowings.  If and when we
see these facilities abused, we can take whatever actions are
necessary at that time.  But leaving legitimate programs limited
because we fear less legitimate programs will abuse them is not TRT in
my book.

> (Note that I'm writing the above to "defend" a feature that I still 
> believe should better be removed from Emacs.)

I'm not sure what to do with this remark.  I'm not accusing you of
anything, so you don't need to justify or defend yourself.  We are
discussing what should this feature include assuming that it will be
in Emacs.