Re: locked narrowing in ELisp

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 17 Aug 2022 17:03:46 +0300
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 17.08.2022 16:55, Eli Zaretskii wrote:
> >> 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.

I don't see how this is relevant to the concern I raised.  I was
talking about the effects on the display engine.  It doesn't only
display, it also looks at buffer text for various purposes.

> > 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 Org is indeed relatively slow when you move through a buffer which
has large parts of it hidden by invisible properties.

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

I don't think you realize how widespread is use of low-level
primitives and functions in user-level commands.

What you suggest is not a clean design, because it is based on
inaccurate mental model of Emacs internals.  It cannot work reliably,
to the best of my knowledge.