GNU bug report logs - #62238
30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode

Previous Next

Full log

View this message in rfc822 format

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62238 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no, philipk <at> posteo.net
Subject: bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode
Date: Sat, 18 Mar 2023 17:08:25 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 
>> I see in treesit.el that we set forward-sexp-function to
>> treesit-forward-sexp when treesit-sexp-type-regexp is set by the major
>> mode.  For languages with simple grammars, like C, I think that the
>> current approach that uses the syntax table is simpler and less prone to
>> errors, because the Tree-sitter function is general and should work for
>> every language.  I'd suggest we don't define treesit-sexp-type-regexp in
>> c-ts-mode, at least for C.
>
> I don't understand how you came to that conclusion.  Why would we want
> to use syntax tables when we have a parser at our fingertips?  And if
> "the Tree-sitter function is general and should work for every
> language", as you say (and I agree), why should we refrain from using
> it for C?

Note that basing C-M-x on syntax tables (that is, traditional
forward-sexp) does not completely exclude the use of Tree-sitter, AFAIU.
Here's my thought process: To do its job, C-M-x needs to know about some
code structures such as symbol constituents, strings, comments, and
parenthetical groups.  If in some language or future version of C the
syntax is complex enough that getting the syntax class of a character
requires proper parsing, the Tree-sitter major modes can augment the
syntax table to make C-M-x work correctly.  See
c-ts-mode--syntax-propertize for an example of how Tree-sitter can
augment a buffer's syntax table, if needed.

>
>> For languages like TypeScript, whose grammar is more complex, perhaps
>> forward-sexp does not work very well and using Tree-sitter to implement
>> it gives better results with code that is simpler to understand.
>
> There's a huge advantage of using the same function for all the
> supported languages, because that makes that function better, as it is
> tested in many different situations.
>

I agree that using a single function for every language is great for
simplicity and maintainability but, should it handle every movement
command as well?  My main concern is that a single function
(treesit--navigate-thing) is now being used not only for every language,
but for every structural movement command.  I think that it is difficult
that a single piece of logic can handle all structure movement commands
well.  There's a good chance that the code will end up being complex and
difficult to maintain.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.