From: Yuan Fu <casouri@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: Eli Zaretskii <eliz@gnu.org>,
Mickey Petersen <mickey@masteringemacs.org>,
73404@debbugs.gnu.org
Subject: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes
Date: Mon, 30 Sep 2024 20:57:36 -0700 [thread overview]
Message-ID: <AD87175F-6F83-4D7D-9A00-B2B96CEC7072@gmail.com> (raw)
In-Reply-To: <86ikueiekp.fsf@mail.linkov.net>
> On Sep 29, 2024, at 9:56 AM, Juri Linkov <juri@linkov.net> wrote:
>
>> Note that you can affect the behavior of tree-sitter sexp movement by
>> defining the sexp “thing” in treesit-thing-settings. Js-ts-mode defines one
>> (js--treesit-sexp-nodes) and it only consider some nodes as sexp. You might
>> be able to tweak the sexp movement to your liking by changing it, or
>> directly modifying the definition for `sexp’ in treesit-thing-settings.
>>
>>>> Do you think the examples I listed in the original bug report match
>>>> your expectations? If so, then it is probably OK to close the bug report.
>>>
>>> Yes, I do, but let's wait for others to chime in if they have opinions
>>> on this.
>
> Here are some ideas how to cover more use cases.
>
> Suppose that a user wants to disable tree-sitter sexp movement
> completely to use the default forward-sexp-default-function.
> The natural way to do this would be set the list of nodes to nil:
>
> (setq js--treesit-sexp-nodes nil)
>
> However, this currently doesn't work, and requires a change like this:
>
> @@ -2290,10 +2290,12 @@ treesit-forward-sexp
> (treesit-node-at (point) (treesit-language-at (point)))))
> (or (when (and node-at-point
> ;; Make sure point is strictly inside node.
> - (< (treesit-node-start node-at-point)
> - (point)
> - (treesit-node-end node-at-point))
> - (treesit-node-match-p node-at-point 'text t))
> + (<= (treesit-node-start node-at-point)
> + (point)
> + (treesit-node-end node-at-point))
> + (or (treesit-node-match-p node-at-point 'text t)
> + (not (treesit-node-match-p node-at-point 'sexp t))
> + ))
> (forward-sexp-default-function arg)
> t)
> (if (> arg 0)
>
> Now, the next case: what if the user wants to use the default
> forward-sexp-default-function except for the 'binary_expression'
> like "a + b" where `C-M-f' should move from "a" to the end of "b":
>
> export const add = (a, b) => -!-a + b;
>
> should move to
>
> export const add = (a, b) => a + b;
>
> ^1
>
> The best way for the user would be to customize:
>
> (setq js--treesit-sexp-nodes '("binary_expression"))
>
> But this is not yet handled by the condition above:
>
> (not (treesit-node-match-p node-at-point 'sexp t))
>
> because 'node-at-point' is "identifier".
> So we need to use 'treesit-parent-until'
> to check if all parent nodes match
> 'js--treesit-sexp-nodes'. Then it will find
> the parent "binary_expression".
>
> I believe something like this will make
> treesit-forward-sexp more customizable.
The user can modify treesit-thing-settings to alter the behavior of sexp navigation, they don’t necessarily need to use js--treesit-sexp-nodes. Maybe we should add a test for (treesit-thing-defined-p 'sexp nil) in treesit-forward-sexp?
Your second example sounds useful, but right now the premise of tree-sitter sexp movement is to use the parse tree primarily, and only use the default sexp movement for comments and strings. What you envisioned seems to be the other way around: use default sexp movement by default, and only use tree-sitter movement under certain conditions. Is that few lines of change able to make such big difference in the logic?
Yuan
next prev parent reply other threads:[~2024-10-01 3:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-21 5:06 bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes Mickey Petersen
2024-09-26 7:42 ` Yuan Fu
2024-09-26 9:56 ` Mickey Petersen
2024-09-26 10:53 ` Eli Zaretskii
2024-09-26 12:13 ` Mickey Petersen
2024-09-26 13:46 ` Eli Zaretskii
2024-09-26 15:21 ` Mickey Petersen
2024-09-26 15:45 ` Eli Zaretskii
2024-09-27 5:43 ` Yuan Fu
2024-09-29 16:56 ` Juri Linkov
2024-10-01 3:57 ` Yuan Fu [this message]
2024-10-01 17:49 ` Juri Linkov
2024-10-02 6:14 ` Yuan Fu
2024-12-05 18:52 ` Juri Linkov
2024-12-05 19:53 ` Juri Linkov
2024-12-10 17:20 ` Juri Linkov
2024-12-11 6:31 ` Yuan Fu
2024-12-11 15:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-11 15:29 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-11 16:50 ` Mickey Petersen
2024-12-11 18:27 ` Yuan Fu
2024-12-12 7:17 ` Juri Linkov
2024-12-12 7:40 ` Eli Zaretskii
2024-12-12 7:58 ` Juri Linkov
2024-12-12 8:14 ` Juri Linkov
2024-12-12 16:31 ` Juri Linkov
2024-12-12 17:49 ` Juri Linkov
2024-12-12 19:13 ` Eli Zaretskii
2024-12-13 7:06 ` Juri Linkov
2024-12-14 11:02 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AD87175F-6F83-4D7D-9A00-B2B96CEC7072@gmail.com \
--to=casouri@gmail.com \
--cc=73404@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
--cc=mickey@masteringemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).