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

[Eli Zaretskii <eliz@gnu.org>]

> From: Mickey Petersen <mickey@masteringemacs.org>
> Cc: Yuan Fu <casouri@gmail.com>, 61235@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.