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

[Stefan Monnier]

>> Eli, we already have a feature in Emacs (prog-indentation-context) that
>> does not adhere to your (unreasonably high) requirements.
> Emacs development is not only about not losing existing features.  It
> is mainly about gaining new important features.  Here you are adding a
> feature that I think is important enough for us to try make it support
> C-like languages.

His proposal is reworking prog-indentation-context.
CC-mode doesn't support prog-indentation-context, so it's no surprise
that it doesn't support this replacement= and I don't see why suddenly
we should first get CC-mode to support it before the replacement can
be installed.

> I don't think this requirement is unreasonably high, as those
> languages are still pretty much the mainstay of the industry, and
> definitely used by many Emacs users.

Apparently, this has not been enough motivation for the last decade, so
I'm not holding my breath.  Including the new proposal into Emacs may
provide an added incentive if MMM-support becomes sufficiently common
that CC-mode becomes really the odd-one out (tho it's just an incentive
and CC-mode is the odd-one out in many respects already).

> Maybe I'm missing something, but what's the equivalent of PREV-CHUNK?

There isn't any.  PREV-CHUNK is probably a good idea somewhere in some
cases, but we haven't found those cases yet.

>> We keep 'prog-first-column' from that proposal
> But it was a function, and you made it a variable.  This will get in
> the way of compatibility, and also potentially will make future
> extensions harder.  Why not keep it a function?

Agreed, it should be a function (which can internally just lookup
a variable, in its current implementation, but API exposed to major
modes should be the function).

>> and instead of allowing MMM to indicate the chunk bounds through
>> prog-indentation-context, we allow MMM to apply narrowing directly, and
>> that modes honor it.
> This simplification also took away some of the features, like the
> ability to nest restrictions.

I do not know what you're referring to.

> I wonder why did you discard that.
> It's existing functionality, pretty lightweight, which was in Emacs
> for some time, and is reasonably well documented.  And it already
> satisfied your requirement of not allowing sub-modes to widen.  Why
> not leave it alone?  What am I missing?

>>>> Transitioning from prog-indentation-context to the new approach is very
>>>> easy.
>>> That's what I thought.  And that's why we should do that
>>> simultaneously with landing the new approach.  There's no reason to do
>>> that earlier.

You mean we should provide patches for those codes using
prog-indentation-context?  Doesn't Dmitry's branch already do that?

> I don't see the incompatibilities.  Basically, you replaced prog-widen
> with widen,

Actually, no.  The replacement for prog-widen is more like #'ignore
(remember: prog-widen is for major modes who want to "narrow to the
current chunk's boundaries", but with the new arrangement, the major
mode's code is already called with such a narrowing in place).

> IOW, the transition could be much smoother than it will be if we
> actually remove that stuff, because I don't think there's any
> incompatibility here which would disallow direct calls to 'widen'
> and/or leaving prog-indentation-context at its default nil value.  Or
> maybe I'm missing something again.  But if I'm right, and if we can
> make the necessary changes limited only to the documentation, then it
> could well make it into Emacs 26.  So I think it is worth our while
> to make some effort in that direction, if at all possible.

Then let's focus on the doc plus adding a few calls to widen in places
like indent-according-to-mode.


        Stefan