From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Tree sitter support for C-like languages Date: Mon, 14 Nov 2022 11:51:59 -0800 Message-ID: <8BEF109A-A5B3-4CF4-AE07-AEB9388B0A07@gmail.com> References: <87tu36em9t.fsf@thornhill.no> <45FD2F78-F15B-488B-9348-A8E298D8AD35@gmail.com> <87v8nmyqqp.fsf@thornhill.no> <834jv4nz2g.fsf@gnu.org> <871qq8hsj1.fsf@thornhill.no> <83iljklzmo.fsf@gnu.org> <87v8nkgcqj.fsf@thornhill.no> <87sfiogcbm.fsf@thornhill.no> <83pmdrkyj7.fsf@gnu.org> <87v8njw5th.fsf@thornhill.no> <83leofkwjm.fsf@gnu.org> <9E9244D3-2EFB-4621-91E0-FC8B8C1C2D52@gmail.com> <186915C1-1C47-43DC-A386-B447A2E7528D@gmail.com> <83h6z1k6z8.fsf@gnu.org> <52D18BA8-C9A8-4E9A-9DDA-76E48744DDC9@gmail.com> <837czxjrxu.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27986"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 02:43:04 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oukyd-00073W-N3 for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 02:43:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouiin-0002JU-Tc; Mon, 14 Nov 2022 18:18:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouieN-0003HL-Vo for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:14:00 -0500 Original-Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oufUy-0002BA-5L; Mon, 14 Nov 2022 14:52:06 -0500 Original-Received: by mail-pg1-x529.google.com with SMTP id f3so4739744pgc.2; Mon, 14 Nov 2022 11:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HvxdOIG7WPzp9ode2fIt9GxjrafTExh3m5PrXhFay6c=; b=ViYAXHraKgKypWhm9j+ZhehS7fsWuUYfpJQ4MlxuZbATp2HrAgOKNRpUrSNzjeCsu2 AGiasjn5TlDK5av5ITD1kpVo40llXu0ZEkyz9l6SFYyOvHOsFxNYeiw4Vjm1eORcu6G9 WZzwXvvSLOz3mHK1qcLDZzE6j48/neufTrPlziR5Ht7/SmKTJxCAIlAw5zRDwt+sUv8U HAMSjYcWd9YPp6CNeVIM7vqJTQAZuh9W9WNU7FF1zqI94iat0uA+V/1++kqvOH3YEMXI kjukvIHXCqenw7AdhU2rFl/cWWOClCv0JI7PP1aEeeRa0sctuLkwGiDkcqpt9bxKvxDL PGMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HvxdOIG7WPzp9ode2fIt9GxjrafTExh3m5PrXhFay6c=; b=xbQHNfeknq3V7CS17o4JXO9fjbSlz5tbAgVwSnDYg2sHqZ6cu4KXJTGFXIu9cS536u MAYo6qJCNRyEOknJaF2aQs89Y/HgXTlBYxxsoueplP+OA3VM2Tl6kdFI3wIFwuS/c3V6 ZIS12X0YfZc95bgD9xrDsEjdnRPtpzS82y9i24EMBz/4zuqZyeyItKc/XH7Q4ZgF01bK KGCQORnipSG0sWunmVkLEqtGYa84Yk+BhizAxgrR4ZRevn+tONO8prM/D6KP6ZI8m+nA mmLlFtQCPW4tOV3inRhq6+oPOM03pZRLAIzjW01IVj+PC4eNwdNHPz2bh2rmDlXuPigy V8gQ== X-Gm-Message-State: ANoB5pk4eEWxKgVPZ6NZv2Qj1YcfNjKpfHJdW76jUnSGBFkwI5fLwrq7 JdYukypCR1uMSTZynjLQGUwTBJL9arNbwg== X-Google-Smtp-Source: AA0mqf6+SCpl3FMFThSooEM5VZrzvW7dOVweWQJrDptWl+t1ACR5Lobs/8H0IhnxncLICV5UhPH0nw== X-Received: by 2002:aa7:8e59:0:b0:56c:12c0:a89b with SMTP id d25-20020aa78e59000000b0056c12c0a89bmr14875517pfr.40.1668455522046; Mon, 14 Nov 2022 11:52:02 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id f18-20020aa79d92000000b0056e5bce5b7asm7069003pfq.201.2022.11.14.11.52.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2022 11:52:01 -0800 (PST) In-Reply-To: <837czxjrxu.fsf@gnu.org> X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::529; envelope-from=casouri@gmail.com; helo=mail-pg1-x529.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299821 Archived-At: > On Nov 14, 2022, at 10:45 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Mon, 14 Nov 2022 10:29:56 -0800 >> Cc: monnier@iro.umontreal.ca, >> theo@thornhill.no, >> emacs-devel@gnu.org >>=20 >>> 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? =20 >>=20 >> 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 = =E2=80=9Cinsertion in X, deletion from X to Y=E2=80=9D. This is required = by tree-sitter=E2=80=99s API. For this particular node, not updating the = node might be ok, depending on hoe tree-sitter implements things. But of = course we shouldn=E2=80=99t rely on that. >=20 > 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? >=20 >>> And if >>> the text of the node with the error did change, then we do update = the >>> node, don't we? >>=20 >> Well we update the parse tree and re-parse, but we currently don=E2=80=99= 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. >=20 > 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 =E2=80=9Cupdating=E2=80=9D the = tree: const TSInputEdit edit =3D 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 = =E2=80=9Cincremental parsing=E2=80=9D.=20 Tree-sitter nodes needs similar updates, so that it is in sync with the = buffer text. >=20 >>> Please do. We must solve this problem. >>>=20 >>> 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. >>=20 >> I wouldn=E2=80=99t call this a problem. >=20 > 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=E2=80=99t a = problem per se.=20 >=20 >> Let=E2=80=99s not highlight syntax errors for now, and see how it = looks. In the meantime I=E2=80=99ll 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. >=20 > 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 ;-) >=20 >> I don=E2=80=99t think Atom highlight parse errors, neovim disables it = by default. >=20 > We could decide to disable it by default, but let's first see how to > solve the problem, or at least minimize it. Yep. Yuan=