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: Tue, 1 Oct 2024 23:14:15 -0700 [thread overview]
Message-ID: <08933A47-CCCD-4317-9EEA-DCB0C1D9E544@gmail.com> (raw)
In-Reply-To: <86ed4zg1cc.fsf@mail.linkov.net>
> On Oct 1, 2024, at 10:49 AM, Juri Linkov <juri@linkov.net> wrote:
>
>> 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?
>
> I tried to do something like this, and everything works nicely with:
>
> @@ -2289,11 +2289,10 @@ treesit-forward-sexp
> (node-at-point
> (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))
> + (or (treesit-node-match-p node-at-point 'text t)
> + (not (treesit-thing-at
> + (if (> arg 0) (point) (1- (point)))
> + (treesit-thing-definition 'sexp nil)))))
> (forward-sexp-default-function arg)
> t)
> (if (> arg 0)
>
> The new logic is the following: if there is no sexp thing defined at point,
> then fall back to 'forward-sexp-default-function'.
>
> Then after (setq js--treesit-sexp-nodes '("binary_expression"))
> 'C-M-f' in e.g.
>
> export const add = (a, b) => -!-a + b;
>
> moves point to
>
> export const add = (a, b) => a + b-!-;
>
> The condition (if (> arg 0) (point) (1- (point))) above
> is necessary to allow 'C-M-b' to move back to:
>
> export const add = (a, b) => -!-a + b;
>
> Also the condition to make sure point is strictly inside node
> was removed to handle the case when point was at the beginning
> of the buffer:
>
> -!-
> export const add = (a, b) => a + b;
>
> to move after
>
> export-!- const add = (a, b) => a + b;
>
> by 'forward-sexp-default-function'.
Sounds good. Feel free to install on master if you think it works well :-)
>
>> 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?
>
> I think we need to support both ways:
>
> 1. opt-out - where sexp-thing definition is used by default,
> and only text-thing allows users to override it;
>
> 2. opt-in - where 'forward-sexp-default-function' is used by default,
> and user can explicitly define what sexp-things are preferable
> for navigation by treesit.
>
> Then in the latter case the users could prefer to use
> treesit sexp navigation only for constructions with
> "invisible parens". For example, in Ruby there are
> two interchangeable syntaxes for code blocks:
>
> 1. curly braces {...} that are already handled
> by 'forward-sexp-default-function';
>
> 2. do...end that can't be handled by 'forward-sexp-default-function',
> so treesit is coming to the rescue for the case of such
> implicit braces.
Sounds good to me, I wonder if there are clever way to implement this. If there isn’t, we’d need to define two sets treesit-sexp functions and add a custom option to control which one to use. Seems a bit clunky to me.
Yuan
next prev parent reply other threads:[~2024-10-02 6:14 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
2024-10-01 17:49 ` Juri Linkov
2024-10-02 6:14 ` Yuan Fu [this message]
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=08933A47-CCCD-4317-9EEA-DCB0C1D9E544@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).