From: Danny Freeman <danny@dfreeman.email>
To: Yuan Fu <casouri@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Treesit Regression In ec4d29c4494f32acf0ff7c5632a1d951d957f084
Date: Mon, 11 Sep 2023 08:41:26 -0400 [thread overview]
Message-ID: <87o7i898af.fsf@dfreeman.email> (raw)
In-Reply-To: <945F818F-AA9B-402B-BCC7-53286EAD2C05@gmail.com>
Yuan Fu <casouri@gmail.com> writes:
>> I take that back. It is indeed caused by that commit. I just had a wrong Emacs build when testing. In that commit, ts_tree_cursor_goto_first_child_for_byte seem to be the problem.
Well I'm glad to know I am capable of building Emacs with the latest
tree sitter. Not as glad that the problem still exists lol
> What I found is that, for some reason, ts_tree_cursor_goto_first_child_for_byte doesn’t always work
> as expected in clojure [1]. In your example, if I evaluate (treesit-node-parent (treesit-node-at
> (point))) with point at the beginning of “defn”, “foo”, “[]”, and “1”, only “defn” correctly
> evaluates to the parent node. I tried this in other modes like c-ts-mode, but things seems to work
> fine in all the few cases I tried.
>
> So now the question is, is there anything tree-sitter-clojure does differently? Not saying it does, but that seems like a starting point.
Maybe there is. The grammar has not changed in a couple months, and
those things that did change were related to keyword literals, which are
not involved in the example I've been using to reproduce this.
Even knowing that. I will try to narrow the problem down even further,
and see if I can find another grammar the exhibits this behavior.
> [1] Instead of returning the first child node of NODE that extends beyond POS, ts_tree_cursor_goto_first_child_for_byte (NODE, POS) returns false (meaning not found).
I remember we found an issue with a similarly named function here
https://github.com/tree-sitter/tree-sitter/issues/2012
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60127
You ended up writing a workaround in emacs for this called
treesit_cursor_first_child_for_byte
I don't think there is overlap between that change and this ec4d29 one.
However, maybe there is overlap in the tree-sitter implementation? I'm
not sure how to tell right now, but maybe this is an upstream
tree-sitter problem that is just brought into the light by the commit in
question here.
--
Danny Freeman
next prev parent reply other threads:[~2023-09-11 12:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 19:26 Treesit Regression In ec4d29c4494f32acf0ff7c5632a1d951d957f084 Danny Freeman
2023-09-10 1:15 ` Yuan Fu
2023-09-10 4:00 ` Danny Freeman
2023-09-10 5:26 ` Yuan Fu
2023-09-10 7:12 ` Yuan Fu
2023-09-11 12:41 ` Danny Freeman [this message]
2023-09-11 22:19 ` Yuan Fu
2023-09-12 3:49 ` Danny Freeman
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=87o7i898af.fsf@dfreeman.email \
--to=danny@dfreeman.email \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.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 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.