From: Yuan Fu <casouri@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: Dmitry Gutov <dmitry@gutov.dev>, 74963@debbugs.gnu.org
Subject: bug#74963: Ambiguous treesit named and anonymous nodes in ruby-ts-mode
Date: Mon, 23 Dec 2024 19:02:28 -0800 [thread overview]
Message-ID: <4DFCFBC8-A353-48F2-8257-D6CFB155A030@gmail.com> (raw)
In-Reply-To: <87ttb0rwni.fsf_-_@mail.linkov.net>
> On Dec 18, 2024, at 11:18 PM, Juri Linkov <juri@linkov.net> wrote:
>
> [This is a separate bug report from bug#73404]
>
>>> While testing treesit-forward-sexp-list, I discovered that
>>> thing-navigation functions are not restricted to named nodes.
>>>
>>> I wonder if there a reason to find anonymous nodes as things?
>>
>> We should rather ask is there any reason to not find anonymous nodes
>> as things? Even ruby-ts-mode defines a bunch of anonymous nodes as
>> sexp, no? In any case, excluding anonymous nodes from things doesn’t
>> sound right.
>
> Indeed, there are many anonymous nodes used in ruby-ts-mode.
>
>>> The problem was found with the node "unless" in Ruby:
>>>
>>> unless cond
>>> a += 1
>>> else
>>> b -= 1
>>> end
>>>
>>> Here the named node 'unless' has exactly the same name
>>> as the anonymous node with the text "unless":
>>>
>>> (unless "unless" condition: (identifier)
>>
>> I feel like Ruby’s grammar should call the named node something else,
>> like unless_statement.
>
> Agreed, the problem is that nodes defined in Ruby’s grammar
> are too ambiguous. There are more such nodes with the same name
> for named and anonymous: "if", "while", "until", etc.
>
>>> Finding anonymous nodes breaks forward-sexp when point is on "unless":
>>>
>>> un-!-less cond
>>> a += 1
>>> else
>>> b -= 1
>>> end
>>>
>>> because (treesit-thing-at (point) 'sexp t) finds
>>>
>>> #<treesit-node "unless" in 156-162>
>>>
>>> instead of
>>>
>>> #<treesit-node unless in 156-203>
>>>
>>> Also this breaks backward-sexp and backward-up-list
>>> because treesit--thing-sibling finds
>>> the anonymous node "unless" as a previous sibling
>>> instead of the named node 'unless' as a parent.
>>>
>>> Would the right solution be to check if the found thing
>>> is a named node? With something like:
>>>
>>> diff --git a/lisp/treesit.el b/lisp/treesit.el
>>> index 18200acf53f..9ad879ee40c 100644
>>> --- a/lisp/treesit.el
>>> +++ b/lisp/treesit.el
>>> @@ -2711,6 +2774,7 @@ treesit--thing-sibling
>>> (lambda (n) (>= (treesit-node-start n) pos))))
>>> (iter-pred (lambda (node)
>>> (and (treesit-node-match-p node thing t)
>>> + (treesit-node-check node 'named)
>>> (funcall pos-pred node))))
>>> (sibling nil))
>>> (when cursor
>>> @@ -2760,6 +2824,7 @@ treesit-thing-at
>>> (let* ((cursor (treesit-node-at pos))
>>> (iter-pred (lambda (node)
>>> (and (treesit-node-match-p node thing t)
>>> + (treesit-node-check node 'named)
>>> (if strict
>>> (< (treesit-node-start node) pos)
>>> (<= (treesit-node-start node) pos))
>>
>> A better solution IMO is to add some way to distinguish between named and
>> anonymous nodes. I can think of two ways, either add “and” and
>> “named/anonymous” predicate, so (and named “unless”) only matches the named
>> “unless” node; or we add a special syntax such that “(unless)” only matches
>> named nodes, and “\”unless\”” only matches anonymous nodes.
>
> Either predicate or a special syntax is welcome.
>
> This would be more handy than writing a lambda with implicit calls
> of treesit-node-check.
I’ll go with the (and named “unless”) route because after thinking about it more, “(unless)” will be hard to work with because the string predicate is actually a regexp.
Yuan
next prev parent reply other threads:[~2024-12-24 3:02 UTC|newest]
Thread overview: 49+ 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
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
2024-12-14 18:14 ` Juri Linkov
2024-12-18 7:37 ` Juri Linkov
2024-12-19 4:04 ` Yuan Fu
2024-12-19 7:14 ` Juri Linkov
2024-12-19 7:18 ` bug#74963: Ambiguous treesit named and anonymous nodes in ruby-ts-mode Juri Linkov
2024-12-24 3:02 ` Yuan Fu [this message]
2024-12-24 7:17 ` Juri Linkov
2024-12-24 7:41 ` Juri Linkov
2024-12-25 3:25 ` Dmitry Gutov
2024-12-25 7:52 ` Juri Linkov
2024-12-24 17:52 ` Juri Linkov
2024-12-24 21:03 ` Yuan Fu
2024-12-25 7:49 ` Juri Linkov
2024-12-25 9:11 ` Yuan Fu
2024-12-19 7:34 ` bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes Juri Linkov
2024-12-24 19:05 ` Juri Linkov
2024-12-24 21:14 ` Yuan Fu
2024-12-25 7:44 ` Juri Linkov
2024-12-25 8:34 ` Yuan Fu
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DFCFBC8-A353-48F2-8257-D6CFB155A030@gmail.com \
--to=casouri@gmail.com \
--cc=74963@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=juri@linkov.net \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.