Re: Removing prog-indentation-context

[Dmitry Gutov <dgutov@yandex.ru>]

On 03/24/2016 08:55 PM, Stefan Monnier wrote:
> FWIW, I think it's a mistake to remove it.  We need to move forward on
> multi-mode support, and even if prog-indentation-context is not "the
> right way" (I doubt there is such a thing anyway),

Are you against removing it in Emacs 25.1 in particular (but retaining 
it, for now, on master)? We don't include support for it even in the 
built-in major modes, save one. And python-mode doesn't support the more 
controversial third element. The built-in antlr-mode doesn't use it 
either, even though it was supposed to be the main beneficiary.

It's silly to expect third-party authors to adopt it when we haven't 
done so ourselves.

By that measure, prog-indentation-context has failed, at least for 
inclusion in the upcoming release.

> adapting some major
> modes to it will most likely not be wasted time, because it will most
> likely make it easier to adapt those modes to whichever other approach
> we may switch to in some future.

Respectfully, I more disagree than agree. If we put aside the 
PREVIOUS-CHUNKS element, we have two elements left:

- (START . END). Yes, making modes use `prog-widen' instead of `widen' 
is a good change, but it's a trivial search-replace. There's not much 
benefit in doing it in advance, or waiting for third-party code to catch 
up, etc. The proposed alternative: hard widen limits. If it's adopted, 
it'll make using prog-widen simply unnecessary.

- FIRST-COLUMN. The proposed alternative: prog-indentation-function that 
returns a column number. If we choose this one, it's likely to result in 
a rather natural code transformation in modes adopting it. It's also a 
different one that what we'd make to use FIRST-COLUMN, at least if we 
take smie and js as examples.

> More importantly, I don't think we'll ever agree on what should be done
> in this respect because we'll only know what works and what doesn't
> *after* we install it and make it "the official way".

Why? The advancement prog-indentation-context offers is rather minimal 
for new multi-mode packages to crop up overnight. And even if they 
would, they could just as well test their changes using the master 
branch (we do have a certain fraction of users continually building from 
it, even if they don't participate in the development).

On the other hand, you have maintainers of the two active multi-mode 
packages (polymode more than mmm-mode) right here, in this discussion. 
And we're both capable of building Emacs from master, as well as 
implementing features that depend on it. That must be true for 
Christopher as well.

> The "run with it" part will hopefully help align the
> various major modes, thus making it easier for a second candidate to
> make further progress, and so on and so forth.

Yes, well, it didn't, so far.

And there are better ways to evaluate an API proposal, such as asking 
for patches that add support for all of its parts, in advance.

If the demand for multi-mode support is less than we'd hope (resulting 
in fewer or slower patches), it can well incubate on a feature branch.

In the meantime, the basic needs of the web development crowd are being 
served by web-mode (which is not an actual multi-mode, and would likely 
not benefit from features discussed here). So it's not like a lot of 
people's is at a standstill because of our indecision.

> At least, that was the reason why I decided to go with
> prog-indentation-context.  It was not because I thought it was The Right
> Way, the final word on the matter.

Emacs's development cycles are long, and backward compatibility promise 
is significant. I don't want to get into situation with multiple blessed 
solutions, all inferior in some way, all with spotty support in existing 
code.