Re: Tree sitter support for C-like languages

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Mon, 14 Nov 2022 00:23:20 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  Theodor Thornhill <theo@thornhill.no>,
>  emacs-devel <emacs-devel@gnu.org>
> 
> >> Then when you insert the closing bracket, the parse tree is complete
> >> 
> >> int
> >> foo (void)
> >> {
> >> int bar = 0;
> >> }
> >> 
> >> Int is still in warning face because jit-lock doesn’t know it needs to be
> >> refontified.
> > 
> > Doesn't tree-sitter tell us that the node for `int` has changed?
> 
> Yes and no, but mostly no. Tree-sitter can tell if a node “has changes”. But 
> you need to keep the node updated as the buffer changes, which we currently 
> don’t do.

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?  And if
the text of the node with the error did change, then we do update the
node, don't we?  So what is the problem here, exactly?  Or maybe I
misunderstand what you mean by "update the node"?

> Even if we add this feature, I don’t know if “has changes” includes 
> “previously inside an ERROR node but not anymore”. IIUC “has changes” means 
> “corresponding text edited”. I need to add this feature and experiment with 
> it to figure out what does “has changes” mean exactly.

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.

> Keeping some nodes updated (ie, “watch” those nodes) isn’t too hard to 
> implement, but it wouldn’t be a trivial change. I don’t know if we want to 
> introduce non-trivial changes now.

If there are less invasive changes which could solve this, I agree.
But if this is the only way, we have no choice, I think.  Again, it
would be good to find out how other IDEs solve this.

And don't worry too much about non-trivial changes, we have ample time
before the release of Emacs 29 to find and fix any fallout.

Thanks.