[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing prog-indentation-context

From: Dmitry Gutov
Subject: Re: Removing prog-indentation-context
Date: Fri, 25 Mar 2016 02:53:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]