[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tree-sitter central configuration variable
From: |
Yuan Fu |
Subject: |
Re: Tree-sitter central configuration variable |
Date: |
Fri, 29 Nov 2024 00:42:34 -0800 |
> On Nov 28, 2024, at 11:12 PM, Eshel Yaron <me@eshelyaron.com> wrote:
>
> Hi,
>
> Yuan Fu <casouri@gmail.com> writes:
>
>> Actually, I want to expand this to something that allows users to
>> configure tree-sitter modes and toggle on/off tree-sitter features.
>>
> [...]
>>
>> 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)
> [...]
>> )))
>>
>
> FWIW, I think tree-sitter should be treated as an implementation detail,
> not a user-facing concept. Tree-sitter empowers major mode developers,
> but users shouldn't have to know or care about tree-sitter to benefit
> from it. So a TS-specific configuration user option is not the best
> approach IMO. (For the same reason, I'm not a big fan of the "powered
> by tree-sitter" that we have today in the docstring of various modes.)
I principle, I agree, and that’s what we’ve been doing: we expose tree-sitter
as a mechanism for major modes to build on. However, the reality is, something
like this just aren’t going to be transparent—users know it’s powered by
tree-sitter, they’ll need to have tree-sitter knowledge for non-trivial
customizations (eg, add a font-lock rule or indent rule), and the major mode is
tied-in with tree-sitter, implementing the major mode with another parser
library would require creating a new major mode.
Once you accept that these modes are tied with tree-sitter, a TS-specific
configuration starts to seem pretty reasonable. Also, think of the advantage of
using a single set of configuration: no need to read the manual and learn the
variables etc for each individual major modes; as long as the mode uses
tree-sitter features, you learn the configuration framework once and use it on
every mode.
> Instead, when it comes to settings that apply across major modes, I
> think we should focus on knobs that make sense whether or not a mode is
> TS-based, and have the TS-based modes respect such universal settings.
Perhaps you mean something that configures things like font-lock, imenu, etc?
(I can’t really think of a third example). That’s a bit ambitious, the return
is unclear to me, and gods bless whoever wants to fight through emacs-devel for
it :-) OTOH, a tree-sitter configuration variable is pretty concrete, I know
people want it, and more or less noncontroversial (I hope).
Yuan
- Define treesit-font-lock-level as buffer local, Vincenzo Pupillo, 2024/11/07
- Re: Define treesit-font-lock-level as buffer local, Eli Zaretskii, 2024/11/07
- Re: Define treesit-font-lock-level as buffer local, Vincenzo Pupillo, 2024/11/07
- Re: Define treesit-font-lock-level as buffer local, Yuan Fu, 2024/11/09
- Re: Define treesit-font-lock-level as buffer local, Eli Zaretskii, 2024/11/09
- Re: Define treesit-font-lock-level as buffer local, Yuan Fu, 2024/11/10
- Re: Define treesit-font-lock-level as buffer local, Eli Zaretskii, 2024/11/23
- Tree-sitter central configuration variable, Yuan Fu, 2024/11/29
- Re: Tree-sitter central configuration variable, Eshel Yaron, 2024/11/29
- Re: Tree-sitter central configuration variable,
Yuan Fu <=
- Re: Tree-sitter central configuration variable, Eli Zaretskii, 2024/11/29
- Re: Tree-sitter central configuration variable, Yuan Fu, 2024/11/29
- Re: Tree-sitter central configuration variable, Eli Zaretskii, 2024/11/29
- Re: Tree-sitter central configuration variable, Stefan Monnier, 2024/11/29
- Re: Tree-sitter central configuration variable, Ship Mints, 2024/11/29