Re: locked narrowing in ELisp

[Eli Zaretskii]

> Date: Thu, 18 Aug 2022 02:13:30 +0300
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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'.

The concern is that some parts of the display code will ignore the
invisible text and some won't.  The display code doesn't expect
BEGV..ZV restriction to behave that way, it expects these limits to
affect every part of Emacs.

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

I'm talking from experience: movement through a large Org buffer with
a lot of text hidden is slower.

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

That would mean all of the commands.  A lot of changes (or a lot of
breakage).  It doesn't sound like a good solution, at least not better
than just biting the bullet and introducing 2 different kinds of
narrowing with some ways of telling Emacs internals which of the two
to obey at any particular moment.  (The latter is actually the tricky
part, IMO.)

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

Making a specific command ignore narrowing is easy.  Your proposal
implicitly assumes that the number of commands that want to ignore
narrowing is much larger than the other kind.  I don't think it's
true, and you haven't provided any evidence to that effect.  Moreover,
I think it might make sense for some commands to honor or ignore the
narrowing depending on the use case, and that is not solved with your
proposal.

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

That's just one command.  Emacs has thousands of them.