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

[Theodor Thornhill <theo@thornhill.no>]

On 23 October 2022 03:59:35 CEST, Fu Yuan <casouri@gmail.com> wrote:
>
>
>> 
>>> 
>>>>> 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?

Yeah, that's what I was thinking too. We can just separate the inits into its own function and use a coed. Adding other variants will then be trivial. 

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


Theo