>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4