From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter central configuration variable Date: Fri, 29 Nov 2024 12:22:48 -0500 Message-ID: References: <4929184.OV4Wx5bFTl@3-191.divsi.unimi.it> <861pznqp9m.fsf@gnu.org> <2730223.lGaqSPkdTl@3-191.divsi.unimi.it> <39CF8919-E0A5-44D7-AA7E-ECD7465620A1@gmail.com> <86a5e8okhx.fsf@gnu.org> <868qtam99v.fsf@gnu.org> <137AE507-F467-4FB2-83DB-EC621F868C60@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000562f89062810735a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18114"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Eli Zaretskii , Vincenzo Pupillo , Emacs Devel , Stefan Kangas , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 29 18:24: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 1tH4io-0004Zz-B9 for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Nov 2024 18:24:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tH4hu-0001v0-5W; Fri, 29 Nov 2024 12:23:06 -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 1tH4hs-0001tI-3L for emacs-devel@gnu.org; Fri, 29 Nov 2024 12:23:04 -0500 Original-Received: from mail-qv1-xf2f.google.com ([2607:f8b0:4864:20::f2f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tH4hp-0005G5-Rp; Fri, 29 Nov 2024 12:23:03 -0500 Original-Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-6d41864d745so14546866d6.2; Fri, 29 Nov 2024 09:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732900980; x=1733505780; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lkf9FFbXwitIU4pyhqhYCkEXE3PM1/wcoiL3EQd0u9k=; b=RHAd6YBIN8v8wSRYLut0cj2bk0vCoy63i/AP/SN9uYta6l66ffXD2rXhyZZ4q/eEfD HaAa6a7UndKCA87xvzhG7uZfhsXHntHwYaQkIBT46VduCiKdwOexKjix9OjQHn5cGUPv +a7+SsCONeTOBhEpExpXsS+r6sZzUplKw74AeE0NLFmMrIKQ6AaCtvw57JRKdnBrs2HR XgjQ1lQVvm0zTC/Ix3Yv9lmsiT8yiNljKZxPzv2B4ILtZF+mh3wibakCOqv9bR44PFHl Ro2y6tkDfowBMr+qV+UlpB7vuCsJXm8rgGU94fR12PGaa7tHWdhyJsoaLAACJriaHkEs yrLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732900980; x=1733505780; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lkf9FFbXwitIU4pyhqhYCkEXE3PM1/wcoiL3EQd0u9k=; b=bCdEK+vC4XgpxaiDZlvViZWv3INPIBeq+HsGG9/T8WapuchxyrKvNga/UaCDKSZXF8 AQSRyaBY9vCl/t3aiEmWZLoJvfcrwCpV4mNJJnMjVVt4pvKykqpYx7nXvSm7hqFkwxbO JM0L8CDCABNAS/8G1mV0vRDNeUKEGsg26mtQklqoqyaGMwXOXO5e/v82sciN8o8IqHCr EvKRAbsGecx7J22x/Fx385abAhtBXjjYYzPLRvuaIQs80bCrFThHZYVAvoWuZvo9y2rI rCZ6yHlKHPCgLqe2W3GRwRzYKmb+Clrt0OKt37MkQNsFjz9FBzCThEgiKszT8Lt3pXqA kTtA== X-Forwarded-Encrypted: i=1; AJvYcCXBbA7nPpOB8Dj4E0hQ1YG5TJOjcIex/k6g81SWEd4fnrooaKc3ev+MK/gzQsCDctN2us5O@gnu.org, AJvYcCXZ5lD4DHagCf1SSHSALD5vcQyHLgBopKLgbvTQzA5KBr5mQoT1tpbrbcbsxMq/XyplUiLeVqFixJtq3Z8=@gnu.org X-Gm-Message-State: AOJu0Yz7zvCLOvfrEoJL+BwK5NLCKb6MQ0IEym639z7ssbFiQ2peF/Zm GS4dDYYPWKd4QlYptBOczUwYAzSjNZEi/0+XNFWDgI7nCO5kWd6uzu4uVp7URFKNvN6OlCBuql/ cP4kQmGgYEJU7Z/62QnAQm6D5X08= X-Gm-Gg: ASbGncvQwSJ37BVFUMXXbGaAGFdcSMa7SJ3nxDxybUqPtac8L5Rw5eUK05r5vR4y1cE QN/PVj2Oh62ARDq2QQc+KfMlV3Wel264= X-Google-Smtp-Source: AGHT+IFPyXqru/loPrOZLwfrZfwPc7cUUwf2+haI/HbXEYwgANugujSqI7t5OwIpfh5sUHnqOLGinFUi3kuepzusIsY= X-Received: by 2002:ad4:5de8:0:b0:6cb:e99c:86a9 with SMTP id 6a1803df08f44-6d864d02bdcmr169767346d6.1.1732900979877; Fri, 29 Nov 2024 09:22:59 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::f2f; envelope-from=shipmints@gmail.com; helo=mail-qv1-xf2f.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:325857 Archived-At: --000000000000562f89062810735a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Chiming in with my minor voice. I prefer my mode configurations generally self contained and not centralized as a single global configuration variable would encourage. When I share my configurations with others, it also suggests that if they adopt a global configuration variable on top of what I share, it will introduce subtle changes in behavior that I may not at first understand the source of when helping others. I definitely prefer proper lisp over an opaque configuration variable. -Stephane On Fri, Nov 29, 2024 at 12:04=E2=80=AFPM Stefan Monnier wrote: > > Since Emacs 29, I see many people ask about how to configure > > tree-sitter modes by setting some variable. > > This is not specific to tree-sitter. > > > It seems that people much prefer setting a variable than adding > > a major mode hook that calls some functions. > > But that boxes them into the subset of possibilities that have been > pre-imagined by those who designed the set of variables. > > > What do you guys think about something like this: > > > > (setq treesit-global-configuration > > '((c-ts-mode > > ;; Set treesit-font-lock-level to 4 > > (font-lock-level . 4) > > ;; Disable tree-sitter=E2=80=99s outline support > > (outline . disable) > > ;; Enable these features on top of the default ones. > > (font-lock-enable . (function property variable)) > > ;; Disable these features. > > (font-lock-disable . (definition)) > > ;; Add extra font-lock rules > > (font-lock-extra-rules > > ( :feature 'my-rules > > :language 'c > > ((some_query) @some-face))) > > (simple-indent-extra-rules > > (c > > (matcher anchor offset)) > > (d > > (matcher anchor offset))) > > ))) > > Sounds to me like this is inventing a new programming language, just one > that's a lot more restrictive than ELisp. > > Is it really better than ELisp which could look like: > > (add-hook 'c-ts-mode-hook #'my-c-ts-mode-preferences) > (defun my-c-ts-mode-preferences () > (setq-local treesit-font-lock-level 4) > (treesit-outline-mode -1) > (treesit-font-lock-enable '(function property variable)) > (treesit-font-lock-disable '(definition)) > (treesit-font-lock-add-rules > '( :feature 'my-rules > :language 'c > ((some_query) @some-face))) > (treesit-indent-add-rules > '((c > (matcher anchor offset)) > (d > (matcher anchor offset))) > )) > > Admittedly, the add-hook/defun dance could be improved, and that would > benefit more than just tree-sitter. E.g. a new macro like > > (defmacro custom-set-hook (hook &rest body) > (declare (indent 1) (debug (sexp def-body))) > (let ((funname (intern (format "custom-set-hook--%s" hook)))) > `(progn (add-hook ',hook #',funnmame) > (defun ,funname () ,@body)))) > > > One thing I don=E2=80=99t like is how it handles languages. In this POC > > language-specific settings are nested under the mode. I=E2=80=99m ok wi= th > > mode-language hierarchy, but the nesting adds a lot of nesting levels > > to the variable. And the language nesting isn=E2=80=99t consistent, so= me > > settings have language nesting, some don=E2=80=99t. > > I don't really understand what you're referring to, but for > `treesit-font-lock-add-rules` would could try and auto-add the `:language= `? > > > Stefan > > > --000000000000562f89062810735a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chiming in with my minor voice. I prefer my mode configurations generall= y self contained and not centralized as a single global configuration varia= ble would encourage. When I share my configurations with others, it also su= ggests that if they adopt a global configuration variable on top of what I = share, it will introduce subtle changes in behavior that I may not at first= understand the source of when helping others. I definitely prefer proper l= isp over an opaque configuration variable.

-Stephane

On Fri, = Nov 29, 2024 at 12:04=E2=80=AFPM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Since Emacs 29, I see man= y people ask about how to configure
> tree-sitter modes by setting some variable.

This is not specific to tree-sitter.

> It seems that people much prefer setting a variable than adding
> a major mode hook that calls some functions.

But that boxes them into the subset of possibilities that have been
pre-imagined by those who designed the set of variables.

> What do you guys think about something like this:
>
> (setq treesit-global-configuration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0'((c-ts-mode
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Set treesit-font-lock-level to 4<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (font-lock-level . 4)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Disable tree-sitter=E2=80=99s out= line support
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (outline . disable)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Enable these features on top of t= he default ones.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (font-lock-enable . (function proper= ty variable))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Disable these features.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (font-lock-disable . (definition)) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Add extra font-lock rules
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (font-lock-extra-rules
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( :feature 'my-rules
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:language 'c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((some_query) @some-fac= e)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (simple-indent-extra-rules
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (matcher anchor offset))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(d
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (matcher anchor offset)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )))

Sounds to me like this is inventing a new programming language, just one that's a lot more restrictive than ELisp.

Is it really better than ELisp which could look like:

=C2=A0 =C2=A0 (add-hook 'c-ts-mode-hook #'my-c-ts-mode-preferences)=
=C2=A0 =C2=A0 (defun my-c-ts-mode-preferences ()
=C2=A0 =C2=A0 =C2=A0 (setq-local treesit-font-lock-level 4)
=C2=A0 =C2=A0 =C2=A0 (treesit-outline-mode -1)
=C2=A0 =C2=A0 =C2=A0 (treesit-font-lock-enable '(function property vari= able))
=C2=A0 =C2=A0 =C2=A0 (treesit-font-lock-disable '(definition))
=C2=A0 =C2=A0 =C2=A0 (treesit-font-lock-add-rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0'( :feature 'my-rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :language 'c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((some_query) @some-face)))
=C2=A0 =C2=A0 =C2=A0 (treesit-indent-add-rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0'((c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (matcher anchor offset))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (matcher anchor offset)))
=C2=A0 =C2=A0 =C2=A0 ))

Admittedly, the add-hook/defun dance could be improved, and that would
benefit more than just tree-sitter.=C2=A0 E.g. a new macro like

=C2=A0 =C2=A0 (defmacro custom-set-hook (hook &rest body)
=C2=A0 =C2=A0 =C2=A0 (declare (indent 1) (debug (sexp def-body)))
=C2=A0 =C2=A0 =C2=A0 (let ((funname (intern (format "custom-set-hook--= %s" hook))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 `(progn (add-hook ',hook #',funnmame) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (defun ,funname () = ,@body))))

> One thing I don=E2=80=99t like is how it handles languages. In this PO= C
> language-specific settings are nested under the mode. I=E2=80=99m ok w= ith
> mode-language hierarchy, but the nesting adds a lot of nesting levels<= br> > to the variable.=C2=A0 And the language nesting isn=E2=80=99t consiste= nt, some
> settings have language nesting, some don=E2=80=99t.

I don't really understand what you're referring to, but for
`treesit-font-lock-add-rules` would could try and auto-add the `:language`?=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan


--000000000000562f89062810735a--