[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Repla
From: |
Dmitry Gutov |
Subject: |
Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls |
Date: |
Wed, 6 Dec 2017 20:41:21 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 |
On 12/4/17 7:40 PM, Eli Zaretskii wrote:
From: Stefan Monnier <address@hidden>
Cc: address@hidden, address@hidden
Date: Mon, 04 Dec 2017 12:12:48 -0500
The code which supports PREV-CHUNK is already in Emacs, so the
question IMO is "why remove it"?
?Which code is that?
prog-indentation-context and its support in prog-widen.
To reiterate:
Yes, this code has been in Emacs source tree for two years. But:
It's only used is one line in antlr-mode.el, which wasn't supposed to
start using it before Emacs 26 was released anyway. But it's easy to change.
On the flip side, prog-indentation-context is *only* well-supported in
python-mode. Not in css-mode, js-mode, ruby-mode or others. In those,
you still have to combine its binding with narrow-to-region, essentially
obviating the need for the second element in the list. In short: we have
the code, and even Emacs, after the said 2 years, isn't supporting it
properly.
PREVIOUS-CHUNKS isn't supported anywhere either. And, in that case,
there's no code corresponding to it. Just a few pieces of documentation.
If we want to try to get this into
Emacs 26, we should strive to make the code changes minimal, ideally
zero. Once all we are left with are documentation changes, the
feature can land on emacs-26 right now.
Zero is not the intention: for the doc changes to be valid, we need to
add a few `widen` calls in places like indent-according-to-mode.
If those calls are conditioned on MMM actually being active, then
existing behavior will remain unchanged, and we are good.
No, the widen calls are conditioned on whether we want all
indent-line-function calls to start in fully widened state. Which seems
like an obvious improvement. Point is, they won't be allowed to call
'widen' themselves, so the addition of 'widen' to indent-for-tab-command
and indent-according-to-mode makes them act on the whole buffer in the
simple case.
What I see in the branch is this:
1) the calls to prog-widen are replaced with calls to widen.
No, they are not. The calls to prog-widen (or widen) made in indentation
related code are removed.
The only place in the diff where prog-widen was replaced with widen, is
where it probably shouldn't have been in the first place (that code is
not inside indent-line-function; only tangentially related).
2) some calls to widen are added
In code that later either calls indent-line-function or
beginning-of-defun-function.
3) prog-indentation-context is removed
Yup.
4) prog-first-column the function is removed, and its calls replaced
with accessing the (existing) name-sake variable
Yes. It's not a hard requirement, but there doesn't seem much benefit in
keeping it a function. And if it's a function, what will it return?
For 4), we already agreed that keeping a function is better.
I did not. Allow me to post a quote from my other message:
If we keep it a function, do we also have a variable prog-first-column?
Then, some consumers might have doubt which ones to use, and might opt
to reference the variable. In that case, we lose all benefits of having
it a function (like making its implementation somehow smarter later),
and the only benefit remaining is backward compatibility of having a
function with that name.
But! Like with PREV-CHUNKS, prog-first-column (and the later prog-widen)
are supposed to be used by the major modes only. There are no references
to either of these functions in the latest antlr-mode.el, and there
shouldn't be.
And as long as all the calls to that function are inside Emacs, we're
free to change it however, including turning it into a variable.
Since prog-widen already calls widen if prog-indentation-context is
nil (which it is by default), calling prog-widen without setting up
prog-indentation-context will just call widen; this magically takes
care of 1).
For 3), if we leave prog-indentation-context in the code, and also
allow direct calls to widen in modes which don't want to use the
context, we are not losing anything, while leaving the option of using
the context to those modes which will want that. This currently
cannot be used by MMM (AFAIU), but other features which need embedded
code, such as ANTLR, could still use it, and even MMM will be able to
do that if it is extended.
As I hopefully described, the above does not make sense, unfortunately.
2) can be taken care of as indicated above, thus avoiding any possible
effects on existing behaviors when MMM is not active.
Not sure I understand you here.
- [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, (continued)
- [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/03
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/04
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls,
Dmitry Gutov <=
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/09
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/09
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/10
- Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/10
- Getting rid of prog-indentation-context, Stefan Monnier, 2017/12/11
- Re: Getting rid of prog-indentation-context, Eli Zaretskii, 2017/12/11
- Re: Getting rid of prog-indentation-context, Stefan Monnier, 2017/12/11
- Re: Getting rid of prog-indentation-context, Stefan Monnier, 2017/12/11
- Re: Getting rid of prog-indentation-context, Eli Zaretskii, 2017/12/11
- Re: Getting rid of prog-indentation-context, Ingo Lohmar, 2017/12/11