Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls

[Stefan Monnier]

>>>> (defvar prog-widen-function #'widen)
>>>> (defun prog-widen () (funcall prog-widen-function))
> The idea for multi-mode packages has always been to make do without making
> the major modes actually aware of hunk boundaries.
[...]
> And the snippet of code won't make them aware either, since the chunk
> boundaries are conveyed via narrowing only in particular dynamic contexts,
> such as when indent-line-functions is called.

But widening/narrowing to the current chunk might be needed for commands
specific to the major-mode, hence commands which the MMM framework
doesn't know about (and hence doesn't wrap like it does for
indent-line-function).

> You probably mean adding a variable prog-first-column-function, then?

Right.

> Or will we expect multi-mode packages to simply advise the prog-first-column
> function? I'm fine with that.

Give that it's introduced specifically so it can be changed, relying
advice would be a bad idea (especially since the advice would generally
want to be buffer-local, which is easier to get with a variable).

>> Here are some examples I can think of:
>> - auto-fill-mode may like to compute the hypothetical indentation that
>> would result from inserting a newline somewhere (and do that before
>> touching the buffer).
> Won't it need to call indent-line-function to find out how much the next
> line should be indented?

No because indent-line-function would actually perform the
re-indentation, whereas we only want to calculate the hypothetical new
indentation column.  See `smie-auto-fill`.

>> - some package may like to highlight lines which aren't currently
>> indented right (so, it won't call indent-according-to-mode, but
>> it will need to compute the "desired" indentation).
> This example will *definitely* need to call indent-line-function.

Again no, because it doesn't want to modify the buffer.

> And both of them should be solved by exchanging indent-line-function for
> (non-mutating) line-intentation-function. But that's a change for
> another day.

Ah, yes, that would be a good change.
Arguably `smie-indent-functions` already provides that functionality.

> I'm sure there can be.  A complete proposal to let the modes know chunk
> boundaries, etc, has yet to be finalized, however.  And just having font-lock
> and indentation work reliably in multi-mode contexts will
> be a significant win.

Agreed.  As far as I'm concerned your proposal is good to go, which is
why I was talking about subsequent changes.

BTW, could we get some kind of multi-mode package in elpa.git or
emacs.git to go along with that (it doesn't have to be fancy, but it's
important that it doesn't have any submode-specific hacks).
Maybe a generalization of mhtml-mode, or something separate but whose
design is such that it can aim to (slowly) merge with mhtml-mode?


        Stefan