Re: locked narrowing in ELisp

[Dmitry Gutov]

On 17.08.2022 16:55, Eli Zaretskii wrote:
> > Date: Wed, 17 Aug 2022 16:40:01 +0300
> > Cc: emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > Could be, but unless we go through the whole C code looking for checks
> > > of BEGV/ZV and updating the code to also check the "soft bounds" this
> > > won't work reliably enough to replace existing uses of narrowing.
> >
> > The point is to avoid doing that. If we can.
> >
> > For instance, use two overlays in the current buffer with `invisible'
> > property rather than have the display engine refer to the new kind of
> > narrowing bounds.
>
> That's a time bomb waiting to go off, because invisible text is
> handled at a relatively high level in the display engine, and
> otherwise the invisible property is largely ignored in Emacs.

User-level features should be implementable in terms of primitives 
allowed in Lisp userland.

> Moreover, it will make redisplay slower.  Skipping invisible text is
> faster than iterating through it, but it still takes time, whereas not
> going beyond BEGV..ZV is instantaneous.

Org, as one example, uses invisible text all the time. Other feature too.

> And finally, I don't think I see the benefit of this, even if it'd
> work: you want to get rid of (save-restriction (widen)), but you are
> willing to have to replace that with tests of overlays and invisible
> text all over the place?

No, I don't think the addition of "tests ... all over the place" will be 
needed. The display engine handles the 'invisible' property already.

A number of features/commands will indeed need to know the bounds of the 
user-level narrowing (and we'll have a buffer-local variable for that), 
but that's probably it.