[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Major modes using `widen' is a good, even essential, programming pra

From: Dmitry Gutov
Subject: Re: Major modes using `widen' is a good, even essential, programming practice.
Date: Tue, 23 Aug 2022 02:59:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

Hi Alan,

On 22.08.2022 14:26, Alan Mackenzie wrote:
A bit late, but ....

Not at all.

On Sun, Aug 07, 2022 at 20:57:59 +0300, Dmitry Gutov wrote:
On 06.08.2022 23:13, Alan Mackenzie wrote:
Narrowing is primarily a user feature.  Users can arbitrarily narrow a
buffer to ANY contiguous region of text.  So when a major mode needs to
examine text even slightly distant from point, it MUST widen, to be sure
that the text to be examined is within the visible region.

Now wouldn't it have been nice if user-level narrowing didn't create an
*actual* narrowing but only some visual perception of it? IIRC there is
a third-party package which implements this approach.

I'm not convinced, given how well narrowing currently works.  I don't
think it's useful to debate how things _would_ have been, when they are
currently very different.

I admit the migration path looks murky.

  From what I've seen of feature requests related to narrowing in my
packages, it's always along the lines of "please add (save-restriction
(widen) ...) around the whole implementation".

Are there actually user-level commands which should not ignore

Yes, lots and lots of them.  goto-char, isearch, occur, and many others.
It might be easier to answer the question which user-level commands are
not restricted by narrowing.

You might want to take a look at the patch I posted in https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00644.html

It handles a bunch of commands OOTB (namely, simple navigation and editing), and Isearch support took about 2 lines of code.

Occur should require attention, one way or the other (it's not obvious to me that Occur should limit itself to accessible region, but if not, navigation to inaccessible parts should undo soft-narrowing), but the implementation should likewise be trivial.

The work in choosing the desired behavior for various commands should take the most part of the effort.

If not, it would be better if user-level narrowing was implemented as
something else (e.g. two invisible overlays). Then all other code
wouldn't have to bother with undoing it.

But "all" other code would instead have to take account of the invisible
overlays instead.  I don't think this would be better.  It would involve
a _lot_ of work to implement and we'd be left with some other
inconveniences instead of the currently perceived ones.

Some of the code would be handled automagically. A lot of the code doesn't want to obey user-level narrowing anyway. And the rest, yes, would need to be updated.

reply via email to

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