[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: |
Juri Linkov |
Subject: |
bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode |
Date: |
Mon, 20 Mar 2023 20:13:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) |
>> After trying to tweak treesit-sexp-type-regexp a few times
>> I become convinced it is not up to the task of properly handling
>> all sexp operations. It seems the existing functions that
>> implement C-M-f (forward-sexp), C-M-u (backward-up-list), etc.
>> should remain in place, and the role of the tree-sitter would be
>> only to provide syntax information for them, i.e. just to replace
>> syntax tables with tree-sitter wrappers.
>
> It would be good if you could tell more about what you tried and what
> you saw, and how you reached this quite radical conclusion. Maybe you
> are right, but without knowing the details, how can we possibly
> discuss it and try to reach a common conclusion? Up front, the
> conclusion sounds almost incredible: after all, how can a compiler
> recognize blocks and defuns if not by parsing the program source? If
> the compiler does it, why cannot we do the same using the parsing
> products?
Ideally, the existing syntax tables should still be used, and
tree-sitter could provide an additional support for "implicit parens"
as mentioned in bug#62086. "Implicit parens" are such constructs
that are not defined by syntax tables, but perceived as invisible parens.
> So please consider making the discussion more useful by telling more.
> (Perhaps on emacs-devel, not here.)
I could provide more feedback when someone will start a discussion
on emacs-devel.
- bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, (continued)
- 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, 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, 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 <=
- 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
bug#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode, Yuan Fu, 2023/03/18