|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |