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

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

>> I'm no authority on the matter, but I'd love for us not to complicate
>> things too much. I vote for separate, non-cc-prefixed _new_ modes, that
>> derives from prog-mode.
>
> That'd mean people will need either to invent all the other goodies in
> CC mode (everything except fontifications and indentation) from
> scratch, or give up all those other goodies.  Does that make sense?

I'm a strong proponent of keeping "one mode" but from what I've seen so
far, trying to mix tree-sitter with CC-mode's `c-mode`, I agree with
Theodor that it might be better to start from scratch :-(

I have not looked at other languages in CC-mode, so I don't know if the
same should apply to all CC-mode's modes (my guess is that it does, tho).

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).


        Stefan