Re: feature/tree-sitter: Where to Put C/C++ Stuff

[Stefan Monnier]

> Sorry for being blunt, but you've presented a plan for Emacs 32 if
> not 42.

Huh?  What makes you think that?

On the contrary it's a plan that lets us get quickly a working
tree-sitter-based C-mode.  Not one that's a strict superset of CC-mode's
`c-mode`, but a quite decent `c-mode` nevertheless.

> Bottom line: I don't see how we could make a "revolution" the size you
> are envisioning in such a short time.

It's not at all a revolution.
It's a very smooth path that breaks nothing and lets us move progressively.

It's a mini "revolution" maybe for users who will have to choose
between two different flavors of `c-mode`, each one with its current
strengths and downsides, but that's the cost to pay for a much smoother
job on the implementation.

> Not unless you somehow can summon a team of talented and motivated
> individuals to work on it starting today.  The only practical way
> I see is by _evolution_, gradually replacing CC Mode's features with
> tree-sitter supported ones where that makes sense, and at first as
> opt-in.  And yes, this means no "breaking out of CC-mode", at least
> not as part of this particular effort: it simply is too much, too high
> a bar to jump.  It could well enough kill the effort, for all
> practical purposes.

Slowly evolving CC-mode itself to use tree-sitter is something I can't
even begin to imagine how to do.  That's what I would expect to take
years :-)

> Of course, I'd be happy to be proven wrong, and be dazzled by a
> full-fledged, backward-compatible C/C++ mode based on tree-sitter,
> with all of the stuff you mentioned on top of that, within the month.

I don't foresee "all of the stuff" to be done immediately, no.
[ Tho I do think the filling code at least can be extracted from CC-mode
within a month (or at least, an important subset of it).  ]

Which is why users will have to choose (and we'll stick to CC-mode by
default, of course).


        Stefan