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

[Theodor Thornhill]

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