Re: locked narrowing in ELisp

[Dmitry Gutov]

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?

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.

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