bug#60453: 29.0.60; treesit-range-rules throw an error without tree-sitter

[Wilhelm Kirschbaum <wkirschbaum@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
>> Cc: 60453@debbugs.gnu.org
>> Date: Sat, 31 Dec 2022 18:50:31 +0200
>> 
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
>> >> Date: Sat, 31 Dec 2022 16:53:08 +0200
>> >> 
>> >> 
>> >> With the following code without tree-sitter library:
>> >> 
>> >> (defvar elixir-ts-mode--treesit-range-rules
>> >>   (treesit-range-rules
>> >>    :embed 'heex
>> >>    :host 'elixir
>> >>    '((sigil (sigil_name) @name (:match "^[H]$" @name) 
>> >>    (quoted_content)
>> >>   @heex))))
>> >> 
>> >> upon loading the mode I get the following error:
>> >> 
>> >> treesit-range-rules: Symbol’s function definition is void:
>> >> treesit-query-compile
>> >> 
>> >> This can easily be mitigated with (when 
>> >> (treesit-available-p)...)
>> >> but think it should function similar to how 
>> >> (treesit-font-lock-rules
>> >> work.
>> >
>> > Why does it make sense to protect treesit.el's code with
>> > treesit-available-p?  You aren't supposed to use treesit.el 
>> > functions
>> > when the tree-sitter library is not available.  IOW, Lisp 
>> > programs
>> > that want to use treesit-range-rules and other functions from
>> > treesit.el should make the treesit-available-p test _before_ 
>> > that.
>> 
>> Okay, that makes sense.  I just saw this comment on
>> 
>> ;; treesit.el#618
>> (defun treesit-font-lock-rules (&rest query-specs)
>>   ...
>>   ;; Other tree-sitter function don't tend to be called unless
>>   ;; tree-sitter is enabled, which means tree-sitter must be 
>>   compiled.
>>   ;; But this function is usually call in `defvar' which runs
>>   ;; regardless whether tree-sitter is enabled.  So we need 
>>   this
>>   ;; guard.
>>   (when (treesit-available-p)
>> 
>> As treesit-range-rules also gets called with defvar and it is a
>> consistency issue.  I think the reason why this has not popped 
>> up
>> before is that no other modes I have seen uses 
>> treesit-range-rules
>> yet and think it will probably catch people off guard in the 
>> future.
>
> It's up to Yuan: if he thinks this is a good idea, he should 
> feel free
> to add that test.  But it's slippery slope, IMNSHO: we will very 
> soon
> find ourselves adding such tests to every treesit.el function, 
> just
> because some code somewhere calls that function without a prior 
> test.
> IOW, IMO a single case of such callers is not enough to add a 
> test.
> But that's me.

Okay, I will add the checks before defvar anyways to keep things
consistent on my side.  It does make more sense to me just to not 
have the
guards in the first place as it creates false expectation they 
will be
everywhere.