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.bugs Subject: bug#61235: 30.0.50; tree-sit: `treesit-node-check' lacks a way to tell if a node belongs to a deleted parser Date: Mon, 06 Feb 2023 14:34:44 +0200 Message-ID: <83edr3q8ez.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31876"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61235@debbugs.gnu.org, mickey@masteringemacs.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 06 13:35:48 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pP0ip-00086K-RE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Feb 2023 13:35:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pP0ic-0004KN-9Y; Mon, 06 Feb 2023 07:35:34 -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 1pP0i7-000496-08 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2023 07:35:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pP0i6-0000x9-M2 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2023 07:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pP0i6-00060G-79 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2023 07:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2023 12:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61235 X-GNU-PR-Package: emacs Original-Received: via spool by 61235-submit@debbugs.gnu.org id=B61235.167568688323047 (code B ref 61235); Mon, 06 Feb 2023 12:35:02 +0000 Original-Received: (at 61235) by debbugs.gnu.org; 6 Feb 2023 12:34:43 +0000 Original-Received: from localhost ([127.0.0.1]:47539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pP0hn-0005zd-D6 for submit@debbugs.gnu.org; Mon, 06 Feb 2023 07:34:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pP0hm-0005zN-6V for 61235@debbugs.gnu.org; Mon, 06 Feb 2023 07:34:42 -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 1pP0hg-0000tC-Bx; Mon, 06 Feb 2023 07:34:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MOH48D7LkArLHpREmJrFzIODnnw21qXHHvEz8zpspxU=; b=ECUiZKpQYrZ2 fPMOm2ehKGyFDMZnpyh4kY0MTqyF8U0zGHcpqDzUQmrAcn07LmBvv8czQWWIhqFfOIsfLz24B3cTM eMx49wx2e4/GFXwY15cIte0zRNe61JKTWIVlHczKyTjLQNUnjIPz9Iz62C6HrOym072bOfXnC4bFd 6dMTbr3MDll8zBKgCzhdTDr+g/5dFPfICYvxMAwjRS2BaxyyoL86vpbddbfm/hE02k/CFAt1PokAz 0SrMNKKjZMiJj4r8vEj1CAI0t8QqOFbdigGzKz2KSAODfo7mbeRuZR9nRrVymKOAqZ4agrz2sbbVY 6jXiT9/9o2jeE3UkDQ8PvQ==; 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 1pP0hc-0007fX-Bq; Mon, 06 Feb 2023 07:34:35 -0500 In-Reply-To: (message from Yuan Fu on Sun, 5 Feb 2023 20:24:27 -0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254953 Archived-At: > From: Yuan Fu > Date: Sun, 5 Feb 2023 20:24:27 -0800 > Cc: 61235@debbugs.gnu.org, > Eli Zaretskii > > Mickey Petersen writes: > > > There's no way to tell if a node belongs to a now-deleted > > parser. Checking if it is `missing' or `outdated' returns nil; there > > is no way to ascertain this state except by catching an error if you > > try to get its node text, type, etc. > > That sounds reasonable. I can add treesit-parser-live-p, and add > a "live" PROPERTY to treesit-node-check. I'm not sure I understand the need. AFAIU, a parser is deleted only if we call treesit-parser-delete; are we saying that a Lisp program doesn't know that it deleted a parser? What exactly is the practical situation where this problem happens, and why? Frankly, I don't think we should at this stage add APIs without a very good reason. We should instead collect experience, both from users and from Lisp programs, and analyze them before deciding whether more APIs are necessary. > +DEFUN ("treesit-parser-live-p", > + Ftreesit_parser_live_p, Streesit_parser_live_p, 1, 1, 0, > + doc: /* Check whether PARSER is not deleted and its buffer is live. */) > + (Lisp_Object parser) > +{ > + treesit_check_parser (parser); > + if (XTS_PARSER (parser)->deleted) > + return Qnil; > + else if (NILP (Fbuffer_live_p (XTS_PARSER (parser)->buffer))) > + return Qnil; > + else > + return Qt; > +} Doesn't treesit_check_parser signal an error if the parser was deleted? If so, how will the above be useful, if someone wants to avoid errors?