[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61235: 30.0.50; tree-sit: `treesit-node-check' lacks a way to tell i
From: |
Eli Zaretskii |
Subject: |
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@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.
- 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, 2023/02/02
- bug#61235: 30.0.50; tree-sit: `treesit-node-check' lacks a way to tell if a node belongs to a deleted parser, Yuan Fu, 2023/02/05
- 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, 2023/02/06
- 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, 2023/02/06
- 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 <=
- 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, 2023/02/06
- 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, 2023/02/06
- 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, 2023/02/06
- 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, 2023/02/06
- bug#61235: 30.0.50; tree-sit: `treesit-node-check' lacks a way to tell if a node belongs to a deleted parser, Yuan Fu, 2023/02/06
- 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, 2023/02/06
- bug#61235: 30.0.50; tree-sit: `treesit-node-check' lacks a way to tell if a node belongs to a deleted parser, Yuan Fu, 2023/02/06
- 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, 2023/02/07
- bug#61235: 30.0.50; tree-sit: `treesit-node-check' lacks a way to tell if a node belongs to a deleted parser, Yuan Fu, 2023/02/07
- 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, 2023/02/07