bug#74612: 30.0.90; [PATCH] Allow passing nil to treesit-node-match-p

[Yuan Fu]

> On Dec 5, 2024, at 1:43 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 74612@debbugs.gnu.org
>> Date: Sun, 01 Dec 2024 11:59:58 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>>> From: Yuan Fu <casouri@gmail.com>
>>> Date: Sun, 1 Dec 2024 00:31:05 -0800
>>> Cc: 74612@debbugs.gnu.org
>>> 
>>> 
>>> 
>>>> On Nov 29, 2024, at 11:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> 
>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>> Date: Fri, 29 Nov 2024 16:38:22 -0800
>>>>> 
>>>>> Eli, are you ok with this patch on emacs-30? Almost all tree-sitter node 
>>>>> functions allows user to pass nil for NODE, so treesit-node-match-p 
>>>>> should too.
>>>> 
>>>> Does this solve an actual problem you've seen somewhere (and if so,
>>>> which problem), or does it solve a potential problem that didn't
>>>> actually happen yet?
>>> 
>>> I encountered this problem (more like an inconvenience, since without this 
>>> feature I’d need to test for nullness before passing a node to 
>>> treesit-node-match-p) when using treesit-node-match-p for some new code I’m 
>>> writing for master branch. Since (treesit-node-match-p node “type name”) is 
>>> easier to write and shorter than (equal (treesit-node-type node) “type 
>>> name”) or (string-match-p “type name regex” (treesit-node-type node)), I’ve 
>>> been using it liberally in new code :)
>>> 
>>>> 
>>>> Also, does CHECK_TS_NODE allow nil or does it currently signal an
>>>> error?
>>> 
>>> CHECK_TS_NODE currently signals an error. All the tree-sitter node 
>>> functions that accepts nil has the "if (NILP (node)) return Qnil” line 
>>> before CHECK_TS_NODE (or treesit_check_node)
>>> 
>>> If you’re not too comfortable with the change, we can apply it to master. 
>>> It wouldn’t create any backward-incompatibility since this change makes 
>>> treesit-node-match-p more lenient on its argument, not stricter. The 
>>> drawback is treesit-node-match-p will be a bit more annoying to use.
>> 
>> OK, please install on emacs-30, and thanks.
> 
> I see you did, so I'm closing this bug.

Thank you Eli.