[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Treesit Regression In ec4d29c4494f32acf0ff7c5632a1d951d957f084
From: |
Danny Freeman |
Subject: |
Re: Treesit Regression In ec4d29c4494f32acf0ff7c5632a1d951d957f084 |
Date: |
Mon, 11 Sep 2023 08:41:26 -0400 |
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