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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Theodor Thornhill <theo@thornhill.no>,  emacs-devel@gnu.org,  dev@rjt.dev
> Date: Tue, 01 Nov 2022 09:32:18 -0400
> 
> My best hope so far is to:
> 
> - Rename `c-mode` to `cc-c-mode`.
> - Make a new `c-mode` which delegates to `cc-c-mode` by default unless
>   the user asked for the "new, tree-sitter based, c-mode" in which case
>   it uses the brand new code base.
> 
> `cc-c-mode` would still set `major-mode` to `c-mode`, so from the users's
> point of view there's still only one `c-mode` but the two variants
> (tree-sitter and CC-mode) are almost completely separate.
> 
> We should make some effort to avoid users thinking "oh, there's the
> legacy CC-mode-based c-mode and the shiny new tree-sitter-based C-mode",
> but rather think "should I stay with the trusty CC-mode-based c-mode, or
> try the toddler c-mode".
> 
> > Tree-sitter doesn't (and cannot) replace everything a major mode does
> > for a programming language.
> 
> No, indeed.  But it's hard to use one part of CC-mode without another.
> One of the great things about CC-mode is how it is all
> nicely integrated.  But that cuts both ways :-(
> 
> > So a completely new mode means we through the baby with the bathwater.
> 
> The way I see it is that it will not break backward compatibility, and
> in the short term it may fail to provide a strict superset of CC-mode's
> `c-mode` features, but it's still going to be better than mixing the two
> and then trying to fix the corresponding breakage.
> 
> > CC Mode has a full-blown manual, where this question is answered.
> > Here's a partial list of features outside of the fontification and
> > indentation area, which I collected just by looking at the top-level
> > menus of that manual:
> >
> >  . filling and breaking text in comments and strings
> 
> This should be broken out of CC-mode so that all modes can benefit from it.
> AFAIK this is the most valuable feature of CC-mode that's sorely missing
> in our generic infrastructure (lots and lots of other major modes suffer
> from it, so making it available to all major modes will be a great
> improvement).
> 
> >  . automatic insertion of newlines after braces, colons, commas, semi-colons
> 
> This is already provided by `electric-layout-mode`.
> [ More specifically it's one of the parts of CC-mode which I
>   "broke out of CC-mode so that all modes can benefit from it".
>   Of course, CC-mode doesn't use it, because when you try to
>   implement something to be more generic, you rarely end up with
>   100% identical behavior; and CC-mode wants to be backward compatible
>   with old Emacsen that don't have `electric-layout-mode`.  ]
> 
> >  . whitespace cleanups
> 
> Not very familiar with this, but I'd be surprised if it wouldn't benefit
> from "break out of CC-mode so that all modes can benefit from it".
> 
> >  . minor modes: electric, hungry-delete, comment-style
> 
> "Break out of CC-mode so that all modes can benefit from it".
> 
> >  . c-offsets-alist and interactive indentation customization (related
> >    to indentation, but still extremely important, and not directly in
> >    tree-sitter)
> 
> This is indeed important, but we can't use CC-mode's code for that in
> any case: it needs to be reimplemented for tree-sitter's indentation.
> And it'd be better if we could do that without having to worry about
> backward compatibility with existing CC-mode users's settings
> (i.e. we're free to cover the same functionality in a different way).

Sorry for being blunt, but you've presented a plan for Emacs 32 if not
42.  If that's what we need, we should first make sure that Theodor
(or whoever picks up the gauntlet) will be willing to work on such a
branch for that long a time ;-)

What _I_ want is to have some decent tree-sitter supported modes in
Emacs 29, and I still hope C/C++ editing could benefit from that, in
Emacs 29.  That calls for a completely different plan, if my
experience with Emacs development is of any significance.

Bottom line: I don't see how we could make a "revolution" the size you
are envisioning in such a short time.  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.

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.