[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mo
From: |
Theodor Thornhill |
Subject: |
bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode |
Date: |
Sat, 18 Mar 2023 14:41:57 +0100 |
On 18 March 2023 14:33:49 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> Cc: 62238@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>,
>> theodor thornhill <theo@thornhill.no>
>> Date: Sat, 18 Mar 2023 13:11:15 +0100
>> From: Daniel Martín via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> > You need to enable c-ts-mode first, which redirects
>> > forward-sexp-function to treesit-forward-sexp.
>>
>> 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?
>
>> 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.
>
>So I don't think I agree with you here, not at all.
Yeah but I need some more time, or at least some patches to look at :)
Theo
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Philip Kaludercic, 2023/03/17
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Theodor Thornhill, 2023/03/17
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Yuan Fu, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Daniel Martín, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Daniel Martín, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Theodor Thornhill, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Eli Zaretskii, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode,
Theodor Thornhill <=
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Daniel Martín, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Daniel Martín, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Eli Zaretskii, 2023/03/18
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Juri Linkov, 2023/03/19
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Eli Zaretskii, 2023/03/19
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Juri Linkov, 2023/03/20
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Juri Linkov, 2023/03/29
bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Kévin Le Gouguec, 2023/03/18