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

[Stephen Leake <stephen_leake@stephe-leake.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Here’s my thought (that didn’t go anywhere): since major modes sets
>> a plethora of local hooks and variables, only the major mode itself knows
>> how to reverse them. The cleanest way is probably to clear all the local
>> variables and hooks and re-run the major mode setup, which suggests we
>> should let major mode branch on whether to enable tree-sitter during
>> initialization. I wonder if minor modes can somehow work with this model?
>
> Re-running is fairly problematic.  Not only because it risks repeating
> side effects but also because it starts by killing all buffer-local
> vars, so we'd need extra hacks to try and preserve the treesit-mode's
> own information (making it permanent-local is one way, but that can
> cause further breakage when the user really wants to change to another
> mode, so it tends to be hackish).
>
>> It would be also nice to leave room for inclusion of other “backends”
>> besides elisp and tree-sitter in the future.
>
> 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.

> A simple solution, tho not as elegant as I'd like, is to keep the code
> we have (where the major mode sets all vars upfront) but add to the
> major mode something like:
>
>    (add-hook 'treesit-mode-hook #'js--treesit-mode-hook nil t)
>    (js--treesit-mode-hook)
>
> where `js--treesit-mode-hook` is in charge of removing those settings
> that don't apply when `treesit-mode` is enabled` (and to re-instate
> them when `treesit-mode` is disabled, which is why I call it right away
> in the example above, so we don't duplicate the code between the major
> mode's body and the `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?

Ah; js--treesit-mode-hook (I object to the name; it's _not_ a hook
variable! It might as well be js-treesit-minor-mode) also does unset.

But what calls it to do the unset? I don't see the need for that, except
possibly when the user is still experimenting to determine which backend
is best. In that case, I always prefer restarting Emacs; that's the only
way to ensure the previous mode is fully unset (ie, not even loaded).

I set the backend choices in my .emacs, and change them rarely (next
time I change one will be when ada_language_server gains
SemanticToken support, allowing face via eglot).

I suppose there could be a situation where one xref backend is good at
one task (say finding references in system libraries), while another is
good at something else (maybe finding all refs withing one file); then
you might want to swap backends on the fly. The wisi and
ada_language_server xref facilities may actually be like that; I need to
experiment some more. Or this could argue for splitting the xref feature
in two, for global and local xref. It will take some experience to
settle on a good common set of features.

Another place where the backend matters; refactoring. For example wisi
and ada_language_server offer disjoint refactoring operations, all
useful. So to allow using all of them in ada-mode, each refactoring
function will use whichever backend provides that function; there will
be no ada-refactoring-backend setting.

> 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.

-- 
-- Stephe