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

[Fu Yuan]

> 
>> 
>>>> Yeah.  Shouldn't it be possible to just have a global var instead of a
>>>> mode?  That way we can just look for that variable when enabling the
>>>> mode, and avoid calling anything other than what we want.  At least for
>>>> the foreseeable future, enabling these per mode in the init file
>>>> shouldn't really be too much of a problem, IMO.  When more users
>>>> actually get to try this we can get a feel for how the init should best
>>>> be handled.
>>>> 
>>>> To me the '*-use-tree-siter' defcustoms was beautiful :)
>>> 
>>> Back to centralized variable, perhaps?
>> 
>> I’ve thought really hard but didn’t come up with any brilliant ideas, so I’m
>> going with centralized variable. Now, should I throw away recent commits and
>> create a new branch so we don’t have so many changes back and forth on js.el
>> and python.el? Plus feature/tree-sitter wouldn’t be used for long anyway
>> since it’s merging into master soon.
> 
> I'd wait a bit more to see if some other ideas come up first.

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?

It would be also nice to leave room for inclusion of other “backends” besides 
elisp and tree-sitter in the future.

Yuan