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

[Yuan Fu <casouri@gmail.com>]

> On Oct 24, 2022, at 5:57 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> 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).

I agree, tho I think the risk of side effect is a bit exaggerated. 

> 
>> 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.
> 
> 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`).
> 
> Sample completely untested patch below.
> 
> 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.
> 
> Note that it's very similar to a "backend" function.  But it's only
> meant to choose between "treesit activated" and "treesit not activated”.

Now the minor mode scheme is getting more and more complicated that I wonder if the benefit is worth it. Maybe we should revisit the central variable scheme, which I still think is pretty clean and convenient:
> 
>> 
>> This function would handle derived mode ok, but I don’t know what are
>> the other problems you are think of, maybe you can tell me what this
>> function falls short for. And we can go from there.
> 
> The function is one thing.  Another question is when it is run, and
> hence how it interacts with other ways to enable/set/control the thing
> you want to control (in this case enabling `treesit-mode`, IIUC).

There will not be treesit-mode and global-treesit-mode, only the central variable treesit-settings. Enabling tree-sitter only requires adding (mode t) to treesit-setttings, and M-x revert-buffer, or reopen the file, or rerun the major mode. Actually, 99% of the time people would just set that setting, enabling tree-sitter for a mode (or all supported modes) and be done with it. Ie, there is not a lot of toggling that calls for a minor mode. Minor mode are still nice since one can add it to the major mode hook, but we’ve seen that it brings more trouble than benefit.

Letting major modes to branch on a global variable is also cleaner and easier to write than adding code to enable/disable a bunch of setups, IMO.

At this point, I think we see how minor modes clearly are a bit awkward to control major mode behavior with. And AFAIK the central variable doesn’t have any visible issues. So I think central variable is better.

Yuan