From: Yuan Fu <casouri@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Vincenzo Pupillo <v.pupillo@gmail.com>,
Emacs Devel <emacs-devel@gnu.org>,
Stefan Kangas <stefankangas@gmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>,
dmitry@gutov.dev
Subject: Re: Tree-sitter central configuration variable
Date: Fri, 29 Nov 2024 01:07:37 -0800 [thread overview]
Message-ID: <0D9218A9-C7F5-4D50-B49C-FCE201114C9B@gmail.com> (raw)
In-Reply-To: <86r06ubh3p.fsf@gnu.org>
> On Nov 29, 2024, at 12:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 28 Nov 2024 21:49:33 -0800
>> Cc: Vincenzo Pupillo <v.pupillo@gmail.com>,
>> Emacs Devel <emacs-devel@gnu.org>,
>> Stefan Kangas <stefankangas@gmail.com>,
>> Stefan Monnier <monnier@iro.umontreal.ca>,
>> Dmitry Gutov <dmitry@gutov.dev>
>>
>> Actually, I want to expand this to something that allows users to configure tree-sitter modes and toggle on/off tree-sitter features.
>>
>> Since Emacs 29, I see many people ask about how to configure tree-sitter modes by setting some variable. It seems that people much prefer setting a variable than adding a major mode hook that calls some functions. Also, admittedly adding custom font-lock or indent rules aren’t very straightforward for users.
>>
>> In Emacs 29, we went with the major-mode hook approach for customization since the major mode inheritance situation wasn’t yet clear, the hook approach provides most flexibility, and we don’t really know what we want. But at this point I think we can add another layer of convenience. As long as this convenience layer handles 90% of the use-cases and doesn’t add any confusion, it’ll be a net-gain.
>
> We are discussing the solutions to these issues in this thread:
>
> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00636.html
>
> Feel free to chime in and state your opinions about the solutions
> being proposed there.
That thread is about turning tree-sitter modes on and off. I think Dmitry’s proposal seems pretty good, and I don’t have much to add. What I’m proposing here is rather about configuring tree-sitter modes: turning features (outline, imenu, etc) on and off, customizing things (font-lock, indent, etc).
>
>> 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’s 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)))
>> )))
>>
>> This config will apply to c-ts-mode or its derived mode. Users can add extra font-lock and indent rules by setting this variable.
>
> I'm not sure I understand what problem(s) this intends to solve? Why
> should we have a global variable that customizes several different
> modes, if the specific customizations made by that variable depend on
> the individual modes?
I’m trying to solve several things: first off, turning on/off some tree-sitter features. Originally someone wants to turn off tree-sitter mode’s outline support. Technically they don’t really need to turn of tree-sitter’s outline, they just need to make the minor mode they’re using override tree-sitter’s outline configuration completely. Nevertheless, wanting to turn off a tree-sitter feature seems a reasonable ask so I want to support it.
Secondly, many people wants to configure tree-sitter modes by setting a variable. Right now, if one needs to add/remove some font-lock features they need to do this:
(defun x-mode-setup ()
(treesit-font-lock-recompute-features '(feature-a) '(feature-b)))
(add-hook 'x-ts-mode-hook #'x-mode-setup)
If they want to add some custom font-lock rules:
(defun x-mode-setup ()
(setq treesit-font-lock-settings
(append treesit-font-lock-settings
(treesit-font-lock-rules
:feature 'custom-feature
:language 'lang
((some_node) @face))))
(treesit-font-lock-recompute-features))
(add-hook 'x-ts-mode-hook #'x-mode-setup)
That might be a bit convoluted. I’m hoping that I can simplify things by the proposed variable.
>
>> One thing I don’t like is how it handles languages. In this POC language-specific settings are nested under the mode. I’m ok with mode-language hierarchy, but the nesting adds a lot of nesting levels to the variable. And the language nesting isn’t consistent, some settings have language nesting, some don’t.
>
> We don't have a notion of "language", we only have major modes. Emacs
> 30 makes it easier to specify settings common to modes that serve the
> same "language" by introducing the notion of "extra parent" modes.
> But that is only a small half-step; I don't think we have figured out
> what should be the goal.
We’re talking about different things. The language I was talking about are the languages in a multi-language modes. For a HTML mode, you’ll have HTML, CSS, and Javascript, and the we might want to configure the three languages differently in the HTML major mode. Eg, add a custom indent rule for CSS in the mode.
Yuan
next prev parent reply other threads:[~2024-11-29 9:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 10:30 Define treesit-font-lock-level as buffer local Vincenzo Pupillo
2024-11-07 11:03 ` Eli Zaretskii
2024-11-07 11:08 ` Vincenzo Pupillo
2024-11-09 8:36 ` Yuan Fu
2024-11-09 8:54 ` Eli Zaretskii
2024-11-10 8:04 ` Yuan Fu
2024-11-23 12:20 ` Eli Zaretskii
2024-11-29 5:49 ` Tree-sitter central configuration variable Yuan Fu
2024-11-29 7:12 ` Eshel Yaron
2024-11-29 8:42 ` Yuan Fu
2024-11-29 8:04 ` Eli Zaretskii
2024-11-29 9:07 ` Yuan Fu [this message]
2024-11-29 12:02 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0D9218A9-C7F5-4D50-B49C-FCE201114C9B@gmail.com \
--to=casouri@gmail.com \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@gmail.com \
--cc=v.pupillo@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).