From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: Tree sitter support for C-like languages Date: Sun, 13 Nov 2022 10:40:26 +0100 Message-ID: <87v8njw5th.fsf@thornhill.no> References: <87tu36em9t.fsf@thornhill.no> <45FD2F78-F15B-488B-9348-A8E298D8AD35@gmail.com> <87v8nmyqqp.fsf@thornhill.no> <834jv4nz2g.fsf@gnu.org> <871qq8hsj1.fsf@thornhill.no> <83iljklzmo.fsf@gnu.org> <87v8nkgcqj.fsf@thornhill.no> <87sfiogcbm.fsf@thornhill.no> <83pmdrkyj7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38433"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 13 10:41:21 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 1ou9UO-0009n6-5R for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Nov 2022 10:41:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ou9Tl-0005dy-J2; Sun, 13 Nov 2022 04:40:41 -0500 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 1ou9Tj-0005da-R2 for emacs-devel@gnu.org; Sun, 13 Nov 2022 04:40:40 -0500 Original-Received: from out0.migadu.com ([94.23.1.103]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ou9Th-0000li-Cw; Sun, 13 Nov 2022 04:40:39 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668332433; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rWhULWa/0EHaY82QeYTnDKEzmBfKtnsGpS7j7m6JRuI=; b=o6oru1ukOHg35115LjoU4HhENZNsAbtEyDtO8pwilNcKugXDNQn2EL4GD6Hbz2X3Pv5xq8 yJ/TAWIzKzV7o7hJd0+J3NnCOjUL6PPRGEapT3luhr2ZZOFGA42UQ6sHTLWXEIGY1bG9m2 51N0XLp3YCjvL28TAwmyb9RTrP14/ZhfRDvN2wXoJ03+wAp1QnJ9eMMPa/zP9nM4dladTy uZvVQQWrU900W/twCHlubvVmPVoy8EbkL6TlKNTOwoUVT2kMnHrdGNwnMu84R8GhdWZVEs lU9DyvyeiJRLwFF6UfJvJXgbznz3SZEmkuKRva0v9+Cl1naXKOn5kyZGWYLY7A== In-Reply-To: <83pmdrkyj7.fsf@gnu.org> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=94.23.1.103; envelope-from=theo@thornhill.no; helo=out0.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299715 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: Eli Zaretskii , emacs-devel@gnu.org, monnier@iro.umontreal.ca >> Date: Sat, 12 Nov 2022 21:14:21 +0100 >> >> Yuan Fu writes: >> >> >> See new patch here - following Stefans keen eye ;-) >> > >> > Applied and pushed, thanks ;-) >> >> Great news! Thanks, all! > > Thanks. The new C mode looks good, but I have a couple of issues with > it. > Great - thanks for looking. I actually have answers too! > First, something strange is going on when I type new code. Here's a > recipe: > > emacs -Q > C-x C-f newfile.c RET > M-x c-ts-mode RET > Type: > > int > foo (void) > { > > At this point, "int" is in font-lock-warning-face -- why? > If you enable 'treesit-inspect-mode' and put point on 'int', you will see it report the 'ERROR' node. This node is font locked like that because of the font lock rule I added for that case. I think we can remove it, but it does serve some useful purpose. > Next, with point after the brace, type RET -- this doesn't indent 2 > spaces, as I'd expect -- why? Typing TAB to indent doesn't help, > either. > This is because tree-sitter doesn't know what to do with it. if you rather type: ``` int foo (void) {} ``` It will know that it has a complete node and indent accordingly if you press RET while inside the braces. (no-node parent-bol c-ts-mode-indent-offset) Now this indentation should happen as you want, even though we are in an error state syntax-wise. At least after you do what you state just below > I then type "int bar = 0;". Typing RET after that doesn't indent, > either. > This is for the same reason. Adding the closing brace would fix that, or the rule I mentioned. Now my code is indented like this: ``` int foo () { int bar = 0; ``` > But if I add an empty line at BOB, the fontification becomes as > expected, and doesn't go back to font-lock-warning-face even if I then > remove that empty line. > This is likely due to either treesit or tree-sitter or tree-sitter-c not dealing properly with the root node. Maybe Yuan has some insight here? > Type } to close the function. I now have this: > > int > foo (void) > { > int bar = 0; > } > > But "int" is still in font-lock-warning-face -- why? > I think the best solution is just to remove the ``` :language mode :override t :feature 'error '((ERROR) @font-lock-warning-face) ``` > Next, I type this: > > struct foo { > int bar; > }; > > The result is that all of the struct, except the closing brace, is in > font-lock-warning-face -- why? Again, adding an empty line before > that fixes fontifications, and the fontification stays correct even > after removing that empty line. > > If I type > > struct bar > { > int foo; > }; > Same thing. Let's just remove it. I'll add a patch below, feel free to install it. > then the opening brace and "int foo;" are in font-lock-warning-face. > > Next, if I type M-;, I get a C++-style comment delimiter "//". It > sounds like this is the only style of comments supported? More > generally, if I compare c-basic-common-init and c-common-init from CC > Mode with c-ts-mode, I see that the former has much more > initializations than the latter. So I think we should audit what CC > Mode does here and see what else is relevant. Alternatively, we could > consider c-ts-mode be a minor mode of CC Mode, which only changes the > fontification, the indentation, and the navigation parts. > I can take a look at that this evening - and see what else I can come up with. I agree with the comment style > Thanks. > > P.S. If these problems are non-trivial, it might be best to file a bug > report for each one. But the last issue, the one about doing more > stuff like CC Mode does, is something we should discuss here, I think, > since this is basic design, and similar issues could exist for other > modes whose *-ts-mode variants were installed on the branch. Your issues are two-fold. The warning face is super easy, but the indenting of error nodes may need a change of perspective. Tree-sitter works best when syntax is correct, even though it handles errors pretty well. See patch Theo --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Remove-error-node-font-locking.patch >From 8a21833d36239ed61d808064faa78d19d6fc5517 Mon Sep 17 00:00:00 2001 From: Theodor Thornhill Date: Sun, 13 Nov 2022 10:39:56 +0100 Subject: [PATCH] Remove error node font locking * lisp/progmodes/c-ts-mode.el (c-ts-mode--font-lock-settings) (c-ts-mode--base-mode): Error node font locking causes too much noise. --- lisp/progmodes/c-ts-mode.el | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index 5617ea7d7c..7e7b554943 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -326,11 +326,7 @@ c-ts-mode--font-lock-settings :feature 'statement '((expression_statement (identifier) @font-lock-variable-name-face) (labeled_statement - label: (statement_identifier) @font-lock-type-face)) - :language mode - :override t - :feature 'error - '((ERROR) @font-lock-warning-face))) + label: (statement_identifier) @font-lock-type-face)))) (defun c-ts-mode--imenu-1 (node) "Helper for `c-ts-mode--imenu'. @@ -424,7 +420,7 @@ c-ts-mode--base-mode (setq-local treesit-font-lock-feature-list '((comment preprocessor operator constant string literal keyword) (type definition expression statement) - (error)))) + ()))) ;;;###autoload (define-derived-mode c-ts-mode c-ts-mode--base-mode "C" -- 2.34.1 --=-=-=--