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

Hi Stefan,

On 16.08.2022 23:18, Stefan Monnier wrote:
Last time we discussed these issues, we ended up deciding that
indentation (like font-lock before it) should "eagerly widen" (i.e. undo
any user-setup narrowing) before calling the mode-specific code.
This way, the indentation and font-lock code of a major mode should
simply never need to call `widen` and things like the MMM-mode (or the
long-lines code in redisplay) can just setup the narrowing before
calling that major mode code without any need to "label" the narrowing.

This was an elegant solution, but it seems to be too limited, because
the parsing code that want(ed) to `widen` is typically also called from
other parts of the major mode than the indentation or font-lock code.

Have you given any thought to the "soft widen" alternative I voiced recently?


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.

In the past, we played with having a new widening function (there was
a `prog-widen` briefly in `prog-mode.el`).  Maybe we should
(re)introduce such a thing (or maybe an optional arg to `widen` which
would indicate what "kind" of widening we want to do), coupled with some
kind of `widen-function` which MMM-mode and the redisplay could
setup to filter/tweak those widening.

'widen-function' can work too. IIRC various 'multi-mode' packages have tried to advice 'widen', without much of a reliable success. Hopefully the extra indirection doesn't cause too much overhead. But it's a more complicated solution either way.

reply via email to

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