Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls

[Dmitry Gutov]

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.