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

[Dmitry Gutov]

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
> > narrowing?
>
> 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.