From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tree sitter support for C-like languages Date: Mon, 14 Nov 2022 20:45:33 +0200 Message-ID: <837czxjrxu.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11963"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, theo@thornhill.no, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 02:39:51 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 1oukvW-0002wf-HJ for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 02:39:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouijW-0003dL-9x; Mon, 14 Nov 2022 18:19:18 -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 1ouieT-0002HE-Le for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:14:05 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oueSQ-0001YK-Cd; Mon, 14 Nov 2022 13:45:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=zxB6fDF/FDlaNf6X2cczHlPalw4Plh7cUg39diz8ZB4=; b=K0q6/vwc+VApqr6e8WhZ k2TFZtfBS3Rz7l3asHrMQZKQLjjzcXxSFSH6yI1DnEtKhaENa6rFhDNrhq2jb4746TPCwoRoKyS01 i2GOuzNL8g/8Nt92PfjQ8vh/OA92l2It4BUdGBuupmIjvqJmFb0jYi75mDr116rThgibddYZGtcJ+ aN/VKc7PEcAqcwaTRB/CZRXfcHwbpGjw1yb2J6703RiyRVMxyHgqiKBzPdDGMAkhC2SpssMZUUcuw kt5rqeQ7i7yTZpuGW47TiECihZ+yEkDPf8sLgLrz8N/NAPfuVssNeKewXdsOZ6y+586oLrDbEe4XY s9f65ouBjg1D8A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oueSP-0001Hn-FH; Mon, 14 Nov 2022 13:45:22 -0500 In-Reply-To: <52D18BA8-C9A8-4E9A-9DDA-76E48744DDC9@gmail.com> (message from Yuan Fu on Mon, 14 Nov 2022 10:29:56 -0800) 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:299820 Archived-At: > From: Yuan Fu > 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.