GNU bug report logs - #61235
30.0.50; tree-sit: `treesit-node-check' lacks a way to tell if a node belongs to a deleted parser

Previous Next

Full log

Message #17 received at 61235 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: casouri <at> gmail.com, 61235 <at> debbugs.gnu.org
Subject: Re: 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 15:19:23 +0200

> From: Mickey Petersen <mickey <at> masteringemacs.org>
> Cc: Yuan Fu <casouri <at> gmail.com>, 61235 <at> debbugs.gnu.org
> Date: Mon, 06 Feb 2023 12:35:20 +0000
> 
> > 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.
> >
> 
> Because node references are retained even after a parser is deleted.
> 
> Retrieving a node; somehow deleting the parser (maybe you closed the
> buffer, or you were doing some off-hand parsing); and then doing
> _anything_ with the aforementioned node yields an error for which
> there is no way to test for.
> 
> This is particularly the case when you mix and match parsers in the
> same buffer.

I'm asking why the Lisp program cannot track the parsers its uses and
deletes, and instead expects the core to do the janitor's job for it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.