Re: locked narrowing in ELisp

[Dmitry Gutov]

On 17.08.2022 17:20, Eli Zaretskii wrote:
> > 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.

I guess I didn't understand your concern, sorry. Invisible is handled 
somewhere on the high level, OK. I did not mistake it for 'intangible'.

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

Org uses different properties, a lot. Not just 'invisible'. So I'd 
rather people test the performance of this first before dismissing.

My limited testing didn't show any particular slowdown.

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

Commands that do want to obey narrowing, can take the soft-narrowing 
bounds and apply the narrowing internally.

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

I'm likely missing a lot of things, since I don't usually use this 
feature interactively. All I know is, about once or twice a year, people 
come and ask to make a certain command ignore narrowing. And nobody 
every comes and asks to revert those changes.

Could someone give a few problem scenarios with this patch? Preferably 
ones that should be hard to fix. Adapting isearch took about 2 lines.

soft-narrow-and-widen.diff
Description: Text Data