From: Eli Zaretskii <eliz@gnu.org>
To: Yuan Fu <casouri@gmail.com>
Cc: monnier@iro.umontreal.ca, theo@thornhill.no, emacs-devel@gnu.org
Subject: Re: Tree sitter support for C-like languages
Date: Mon, 14 Nov 2022 15:20:43 +0200 [thread overview]
Message-ID: <83h6z1k6z8.fsf@gnu.org> (raw)
In-Reply-To: <186915C1-1C47-43DC-A386-B447A2E7528D@gmail.com> (message from Yuan Fu on Mon, 14 Nov 2022 00:23:20 -0800)
> 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.
next prev parent reply other threads:[~2022-11-14 13:20 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 17:45 Tree sitter support for C-like languages Theodor Thornhill via Emacs development discussions.
2022-11-10 18:03 ` Stefan Monnier
2022-11-10 18:18 ` Eli Zaretskii
2022-11-10 18:19 ` Theodor Thornhill
2022-11-10 22:58 ` Yuan Fu
2022-11-11 5:48 ` Theodor Thornhill
2022-11-11 6:01 ` Theodor Thornhill via Emacs development discussions.
2022-11-12 5:43 ` Yuan Fu
2022-11-12 6:13 ` Po Lu
2022-11-12 6:17 ` Yuan Fu
2022-11-12 6:43 ` Po Lu
2022-11-12 6:16 ` Theodor Thornhill
2022-11-12 6:25 ` Yuan Fu
2022-11-12 6:37 ` Theodor Thornhill
2022-11-12 8:08 ` Eli Zaretskii
2022-11-12 8:42 ` Theodor Thornhill
2022-11-12 7:22 ` Theodor Thornhill via Emacs development discussions.
2022-11-12 8:05 ` Eli Zaretskii
2022-11-12 8:43 ` Theodor Thornhill
2022-11-12 12:21 ` Eli Zaretskii
2022-11-12 19:38 ` Theodor Thornhill via Emacs development discussions.
2022-11-12 19:46 ` Stefan Kangas
2022-11-12 20:03 ` Theodor Thornhill
2022-11-12 19:51 ` Eli Zaretskii
2022-11-12 20:05 ` Theodor Thornhill via Emacs development discussions.
2022-11-12 20:08 ` Yuan Fu
2022-11-12 20:14 ` Theodor Thornhill
2022-11-13 9:13 ` Eli Zaretskii
2022-11-13 9:40 ` Theodor Thornhill
2022-11-13 9:56 ` Eli Zaretskii
2022-11-13 10:13 ` Theodor Thornhill
2022-11-13 12:55 ` Eli Zaretskii
2022-11-13 13:02 ` Theodor Thornhill
2022-11-13 13:08 ` Eli Zaretskii
2022-11-13 13:37 ` Theodor Thornhill
2022-11-14 1:23 ` Dmitry Gutov
2022-11-14 0:22 ` Yuan Fu
2022-11-14 1:26 ` Dmitry Gutov
2022-11-14 8:35 ` Yuan Fu
2022-11-14 13:24 ` Eli Zaretskii
2022-11-14 18:31 ` Yuan Fu
2022-11-14 19:54 ` Dmitry Gutov
2022-11-15 10:56 ` Yuan Fu
2022-11-15 12:30 ` Dmitry Gutov
2022-11-14 3:48 ` Stefan Monnier
2022-11-14 8:23 ` Yuan Fu
2022-11-14 12:46 ` Stefan Monnier
2022-11-14 13:20 ` Eli Zaretskii [this message]
2022-11-14 18:29 ` Yuan Fu
2022-11-14 18:45 ` Eli Zaretskii
2022-11-14 19:51 ` Yuan Fu
2022-11-14 20:10 ` Eli Zaretskii
2022-11-14 21:57 ` Yuan Fu
2022-11-15 3:27 ` Eli Zaretskii
2022-11-15 10:51 ` Yuan Fu
2022-11-15 11:37 ` Theodor Thornhill
2022-11-15 15:03 ` Eli Zaretskii
2022-11-15 16:01 ` Stefan Monnier
2022-11-15 16:59 ` Eli Zaretskii
2022-11-15 18:18 ` Yuan Fu
2022-11-15 18:38 ` Eli Zaretskii
2022-11-16 7:58 ` Yuan Fu
2022-11-16 13:16 ` Eli Zaretskii
2022-11-16 13:29 ` Po Lu
2022-11-16 17:29 ` Yuan Fu
2022-11-15 18:27 ` Visuwesh
2022-11-15 18:36 ` Yuan Fu
2022-11-14 12:55 ` Eli Zaretskii
2022-11-11 0:43 ` Randy Taylor
2022-11-11 5:50 ` Theodor Thornhill
2022-11-11 13:37 ` Stefan Monnier
2022-11-11 15:09 ` Theodor Thornhill
2022-11-11 15:54 ` Randy Taylor
2022-11-13 8:37 ` Theodor Thornhill
2022-11-13 13:03 ` Randy Taylor
2022-11-16 17:51 ` Yuan Fu
2022-11-16 20:02 ` Theodor Thornhill
2022-11-16 20:10 ` Yuan Fu
2022-11-16 20:25 ` Theodor Thornhill
2022-11-16 20:58 ` Yuan Fu
2022-11-21 9:28 ` Yuan Fu
2022-11-21 11:15 ` Theodor Thornhill
2022-11-23 1:55 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83h6z1k6z8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).