Re: Tree sitter support for C-like languages

[Yuan Fu]

> On Nov 14, 2022, at 10:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 14 Nov 2022 10:29:56 -0800
>> Cc: monnier@iro.umontreal.ca,
>> theo@thornhill.no,
>> emacs-devel@gnu.org
>> 
>>> Sorry, I don't understand: if the node's text did not change, and some
>>> other node (which did change) caused the first node to become
>>> "not-in-error", then why do we need to update the first node?  
>> 
>> Not specific to this node. I was saying that for any node to keep up with 
>> changes made to the buffer text, they need to be updated with “insertion in 
>> X, deletion from X to Y”. This is required by tree-sitter’s API. For this 
>> particular node, not updating the node might be ok, depending on hoe 
>> tree-sitter implements things. But of course we shouldn’t rely on that.
> 
> You mean, we must report the same "insertion in X, deletion from X to
> Y" change more than one time, because more than one node may depend on
> that change?
> 
>>> And if
>>> the text of the node with the error did change, then we do update the
>>> node, don't we?
>> 
>> Well we update the parse tree and re-parse, but we currently don’t update 
>> the nodes created from the old tree. Keeping all nodes updated requires us 
>> to track all live nodes and update them whenever the buffer is edited.
> 
> I guess I still don't understand what exactly do you mean by "update
> the node".  Can you explain that in more detail?

My bad. So when buffer changes (insert in X, delete from X to Y), we inform 
tree-sitter of this change by “updating” the tree:

  const TSInputEdit edit =
    treesit_prepare_input_edit (start_byte, old_end_byte, new_end_byte);

  ts_tree_edit (tree, &edit);

Then when we re-parse, tree-sitter knows which part of the buffer has changed 
and needs to be re-parsed, and only parses those, hence “incremental parsing”. 

Tree-sitter nodes needs similar updates, so that it is in sync with the buffer 
text.

> 
>>> Please do.  We must solve this problem.
>>> 
>>> Btw, do other IDEs that use tree-sitter have the same problem?  I
>>> doubt that, and if I'm right, we cannot afford having this problem in
>>> Emacs.
>> 
>> I wouldn’t call this a problem.
> 
> It's a problem because highlighting in warning face is left on
> display, although the program source is correct and should have been
> highlighted differently.

I agree, I meant that not highlighting syntax errors isn’t a problem per se. 

> 
>> Let’s not highlight syntax errors for now, and see how it looks. In the 
>> meantime I’ll add the feature to track certain nodes for changes. Then if we 
>> decide this is an important feature to have, we can look at how to implement 
>> it.
> 
> If you are working on this issue, we can leave things as they are in
> the meantime.  Having the warning face show will provide motivation
> for solving this ;-)
> 
>> I don’t think Atom highlight parse errors, neovim disables it by default.
> 
> We could decide to disable it by default, but let's first see how to
> solve the problem, or at least minimize it.

Yep.

Yuan