[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.
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, (continued)
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Andreas Röhler, 2016/03/23
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Eli Zaretskii, 2016/03/23
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Andreas Röhler, 2016/03/23
- RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Drew Adams, 2016/03/23
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Vitalie Spinu, 2016/03/23
- RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Drew Adams, 2016/03/23
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Eli Zaretskii, 2016/03/23
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Dmitry Gutov, 2016/03/24
- Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality, Eli Zaretskii, 2016/03/24
- Removing prog-indentation-context (was: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality), Stefan Monnier, 2016/03/24
- Re: Removing prog-indentation-context,
Dmitry Gutov <=
- Re: Removing prog-indentation-context, Dmitry Gutov, 2016/03/24
- Re: Removing prog-indentation-context, Stefan Monnier, 2016/03/24
- Re: Removing prog-indentation-context, Dmitry Gutov, 2016/03/25
- Re: Removing prog-indentation-context, John Wiegley, 2016/03/26
- Re: Removing prog-indentation-context, Dmitry Gutov, 2016/03/27
- Re: Removing prog-indentation-context, Vitalie Spinu, 2016/03/25
- Re: Removing prog-indentation-context, Dmitry Gutov, 2016/03/28
- Re: Removing prog-indentation-context, Stefan Monnier, 2016/03/28
- Re: Removing prog-indentation-context, Dmitry Gutov, 2016/03/28
- Re: Removing prog-indentation-context, Stefan Monnier, 2016/03/28