emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: Average-user-facing interface for tree-sitter
Date: Mon, 24 Oct 2022 17:07:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>> I'm not comfortable with this notion of "backend", because each one of
>> those "backends" (elisp, treesit, eglot, ...) tends to support
>> a different set of features, so in practice, I'd expect that in the
>> common case many major modes will use a mix of those backends.
> Yes, one backend choice for each feature (most backends will provide
> more than one feature). There cannot be two backends for indent, but
> there can be different backends for indent and face.

Individual major modes can indeed offer more fine-grained control, but
I'm not convinced we want/need that complexity in the generic code.
Especially since existing "ELisp backends" (CC-mode, SMIE, and ad-hoc
ones) were not written with such piecemeal use in mind, so there's
a good chance we'd bump into more bugs.

I'd rather start small and later add such refined control if/when this
proves to be often necessary, at which point we'll know better what are
the pitfalls.

>>    (add-hook 'treesit-mode-hook #'js--treesit-mode-hook nil t)
>>    (js--treesit-mode-hook)
[...]
> Since js--treesit-mode-hook is provided by the major-mode, how is that
> better than simply including that code in js-mode, in a cond or cl-ecase
> on the desired backend for each feature?

We can't test directly from the major mode function because we don't
know yet if `treesit-mode` will be enabled.  It'd have to be postponed
to `hack-local-variables` anyway.
[ IIUC you do that for ada-mode, right?  ]

> Ah; js--treesit-mode-hook (I object to the name;

[ I object too, but I was in a hurry.  Now that I have more time to
  think about it, `js--post-treesit-setup` seems better.  ]

> But what calls it to do the unset?

Minor mode hooks are called both when enabling and disabling the mode.

> I set the backend choices in my .emacs, and change them rarely (next

Toggling `treesit-mode` dynamically is expected to be rare, indeed.
But you might enable `treesit-mode` in a mode-hook and then want to
disable it in a child mode's hook.

>> We could try and help write this code by providing a helper function
>> that relies on some buffer-local var containing a list of vars to be set
>> (along with their values), a list of hooks to add (and remove), ...
>> so we don't need to duplicate the list into a "set" and an "unset"
>> branch like I had to do in the patch.
> That would be good.
>> Note that it's very similar to a "backend" function.  But it's only
>> meant to choose between "treesit activated" and "treesit not
>> activated".
> We should also allow for eglot, wisi, and other future backends.

My hope is that for a given major mode we'll usually know which
functionality should better be offered via `treesit-mode` or via
`eglot-mode`.  We'll definitely want to allow the user to refine this
choice, but I don't think we have enough experience yet with it to know
how important it is and what it should look like.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]