From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wilhelm Kirschbaum Newsgroups: gmane.emacs.devel Subject: Possibly changing heex-ts-mode to derived from html-mode to prog-mode Date: Mon, 30 Dec 2024 11:35:53 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008c97be062a798a9c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20264"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 10:37:02 2024 Return-path: Envelope-to: ged-emacs-devel@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 1tSCCr-00057S-N2 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 10:37:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSCC3-0001BO-7p; Mon, 30 Dec 2024 04:36:11 -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 1tSCC1-0001BA-3h for emacs-devel@gnu.org; Mon, 30 Dec 2024 04:36:09 -0500 Original-Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSCBz-0002AU-5Y for emacs-devel@gnu.org; Mon, 30 Dec 2024 04:36:08 -0500 Original-Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-467918c35easo122781751cf.2 for ; Mon, 30 Dec 2024 01:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735551364; x=1736156164; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=N1u8Eit8FQlI3P4DeVRA5uVSe+bIuSABsC8ThSNJAh4=; b=RPjQLuKzCVdCrQA0NSbLtbx6pCQrDe+KRLjya/+EtYL59FEWe6UYf8aPPWDTC9GJfH HOjDWJSXfrkacVcx+Zx1bnvkgVmcuqn5anocMVNbfBpQ3bWX98xPC3CjD9T7As+lchsm dNEcSJM6Uvy5BWNb9LbXxW2VetivToK4iaW0GN9TDgMgFy/mOdrZ3weqEE+f4fnWnnwQ TX7Qv4tDCimQMe11PFvuMRIJwrKYeWqNotF1nmOCHSSROzctx5blZL+cyKJlHg7+4Rgd p7Zq+heg6UXJQLfEy6Yvt3fzhyLLQfYHQNL6ilY7Mnhr1c55I93Ag7WXXJsw0Vi2ghod yWzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735551364; x=1736156164; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=N1u8Eit8FQlI3P4DeVRA5uVSe+bIuSABsC8ThSNJAh4=; b=tdZgbOO10CEdr4lVG1S1aJOBDOYcdDXZdUnbENIA8X1gZjn6zOfYsjqWUsv9+r5M+4 IuMx0XfpNNZjnIM0C6jQx5u57K4syjvEpL6go1FtJeNd0WgHBTldn6dY9QPGXKPy6sfV Ui0q5e8fn4HOZIKCqDb2UWagDo7L3GCib4P+RokT/P/GvhJQfS/Jv2ZHC2H9FslLart6 HIU9Ko1xLnqacE+e9L/bxQncOPjlPKDHMLQ7ZZtzltEKjC763bKeul0ZwSzD+lhszElR EqycxsqNgUiZOIL3f7Gcb757knmeXcWY0txTkeHvhs3o2E51OvgBeYLXaSVh2HsrRRFu y8Jg== X-Gm-Message-State: AOJu0Yxpgqov/EXQ8QsIuXkD2l47QvkVtI6xKIqneTbmzNNwvVP6dSBN Hd99CTK4HU22le3GE2kgz5mL5q3KDC8O5f+kK3aClCDRBtdntZoB2LY1vqIm8VVtGsvElmLeeM7 JVOAVvl+V2VOf4dj2bJvGJwLAV7F5UnQh X-Gm-Gg: ASbGnctzBTPIidSVYZGu0lw7uVoyGuknLX/FVislnyvg9Z/frYmJjyQ29DXjJWQ/nCN aWWQ0MtMY0Rd3upy8d25ZBlrTU133iANLOFryz5A= X-Google-Smtp-Source: AGHT+IHGObcb6e296FHzMaXZPWo7bn3DVFFekplUS2UBQbjmIugtPIGxluLbIOejEjW2klsC8Zd/N0iWe+rQhLx9wOI= X-Received: by 2002:a05:622a:118c:b0:467:6226:bfc1 with SMTP id d75a77b69052e-46a4a8f4d78mr563235481cf.29.1735551364141; Mon, 30 Dec 2024 01:36:04 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::82f; envelope-from=wkirschbaum@gmail.com; helo=mail-qt1-x82f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327397 Archived-At: --0000000000008c97be062a798a9c Content-Type: text/plain; charset="UTF-8" Advice on this will be appreciated. Someone pointed out to me on the legacy heex-ts-mode package on github that heex-ts-mode makes more sense to derive from prog-mode than html-mode. Here is the comment: https://github.com/wkirschbaum/heex-ts-mode/issues/4 which reads: " The derivation chain goes heex-ts-mode <- html-mode <- sgml-mode <- text-mode <- nil. Which means users may trigger (and conversely not trigger) behavior they have setup in text-mode (and conversely prog-mode). For a concrete example, the default completion-at-point keybinding is taken over by ispell in text-mode. This was unexpected since heex-ts-mode, is primarily a programming buffer, even if you're just mostly writing templates. What are your thoughts on making it derive from prog-mode or web-mode rather than html-mode? " I think I agree, as HEEx is just Elixir looking like some html syntax. Language servers and other tools should treat this as Elixir, not text. Testing this change on my side with a very light setup shows that it has no negative impact. The wider impact of such a change is unknown to me. The original decision for deriving from html-mode was because I followed how erb-mode ( ruby markup ) works, which might have been a mistake. This is the proposed change: --- lisp/progmodes/heex-ts-mode.el | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/lisp/progmodes/heex-ts-mode.el b/lisp/progmodes/heex-ts-mode.el index b527d96b579..ab40d4819e8 100644 --- a/lisp/progmodes/heex-ts-mode.el +++ b/lisp/progmodes/heex-ts-mode.el @@ -143,7 +143,7 @@ heex-ts--forward-sexp (abs arg))) ;;;###autoload -(define-derived-mode heex-ts-mode html-mode "HEEx" +(define-derived-mode heex-ts-mode prog-mode "HEEx" "Major mode for editing HEEx, powered by tree-sitter." :group 'heex-ts @@ -168,16 +168,6 @@ heex-ts-mode ("Slot" "\\`slot\\'" nil nil) ("Tag" "\\`tag\\'" nil nil))) - ;; Outline minor mode - ;; `heex-ts-mode' inherits from `html-mode' that sets - ;; regexp-based outline variables. So need to restore - ;; the default values of outline variables to be able - ;; to use `treesit-outline-predicate' derived - ;; from `treesit-simple-imenu-settings' above. - (kill-local-variable 'outline-heading-end-regexp) - (kill-local-variable 'outline-regexp) - (kill-local-variable 'outline-level) - (setq-local treesit-font-lock-settings heex-ts--font-lock-settings) (setq-local treesit-simple-indent-rules heex-ts--indent-rules) -- Wilhelm --0000000000008c97be062a798a9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Advice on this will be appreciated.
Someone pointed out to me on the legacy heex-ts-mode package o= n github that heex-ts-mode makes more sense to derive from prog-mode than h= tml-mode.


"
The derivation chain goes heex-ts-mode <- html-mod= e <- sgml-mode <- text-mode <- nil. Which means users may trigger (and conversely not = trigger) behavior they have setup in text= -mode (and conversely prog-mode).

For a concrete example, the default completion-at-point key= binding is taken over by ispell in= text-mode. This was unexpected since hee= x-ts-mode, is primarily a programming buffer, even if you're jus= t mostly writing templates.

What are your thoughts on making it derive from prog-mode or web-mode rather than html-mode?

"

I think I agree, as HEEx is just= Elixir looking like some html syntax. Language servers and other tools sho= uld treat this as Elixir, not text. Testing this change on my side with a v= ery light setup shows that it has no negative impact. The wider impact of s= uch a change is unknown to me.

The original decision for derivin= g from html-mode was because I followed how erb-mode ( ruby markup ) works,= which might have been a mistake.

This is the proposed change: <= br>
---
=C2=A0lisp/progmodes/heex-ts-mode.el | 12 +-----------
=C2= =A01 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/lisp= /progmodes/heex-ts-mode.el b/lisp/progmodes/heex-ts-mode.el
index b527d9= 6b579..ab40d4819e8 100644
--- a/lisp/progmodes/heex-ts-mode.el
+++ b/= lisp/progmodes/heex-ts-mode.el
@@ -143,7 +143,7 @@ heex-ts--forward-sexp=
=C2=A0 =C2=A0 (abs arg)))
=C2=A0
=C2=A0;;;###autoload
-(define= -derived-mode heex-ts-mode html-mode "HEEx"
+(define-derived-m= ode heex-ts-mode prog-mode "HEEx"
=C2=A0 =C2=A0"Major mod= e for editing HEEx, powered by tree-sitter."
=C2=A0 =C2=A0:group &#= 39;heex-ts
=C2=A0
@@ -168,16 +168,6 @@ heex-ts-mode
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0("Slot" &q= uot;\\`slot\\'" nil nil)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0("Tag" "\\`tag\\'" n= il nil)))
=C2=A0
- =C2=A0 =C2=A0;; Outline minor mode
- =C2=A0 =C2= =A0;; `heex-ts-mode' inherits from `html-mode' that sets
- =C2= =A0 =C2=A0;; regexp-based outline variables.=C2=A0 So need to restore
- = =C2=A0 =C2=A0;; the default values of outline variables to be able
- =C2= =A0 =C2=A0;; to use `treesit-outline-predicate' derived
- =C2=A0 =C2= =A0;; from `treesit-simple-imenu-settings' above.
- =C2=A0 =C2=A0(ki= ll-local-variable 'outline-heading-end-regexp)
- =C2=A0 =C2=A0(kill-= local-variable 'outline-regexp)
- =C2=A0 =C2=A0(kill-local-variable = 'outline-level)
-
=C2=A0 =C2=A0 =C2=A0(setq-local treesit-font-lo= ck-settings heex-ts--font-lock-settings)
=C2=A0
=C2=A0 =C2=A0 =C2=A0(= setq-local treesit-simple-indent-rules heex-ts--indent-rules)
--


Wilhelm

--0000000000008c97be062a798a9c--