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

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/2/17 2:24 AM, Stefan Monnier wrote:

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

Depending on whether the major mode is the "primary" mode or a 
"submode", some commands might prefer no resrictions, and some the 
current chunk. font-lock, on the other hand, will (almost?) always want 
to use the current chunk.

And only the MMM framework knows whether the mode is primary or not. So 
the issue is not that obvious.

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

Are you fine with only having prog-first-column variable in Emacs 26?

Adding prog-first-column-function without having something similar for 
chunks would seem inconsistent.

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

Makes sense.

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

I see.

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

This one I don't understand: how would you know the indentation is 
correct without trying to reindent?

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

As an example, yes, but it's not like we can move all modes to SMIE.

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

The current state of the branch, then?

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

Do you have any particular hacks in mind, in e.g. mmm-mode?

> Maybe a generalization of mhtml-mode,
That might actually be possible, a kind of mixed-mode builder.