Re: locked narrowing in ELisp

[Dmitry Gutov]

On 17.08.2022 14:44, Eli Zaretskii wrote:
> > Date: Wed, 17 Aug 2022 03:05:05 +0300
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > If the user-level narrow/widen commands didn't use _actual_ narrowing,
> > but display engine tricks or whatever (example:
> > https://github.com/Malabarba/fancy-narrow/), "other parts of the major
> > mode" wouldn't have to do the usual (save-restriction (widen) ...)
> > dance, which a lot of code is littered with.
>
> I don't think this is reliable solution for a general problem such as
> this one.  What that package does is prevent _some_ commands and APIs
> from escaping the "narrowing".  But in the general case, once you get
> low enough into our infrastructure code, there's no way of knowing
> what is TRT wrt this "narrowing", because the intent of the caller is
> unknown, and quite a few places in our code will happily ignore it.

Knowing the intent of the narrowing is indeed the problem. A split 
between user-level ("soft") narrowing and "real" narrowing makes sense 
to me.

Calling some narrowing "hard" doesn't answer the question of intent, OTOH.

> So I think it is eventually unavoidable to have to define some
> property of the narrowing that every piece of Emacs will test in order
> to understand whether it should or shouldn't move outside of the
> narrowed region.

In either approach we'd end up with two kinds of narrowings. The 
question for me is, which of the approaches will require more effort 
from Lisp writers to adapt. That is, how many functions and features 
should specifically handle user-level narrowing.

I'd be happy to be able to remove all the (save-restriction (widen) ...) 
calls littering the code.