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

["Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@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.