From: Juri Linkov <juri@linkov.net>
To: Yuan Fu <casouri@gmail.com>
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, 01 Oct 2024 20:49:39 +0300 [thread overview]
Message-ID: <86ed4zg1cc.fsf@mail.linkov.net> (raw)
In-Reply-To: <AD87175F-6F83-4D7D-9A00-B2B96CEC7072@gmail.com> (Yuan Fu's message of "Mon, 30 Sep 2024 20:57:36 -0700")
> 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'.
> 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.
next prev parent reply other threads:[~2024-10-01 17:49 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 [this message]
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=86ed4zg1cc.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=73404@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--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).