From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Theodor Thornhill <theo@thornhill.no>,
emacs-devel@gnu.org, dev@rjt.dev
Subject: Re: feature/tree-sitter: Where to Put C/C++ Stuff
Date: Tue, 01 Nov 2022 09:32:18 -0400 [thread overview]
Message-ID: <jwvv8nyzv6v.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83pme7cf23.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 01 Nov 2022 09:24:52 +0200")
>> 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
next prev parent reply other threads:[~2022-11-01 13:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-01 2:30 feature/tree-sitter: Where to Put C/C++ Stuff Randy Taylor
2022-11-01 5:44 ` Theodor Thornhill
2022-11-01 7:24 ` Eli Zaretskii
2022-11-01 7:55 ` Theodor Thornhill
2022-11-01 9:22 ` Yuan Fu
2022-11-01 9:41 ` Theodor Thornhill
2022-11-01 9:57 ` Eli Zaretskii
2022-11-01 11:53 ` Theodor Thornhill
2022-11-01 12:28 ` Eli Zaretskii
2022-11-01 13:05 ` Theodor Thornhill
2022-11-01 13:10 ` Eli Zaretskii
2022-11-01 13:27 ` Theodor Thornhill
2022-11-01 13:49 ` Eli Zaretskii
2022-11-01 13:54 ` Theodor Thornhill
2022-11-01 14:03 ` Eli Zaretskii
2022-11-01 14:12 ` Theodor Thornhill
2022-11-01 16:09 ` tomas
2022-11-01 13:12 ` Manuel Uberti
2022-11-04 14:49 ` Benjamin Riefenstahl
2022-11-04 16:17 ` Pascal Quesseveur
2022-11-01 13:32 ` Stefan Monnier [this message]
2022-11-01 14:02 ` Eli Zaretskii
2022-11-01 15:09 ` Stefan Monnier
2022-11-01 15:36 ` Theodor Thornhill
2022-11-01 16:43 ` Eli Zaretskii
2022-11-02 20:43 ` João Távora
2022-11-01 7:20 ` Eli Zaretskii
2022-11-01 12:10 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvv8nyzv6v.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=dev@rjt.dev \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).