[Top][All Lists]

[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 16:40:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 17.08.2022 16:03, Stefan Monnier wrote:
Such a display-only narrowing might be a good alternative for many uses
of narrowing, but narrowing is also used quite commonly (either by the
end-user or in ELisp code) in order to restrict the effect of an
operation (like search&replace) to a particular region.

Certain operations could look up the "soft narrowing" bounds and act
accordingly, if it's implemented in the core and appropriately documented.

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.

To my understanding, there are more commands and facilities that want to
ignore user-level narrowing, rather than the ones that want to obey it. Also
a lot of "undecided" ones, waiting for someone to report that they should,
in fact, ignore narrowing.

But for backward compatibility reasons, we can't break the cases that
need the bounds to be hard, even if it could fix some cases.

The "regular" narrowing will play the role of the hard one because there will be little need to protect against 'widen' calls all around.

I agree the migration path is non-obvious, though.

reply via email to

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