[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tree sitter support for C-like languages

From: Yuan Fu
Subject: Re: Tree sitter support for C-like languages
Date: Mon, 14 Nov 2022 11:51:59 -0800

> 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 

>>> 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.



reply via email to

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