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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Since Eli only wants MMM-support if it work 100% everywhere, I don't
think it matters what gets into Emacs itself in this respect, because
the real stuff will have to live elsewhere.

The thing we should try and fight for of course are those such as making
indent-according-to-mode widen before calling indent-line-function.

>> Give that it's introduced specifically so it can be changed, relying
       ^                                                               ^^
       n                                                               on
>> 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.

I'm glad English includes enough redundancy that you could make out what
I meant.

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

The idea is just to highlight those lines whose indentation would be
modified by indent-line-function, so you only want to compute the
target column and compare it with the current column.

>> Arguably `smie-indent-functions` already provides that functionality.
> As an example, yes, but it's not like we can move all modes to SMIE.

Hence the "arguably": it can be used without using SMIE, but it's not as
convenient as you might like.  E.g. you can do:

    (require 'smie)

    (define-derived-mode ...
      ...
      (setq-local smie-indent-functions '(my-compute-indent))
      ...)

You can even reuse some parts of smie-indent-functions which don't depend
on the smie-grammar/rules business, e.g.:

      (setq-local smie-indent-functions
                  '(smie-indent-fixindent smie-indent-bob
                    smie-indent-comment smie-indent-comment-continue
                    smie-indent-comment-close smie-indent-comment-inside
                    smie-indent-inside-string
                    my-compute-indent))

but the more serious problem is that other packages (such as auto-fill)
can't rely on `smie-indent-functions' because it's not used by all major modes.

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

Sure.

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

No.  Can we put mmm-mode into elpa.git?


        Stefan