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

On 17.08.2022 14:44, Eli Zaretskii wrote:
Date: Wed, 17 Aug 2022 03:05:05 +0300
From: Dmitry Gutov <dgutov@yandex.ru>

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.

I don't think this is reliable solution for a general problem such as
this one.  What that package does is prevent _some_ commands and APIs
from escaping the "narrowing".  But in the general case, once you get
low enough into our infrastructure code, there's no way of knowing
what is TRT wrt this "narrowing", because the intent of the caller is
unknown, and quite a few places in our code will happily ignore it.

Knowing the intent of the narrowing is indeed the problem. A split between user-level ("soft") narrowing and "real" narrowing makes sense to me.

Calling some narrowing "hard" doesn't answer the question of intent, OTOH.

So I think it is eventually unavoidable to have to define some
property of the narrowing that every piece of Emacs will test in order
to understand whether it should or shouldn't move outside of the
narrowed region.

In either approach we'd end up with two kinds of narrowings. The question for me is, which of the approaches will require more effort from Lisp writers to adapt. That is, how many functions and features should specifically handle user-level narrowing.

I'd be happy to be able to remove all the (save-restriction (widen) ...) calls littering the code.

reply via email to

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