[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 14:34:44 +0200 |
> 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?
- 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 <=
- 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, 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