emacs-devel
[Top][All Lists]
Advanced

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

Re: Tree sitter support for C-like languages


From: Eli Zaretskii
Subject: Re: Tree sitter support for C-like languages
Date: Mon, 14 Nov 2022 20:45:33 +0200

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

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

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

Thanks.



reply via email to

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