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: Yuan Fu <casouri@gmail.com>
> Date: Sun, 5 Feb 2023 20:24:27 -0800
> Cc: 61235@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> 
> Mickey Petersen <mickey@masteringemacs.org> 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?