Re: Removing prog-indentation-context

[Vitalie Spinu <spinuvit@gmail.com>]

I think the third element of prog-indentation-context is unlikely to be used by
major-modes anyways. Firstly due to inherent complexity of the concept, secondly
due to undefined, multi-mode specific, semantics of what to do with those
spans/chunks.

In any case, multi-mode engines can ignore prog-indentation-context. My bet is
that they will always do so, at least because there is no reliable way to
identify modes which use it and modes which don't.

  Vitalie

>> On Fri, Mar 25 2016 02:53, Dmitry Gutov wrote:

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