emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]