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: Wed, 17 Aug 2022 17:03:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

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.



reply via email to

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