GNU bug report logs -
#60453
29.0.60; treesit-range-rules throw an error without tree-sitter
Previous Next
To reply to this bug, email your comments to 60453 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Sat, 31 Dec 2022 15:01:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 31 Dec 2022 15:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Wilhelm
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Sat, 31 Dec 2022 16:38:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 60453 <at> debbugs.gnu.org (full text, mbox):
> From: Wilhelm Kirschbaum <wkirschbaum <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Sat, 31 Dec 2022 17:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 60453 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Wilhelm Kirschbaum <wkirschbaum <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Sat, 31 Dec 2022 17:06:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 60453 <at> debbugs.gnu.org (full text, mbox):
> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
> Cc: 60453 <at> debbugs.gnu.org
> Date: Sat, 31 Dec 2022 18:50:31 +0200
>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Wilhelm Kirschbaum <wkirschbaum <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Sat, 31 Dec 2022 17:28:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 60453 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
>> Cc: 60453 <at> debbugs.gnu.org
>> Date: Sat, 31 Dec 2022 18:50:31 +0200
>>
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Wilhelm Kirschbaum <wkirschbaum <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Mon, 02 Jan 2023 00:21:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 60453 <at> debbugs.gnu.org (full text, mbox):
Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
>>> Cc: 60453 <at> debbugs.gnu.org
>>> Date: Sat, 31 Dec 2022 18:50:31 +0200
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> >> From: Wilhelm Kirschbaum <wkirschbaum <at> 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.
I wonder if we should remove that guard in treesit-font-lock-rules... It
looked like a good idea at the time, but now I can see it creating
confusion going forward.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60453; Package
emacs.
(Tue, 17 Jan 2023 09:42:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 60453 <at> debbugs.gnu.org (full text, mbox):
Yuan Fu <casouri <at> gmail.com> writes:
> Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
>>>> Cc: 60453 <at> debbugs.gnu.org
>>>> Date: Sat, 31 Dec 2022 18:50:31 +0200
>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>> >> From: Wilhelm Kirschbaum <wkirschbaum <at> 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.
>
> I wonder if we should remove that guard in treesit-font-lock-rules... It
> looked like a good idea at the time, but now I can see it creating
> confusion going forward.
I think it’s too late to change treesit-font-lock-rules, maybe we should
add the guard to treesit-range-rules, just to be consistent? We can make
it an convention to add guards to all treesit-xxx-rules functions.
Yuan
This bug report was last modified 2 years and 246 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.