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 20:45:33 +0200 [thread overview]
Message-ID: <837czxjrxu.fsf@gnu.org> (raw)
In-Reply-To: <52D18BA8-C9A8-4E9A-9DDA-76E48744DDC9@gmail.com> (message from Yuan Fu on Mon, 14 Nov 2022 10:29:56 -0800)
> 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.
next prev parent reply other threads:[~2022-11-14 18:45 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
2022-11-14 18:29 ` Yuan Fu
2022-11-14 18:45 ` Eli Zaretskii [this message]
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=837czxjrxu.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).