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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Convince Alan to do what?  Do we even understand well enough what are
> the problems in CC Mode that get in the way?

Yes.

> About the only thing
> spelled out in this discussion was the need not to widen.  Personally,
> I think this is not a grave issue, just some technical problem that is
> certainly solvable (you proposed one such solution).

Indeed.

> But is that all?  You mentioned some other problems, but never
> described them.  What are they?  Are they grave enough to prevent your
> proposal from ever supporting CC Mode,

No, it's just a small matter of adjusting CC-mode here and there.
But given that the only person who understands this part of CC-mode well
enough is Alan, it's difficult for anyone but Alan to do it (I think
I could do it as well, but I know that my solution wouldn't please Alan
because it would involve switching over to syntax-propertize, so my
motivation to do it is rather low).

> even if your proposal is amended?

No need to amend anything.

> How do you address the issues which prog-indentation-context did
> (e.g., if the embedded chunk of code is incomplete, and perhaps even
> syntactically invalid)?

We can easily provide a similar functionality with Dmitry's design.
Dmitry hasn't bothered doing that, because so far it's never been used
(so it's not even clear whether it's ever needed nor whether it would
provide the needed info).

> cause it to end up like all the previous ones: either committed to
> Emacs and basically unused, or, worse, collecting dust in long
> forgotten patches or branches?

His proposal is really really small, and matches what is already done
in mmm-mode and mhtml-mode, so it's actually the solution that's least
likely to collect dust, because it's already in use.

> Emacs 26 has enough new features to justify a major release, so I see
> no reason to press so hard to get this feature into it as well.

I think the failure here is to describe clearly the proposal.
The core of the proposal, AFAIK, is the following:

    state that indent-line-function can rely on the current narrowing to
    find all the relevant text, because the caller has already widened
    when necessary for that.

To make it true, we need a few changes in the code, mostly we need to
tweak indent-according-to-mode so that it widens before calling
indent-line-function.  This change should be harmless because
even if the user has narrowed the buffer, the indentation should always
be done depending on the whole buffer's content anyway.

>> It's not well supported, and it's incompatible with the code we are 
>> discussing. There's no point in having it present in Emacs 26, and then 
>> removing it in Emacs 27.
> That code is in Emacs for more than 2 years.

It's been in emacs.git's master, yes, but not in any released version of Emacs.

> It was admitted with Stefan's full support, and at least ANTLR needs
> it in conjunction with Python.

These can very easily be adjusted to rely on the new convention.


        Stefan