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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  emacs-devel@gnu.org
> 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.

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

> But I'd be fine keeping the old prog-indentation-context if you want.

Actually, let me try to understand why any changes to the existing
code, apart of _adding_ those few 'widen' calls, are at all necessary.
Please bear with me.

What I see in the branch is this:

  1) the calls to prog-widen are replaced with calls to widen.
  2) some calls to widen are added
  3) prog-indentation-context is removed
  4) prog-first-column the function is removed, and its calls replaced
     with accessing the (existing) name-sake variable

For 4), we already agreed that keeping a function is better.

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.

2) can be taken care of as indicated above, thus avoiding any possible
effects on existing behaviors when MMM is not active.

If you agree with the above, then we can have the cake and eat it,
too.  Or am I missing something?