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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sat, 2 Dec 2017 21:35:43 +0000
> 
> I'm asking why "Emacs is written in these 2 languages" is important.

Because every development environment should first support its own
development well.  If it doesn't do that, it's incomplete.

> > Surely, a feature that aims to
> > support multiple major modes should strive to support CC Mode?
> 
> Not necessarily. It should first and foremost support the languages that 
> are most important for our users.

Indeed; and C-like languages are quite popular among them.

How will we look if we support JS and Ruby embedded in HTML, but not C
code embedded in Yacc grammars nor Awk snippets embedded in shell
scripts?  Both are quite frequent out there.  We will be laughed at.

> > They are important, but so are C-based languages: C++, Java, Awk, etc.
> 
> I don't know CC Mode, and cannot provide patches for us. I tried 
> debugging related problems a few times, and those turned out to be 
> fairly long spelunking expeditions.
> 
> However long it will take just to convince Alan to agree, is anybody's 
> guess.

Convince Alan to do what?  Do we even understand well enough what are
the problems in CC Mode that get in the way?  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).  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, even if your proposal is amended?  I don't know.
Does anyone know?  If so, would they please speak up?

I also don't understand well the essence of your proposal.  Yes, I've
(tried to) read the discussions you pointed to, but what I'm looking
for is buried there under many layers of secondary stuff.  Why do you
want to abandon the prog-widen stuff, which you supported just 2 years
ago?  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)?  All these questions and considerations need
to be understood, because you are explicitly proposing an incomplete
solution, and asking us to agree with its deficiencies, but without
providing a clear picture of what are we going to give up on.  And
last, but not least, what is different in your proposal that will not
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?

We desperately need these details spelled out to make the discussion
of this to become technical again, not emotional.

> > It's not a catastrophe.  Assuming Emacs 26.1 is not a complete
> > disaster, we could decide releasing Emacs 27.1 as the next version.
> 
> Not a catastrophe indeed. But no step forward for mixed-modes support in 
> Emacs 26 would be unfortunate.

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.  You
are still debating its design and implementation, even if we disregard
the CC Mode issue.  It makes no sense to put this into a code base
which is frozen since September.

> > Why would we need to remove that for Emacs 26.1?
> 
> 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 was admitted with
Stefan's full support, and at least ANTLR needs it in conjunction with
Python.  Removing it without having some alternative again makes no
sense to me.  We should discuss this when the incompatible code lands;
at that time, we will see how to remove/replace prog-widen etc. with
minimal pain for its users.  For now, there's no incompatibility that
requires us to remove the code.  And anyway, making such changes when
we are in pretest is against our practices.