Re: Average-user-facing interface for tree-sitter

["Jostein Kjønigsen" <jostein@secure.kjonigsen.net>]

[-- Attachment #1: Type: text/plain, Size: 4669 bytes --]


> Yuan Fu<casouri@gmail.com>  writes:
>
>>  From the suggestions I collected from the old thread, here is my proposal:
>>
>> We define a custom option treesit-settings (we can discuss the name
>> later), which controls whether to enable/disable tree-sitter for each
>> major mode, and the default preference, like this:
>>
>> (defcustom treesit-settings '((t nil nil))
>>    "Tree-sitter toggles for major modes.
> Hm...  well, there's also modes that are "pure treesit", and there are
> (or will be) alternate modes with and without tree-sitter.
>
> I think users basically fall into two camps: The ones that want to have
> tree-sitter in all modes, and ones that want to enable it in specific
> modes (and ones that don't want it at all).  (Note Computer
> Science-mandated off-by-one error.)
>
> This suggests to me that we should just use the normal minor mode
> machinery that we have for these things.
>
> That is, people that want treesit in python-mode will say:
>
> (add-hook 'python-mode 'treesit-mode)
>
> And people that want it everywhere will say:
>
> (global-treesit-mode)
>
> This mode will, in addition to switching `treesit-mode' on everywhere,
> also set up `major-mode-remap-alist', so that `typescript-mode' is
> mapped to `ts-mode', and `c-mode' is mapped to `treesit-c-mode' (which
> I'm sure somebody is going to write in a couple of days), etc.
>
>
Hey there.

I'd like to come up with a somewhat contrarian point of view, if nothing 
else to provide a point of reference.

Right now we have a single (that is: one, 1) implementation for c-mode 
and c++-mode. They are based on cc-mode.

There's no c-mode where you enable usage of cc-mode through a 
minor-mode, nor is there a global-cc-mode toggle. And there's a really 
simple reason for that. That's because c-mode is implemented using 
cc-mode as a foundation, and there's no other implementations.

Now if we are starting to implement some new major-modes using 
treesitter as a foundation (for instance ts-mode or c#-mode), such a 
toggle for tree-sitter-mode will be equally pointless. There is no 
ts-mode without treesitter. And what should we do if people activate 
ts-mode without these bespoke minor-modes being active at the same time? 
I think it's a bit fuzzy and doesn't really sound very .. well defined.

Existing users of typescript-mode can be guided to the new 
implementation through a variety of ways, but to me the flow of 
activating typescript-mode major-mode, then treesit-minor-mode, and then 
magically switching to ts-mode makes absolutely no sense. And the 
performance of that is probably terrible too.

For those users I think a simple deprecation warning which informs about 
the new built-in ts-mode should be more than sufficient, for the users 
to clean out the old (buggy) typescript.el from their conigs.

The one place where it gets slightly complicated is for major-modes 
where one decides to have two or more canonical implementations, that is 
to add a new treesitter backend alongside the existing elisp-one.

For an established built in-mode, like c-mode, switching over night is 
probable not feasable nor desirable. So in practice you will have a few 
modes where you might have multiple backends, ideally only in a 
transitional phase, but in worst case scenario permanently.

So how can we deal with /that/ problem, where we have it, and not 
everywhere else?

I've had a similar "problem" for LSP backend for some programming 
languages. The solution I landed on there was to have a defcustom per 
language/major-mode where there were different LSP-backends which I may 
want to use.

Examples below:

- (defcustom csharp-lsp-backend) ;; 'lsp-mode 'omnisharp

- (defcustom typescript-lsp-backend) ;; 'lsp-mode 'tide

Then I in my major-mode hooks checked for which of the possible backends 
are chosen and dynamically dispatch based on that.

For major-modes ending up with multiple backends, I think this is an 
approach which scales better (supports more than 1 backend, but only 1 
at a time!), and will perform better (because it means avoiding 
triggering code for more than one single backend when activated).

It will also better support the flow if we eventually end up with a 
single backend again which then becomes the default. In that case, we 
don't need to maintain empty/obsolete minor-modes just to avoid breaking 
people's major-mode hooks. Then they will just have a defcustom setting 
which will be ignored.

Personally I think that would work much better, and support the 
transitional period we may be entering, without causing lasting "cruft" 
in the code-base we rather would not have.

Just my 2 cents.

--
Jostein



[-- Attachment #2: Type: text/html, Size: 5649 bytes --]