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

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: casouri@gmail.com,  62238@debbugs.gnu.org,  philipk@posteo.net,
>   theo@thornhill.no
> Date: Sat, 18 Mar 2023 17:08:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

We have already C mode that uses syntax tables.  I think it's useful
to try syntactic movement using results of parsing as well, and
compare the relative merits and demerits.

> > 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.

Instead of deciding up front that it could be a problem, I suggest to
try the tree-sitter based way and see how well it works.  We can
always go back to syntax tables if we decide they will work better for
some modes.  It makes little sense to me to make such decisions
without trying the tree-sitter way and trying it well.