emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: locked narrowing in ELisp


From: Dmitry Gutov
Subject: Re: locked narrowing in ELisp
Date: Thu, 18 Aug 2022 02:13:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]