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

[Mickey Petersen <mickey@masteringemacs.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mickey Petersen <mickey@masteringemacs.org>
>> Cc: casouri@gmail.com, 61235@debbugs.gnu.org
>> Date: Mon, 06 Feb 2023 13:19:57 +0000
>>
>> > 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.
>>
>> Because I have a proxy-like object of a real node because they're
>> invalidated if a buffer is edited, even if the parcel of code I hold a
>> node reference to is untouched. That's just how tree-sitter works, so
>> I deal with it like this. That part works fine for I can of course use
>> `treesit-node-check' to determine if it's outdated and thus needs
>> refreshing (or not.)
>>
>> The problems begin when the parser is also, for one reason or another,
>> destroyed.
>
> But it is only destroyed if your program calls treesit-parser-delete,
> no?
>
> Anyway, I'm okay with exposing treesit_check_parser to Lisp, if you
> really insist.  But please be sure you want to insist, because I'm not
> really convinced.

All I want is a way for treesit-node-check to tell me if the node
belongs to a dead or alive parser. It is already capable of telling me
if a node is outdated, for instance, another rather important feature.
Knowing its status is pertinent if you do any sort of light
refactoring or if you end up destroying a block of code that has its
own nested parser.

Whether I destroy a parser explicitly (which is how I found the issue)
or indirectly (through some other mechanism) is, I think, orthogonal
to the problem of determining liveness (of a node, of a process, or
any of the `xxxxxx-live-p' functions we presently have)

Thanks,

Mickey