Re: locked narrowing in ELisp

[Dmitry Gutov]

On 17.08.2022 03:55, Stefan Monnier wrote:
> > Have you given any thought to the "soft widen" alternative
> > I voiced recently?
> >
> > https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00291.html
> >
> > 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.
> >
> > Then there would be no need for "hard" or "locked" narrowing to restrict
> > those calls to 'widen', because there wouldn't be any. The
> > 'narrow-to-region' and 'widen' would be restricted to lower-level uses, like
> > mmm-mode, Info-mode, and the display engine long-line wrangling magic.
> >
> > The migration path seems difficult, but the result might be worth it.
>
> Such a display-only narrowing might be a good alternative for many uses
> of narrowing, but narrowing is also used quite commonly (either by the
> end-user or in ELisp code) in order to restrict the effect of an
> operation (like search&replace) to a particular region.

Certain operations could look up the "soft narrowing" bounds and act 
accordingly, if it's implemented in the core and appropriately documented.

To my understanding, there are more commands and facilities that want to 
ignore user-level narrowing, rather than the ones that want to obey it. 
Also a lot of "undecided" ones, waiting for someone to report that they 
should, in fact, ignore narrowing.