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

On 17.08.2022 03:55, Stefan Monnier wrote:
Have you given any thought to the "soft widen" alternative
I voiced recently?

https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00291.html

If the user-level narrow/widen commands didn't use _actual_ narrowing, but
display engine tricks or whatever (example:
https://github.com/Malabarba/fancy-narrow/), "other parts of the major mode"
wouldn't have to do the usual (save-restriction (widen) ...) dance, which
a lot of code is littered with.

Then there would be no need for "hard" or "locked" narrowing to restrict
those calls to 'widen', because there wouldn't be any. The
'narrow-to-region' and 'widen' would be restricted to lower-level uses, like
mmm-mode, Info-mode, and the display engine long-line wrangling magic.

The migration path seems difficult, but the result might be worth it.

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.

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.



reply via email to

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