From: Yuan Fu <casouri@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: Re: master 09b5f00613: ; Fix calls to treesit functions
Date: Sun, 18 Dec 2022 15:02:14 -0800 [thread overview]
Message-ID: <47D9ABEB-EA9C-49DA-BC35-189A563DEC10@gmail.com> (raw)
In-Reply-To: <jwvbko0xy99.fsf-monnier+emacs@gnu.org>
> On Dec 18, 2022, at 12:19 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> +(declare-function treesit-available-p "treesit.c")
>> (declare-function treesit-parser-list "treesit.c")
>> (declare-function treesit-node-type "treesit.c")
>>
>> @@ -156,7 +157,8 @@ or follows point."
>> (interactive "P")
>> (save-excursion
>> (let ((treesit-text-node
>> - (and (treesit-parser-list)
>> + (and (treesit-available-p)
>> + (treesit-parser-list)
>
> How 'bout always defining `treesit-parser-list` (and making it return
> `nil` if Emacs was compiled without Tree-sitter support)?
>
> Most places that can make use of Tree-sitter probably would probably
> prefer not to have to worry about the subtle distinction between
> "Tree-sitter support is available but not for this major mode" and
> "Tree-sitter support is not available at all”.
That makes sense. Also, anyone using tree-sitter functions needs to declare functions in treesit.c in case Emacs didn’t build with tree-sitter. Should we streamline it with a macro like this? Would it work?
(defmacro treesit-declare-c-functions ()
'(progn
(declare-function treesit-node-child "treesit.c")
...))
(eval-when-compile
(require 'treesit)
(treesit-declare-c-functions))
Yuan
next prev parent reply other threads:[~2022-12-18 23:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <167138365421.15060.2886694741391315956@vcs2.savannah.gnu.org>
[not found] ` <20221218171414.77B8EC0060F@vcs2.savannah.gnu.org>
2022-12-18 20:19 ` master 09b5f00613: ; Fix calls to treesit functions Stefan Monnier
2022-12-18 23:02 ` Yuan Fu [this message]
2022-12-18 23:54 ` Stefan Monnier
2022-12-19 8:26 ` Yuan Fu
2022-12-19 3:23 ` Eli Zaretskii
2022-12-19 3:37 ` Stefan Monnier
2022-12-19 6:26 ` Theodor Thornhill
2022-12-19 8:35 ` Yuan Fu
2022-12-19 9:07 ` Theodor Thornhill
2022-12-19 12:29 ` Eli Zaretskii
2022-12-19 13:47 ` Theodor Thornhill
2022-12-19 14:40 ` Eli Zaretskii
2022-12-19 14:51 ` Theodor Thornhill
2022-12-19 15:21 ` Eli Zaretskii
2022-12-19 15:44 ` Dmitry Gutov
2022-12-19 16:42 ` Theodor Thornhill
2022-12-19 16:57 ` Eli Zaretskii
2022-12-19 16:13 ` Stefan Monnier
2022-12-19 16:42 ` Theodor Thornhill
2022-12-20 0:12 ` Yuan Fu
2022-12-20 3:39 ` Eli Zaretskii
2022-12-20 4:37 ` Stefan Monnier
2022-12-20 13:59 ` Eli Zaretskii
2022-12-20 15:35 ` Stefan Monnier
2022-12-20 15:44 ` Eli Zaretskii
2022-12-20 16:02 ` Stefan Monnier
2022-12-21 0:36 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47D9ABEB-EA9C-49DA-BC35-189A563DEC10@gmail.com \
--to=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.