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

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/9/17 12:47 PM, Eli Zaretskii wrote:

> You explained that you consider the design and implementation of
> prog-indentation-context unnecessarily complex, and that a simpler
> design and implementation would be more elegant, given the current
> practices in related modes.  You have _not_ explained why keeping the
> prog-indentation-context stuff would prevent us from supporting MMM
> and similar features as easily as under your proposed changes.

I'm honestly might be forgetting some things, given the brain-numbing 
effects of discussions like this, but:

- We need to expand the scope of use of all elements of 
prog-indentation-context but the first to other facilities as well, such 
as font-lock, beginning-of-defun-function, etc, at which point the name 
of the variable kind of ceases to make sense.

Out of all these, font-lock is the most apparent to the user, and thus, 
arguably, the most important. It is, luckily, not an issue in most major 
modes, but it *is* an issue in CC Mode, which you said you wanted to see 
supported.

- PREVIOUS-CHUNKS, given how it's permissively documented now, will 
likely prevent some useful caching mechanisms inside major modes that 
will decide to use it (in particular the first option will, "A string 
containing text"). I also fail to see how one would write support for it 
without having to program two fairly different code paths.

- In case the discussion about moving 'widen' calls to 
indent-for-tab-command and indent-according-to-mode concludes 
affirmatively, we won't be able to use prog-widen there because 
prog-indentation-context gets set "later".

This issue can probably be avoided by dropping the backing variable and 
moving to a similar-but-different design with hooks like 
prog-first-column-function, prog-current-chunk-function, etc, but these 
details still need to be finalized, and for that I'm waiting for Alan's 
feedback on adapting CC Mode to MMM.

- Then, we'll go onto solving the less well-examined issues with our 
designer hands tied more strongly than they could have been, because 
we've committed to one particular API, one that's harder to smoothly 
migrate over from.

Next, WHAT HAPPENS IF WE SUPPORT PROG-INDENTATION-CONTEXT PROPERLY:

- All the major modes will have to be adapted to use prog-widen in 
indentation code, and maybe some other places they use 'widen' at now. 
This, in turn, will break their uses in mmm-mode, polymode, and whatever 
other MMM packages are out there (including mhtml-mode, but it's easy to 
fix).

- Thus, MMM frameworks will need to be updated, changing over from the 
current practice. Compatibility shims will need to be added in them, to 
work with both older and new Emacs.

So if you were worried that removing prog-indentation-context would 
cause inconvenience to antlr-mode (its last released version which 
jumped the gun with supporting prog-indentation-context), properly 
supporting prog-indentation-context will cause more breakage overall, in 
said MMM frameworks. Until they all get updated and all users install 
the new versions, by various means those updates are delivered.