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

Package: emacs;

Reported by: Mickey Petersen <mickey <at> masteringemacs.org>

Date: Thu, 2 Feb 2023 19:47:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 29.1

Done: Yuan Fu <casouri <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: Eli Zaretskii <eliz <at> gnu.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 14:08:46 +0000
Eli Zaretskii <eliz <at> gnu.org> writes:

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




This bug report was last modified 2 years and 95 days ago.

Previous Next


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