From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/tree-sitter: Where to Put C/C++ Stuff Date: Tue, 01 Nov 2022 16:02:45 +0200 Message-ID: <83cza6db7e.fsf@gnu.org> References: <83pme7cf23.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24859"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theo@thornhill.no, emacs-devel@gnu.org, dev@rjt.dev To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 18:15:58 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opurm-0006Eg-F9 for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 18:15:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oprr4-0006gO-Dg; Tue, 01 Nov 2022 10:03:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oprr2-0006gE-AC for emacs-devel@gnu.org; Tue, 01 Nov 2022 10:03:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oprr1-0006bN-IH; Tue, 01 Nov 2022 10:02:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=b5FoLGeOtLIMLGwLXM+q0G/MEX6C+Qq5mXiDItHQXb0=; b=iREUwf0iqhkZ M6ZXa8nstZF7aF8HQA6+yZz5rVYVNYqk9jNAe6VSpVzRsrEH05q8XeGmL8Hq20pxYvKoBYF+EfxWf BzK4A1aSXQKaupJtBYZRlzfRVmWJEVU6wOY3b/Yti/qNRGvszcDKhqpY0DPYdfNXLypuPOPGIgCCS Q5WKTJzGWykzI6arEt8xMQiz7kzdHmqTuh/e917xsUWfcAL9S1Rvqjo+rR86+kUyFTiFQ0rtyXcUP JErzamwfBI7iaIgNYzchL8J2sJbzgh2khq5qu8AJClTzp4TeUjpAaA9Vz6yZdj+tGg6fmIY8+NzPs SrhPZNnc7TcPIoh/NNvGrg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oprr0-0001Dd-BY; Tue, 01 Nov 2022 10:02:58 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 01 Nov 2022 09:32:18 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298947 Archived-At: > From: Stefan Monnier > Cc: Theodor Thornhill , 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.