From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#60453: 29.0.60; treesit-range-rules throw an error without tree-sitter Date: Tue, 17 Jan 2023 01:41:48 -0800 Message-ID: <45844FFA-6D03-4B0E-9170-C62BDDE73438@gmail.com> References: <87wn67sjnw.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8242"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 60453@debbugs.gnu.org To: Wilhelm Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 17 10:42:12 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHiTr-0001s9-Ue for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Jan 2023 10:42:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHiTk-0007OI-HM; Tue, 17 Jan 2023 04:42:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHiTi-0007NG-Vt for bug-gnu-emacs@gnu.org; Tue, 17 Jan 2023 04:42:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHiTi-0004sh-NJ for bug-gnu-emacs@gnu.org; Tue, 17 Jan 2023 04:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pHiTi-0000tz-66 for bug-gnu-emacs@gnu.org; Tue, 17 Jan 2023 04:42:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87wn67sjnw.fsf@gmail.com> Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Jan 2023 09:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60453 X-GNU-PR-Package: emacs Original-Received: via spool by 60453-submit@debbugs.gnu.org id=B60453.16739485183452 (code B ref 60453); Tue, 17 Jan 2023 09:42:02 +0000 Original-Received: (at 60453) by debbugs.gnu.org; 17 Jan 2023 09:41:58 +0000 Original-Received: from localhost ([127.0.0.1]:35805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pHiTd-0000tY-MG for submit@debbugs.gnu.org; Tue, 17 Jan 2023 04:41:58 -0500 Original-Received: from mail-pg1-f181.google.com ([209.85.215.181]:35787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pHiTb-0000tF-4w for 60453@debbugs.gnu.org; Tue, 17 Jan 2023 04:41:55 -0500 Original-Received: by mail-pg1-f181.google.com with SMTP id f3so21518153pgc.2 for <60453@debbugs.gnu.org>; Tue, 17 Jan 2023 01:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=rdASjmu65jH1d3TML0+reWxU4rGwgjZYscLn4/GVYqg=; b=PbCFKeC2DsiO0uKVnihyIQJ0rPJUop27/KhLddnMD35dWw3qZ7fazdpWOE28LiB/ZE aJhrMuF798eZ2aKYfJq1pFd2PNkla0dzQ4+AnnHC+tywLXVK4Wn1yaJ/3sFesaUQ22CL 2y2063Gg+VJVLLYvljKeNXgQxbVV+4/sdQi3t6yyreu04H0LJc0+1FsqC+hTI/QKVvPE DWt/YKj84hPK1Kxm5eDR1SE9mGBTTqxFCAYDwbbjglATMHGLKHJeRG+ox4iaR+KYKeBt sd6JxEmSvHfIHs+1dRxOCchQklHzr5PY2nbpDwxTs9PtSXqfA3idp5tW+cdqPXCMlgoq M9oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rdASjmu65jH1d3TML0+reWxU4rGwgjZYscLn4/GVYqg=; b=sNHj5tyShpBi1yZMoXdjoaxYX6Lwbasprrwy0ZOTGvtmy9QKf1b8f34dmHWUGEWd0b eX2vKkvTPedHe06vqHdUS7YgsXme2MEwhS5LwzmdsPDYgbJXnjZKVpID6FwB2gvIZaAJ kDz8GuKVbxM7hdXB8UiN+d1ieq9ER9y4vhA7dEY2cVSYMtWJFnFduwC/fQbXF7iS6R7x bWxETeOhXxYIkMjx7fPJ8UA3vvvB922yuC96hmzD3TxFtaSSY6SkDGm3+u4vzzTG0LK2 2SzE1KpXdkNy8b8cKipvAapcriAJLNxM5zcZYY+X/yiw+x1hRZLemRl162YisJmG4gV+ 1JlQ== X-Gm-Message-State: AFqh2koXV1wqy7kU6nUUwzUzK7l5kE7wJNOUMZXizEKTjnIkjuPY4jc1 NYK1BY0ToCPTwMzCdZnTERU= X-Google-Smtp-Source: AMrXdXskiAUjpcj12riynidXPkL5iwpSuliCQJO9q3T4R68HdaXN7n+g5VvCnVF2fYxPSar3BGndGw== X-Received: by 2002:aa7:8544:0:b0:58d:d0de:fc11 with SMTP id y4-20020aa78544000000b0058dd0defc11mr693565pfn.31.1673948509613; Tue, 17 Jan 2023 01:41:49 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id i1-20020a056a00004100b00581a156b920sm7404451pfk.132.2023.01.17.01.41.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2023 01:41:49 -0800 (PST) X-Mailer: Apple Mail (2.3696.120.41.1.1) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:253537 Archived-At: Yuan Fu writes: > Wilhelm Kirschbaum writes: > >> Eli Zaretskii writes: >> >>>> From: Wilhelm Kirschbaum >>>> Cc: 60453@debbugs.gnu.org >>>> Date: Sat, 31 Dec 2022 18:50:31 +0200 >>>> Eli Zaretskii writes: >>>> >> From: Wilhelm Kirschbaum >>>> >> 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=E2=80=99s 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=E2=80=99s 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