Re: Turing on tree-sitter

[Yuan Fu]

> On Oct 10, 2022, at 9:24 AM, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> On Oct 10, 2022, at 7:52 AM, Stefan Monnier <monnier@iro.umontreal.ca> 
>>> wrote:
>>> 
>>>>> Is there a reason we can't use a minor mode?  Something like
>>>>> 
>>>>>       (add-hook 'python-mode-hook #'treesit-mode)
>>>>> 
>>>>> or a list
>>>>> 
>>>>>       (add-to-list 'treesit-modes 'python-mode)
>>>>> 
>>>>> ?
>>>> 
>>>> We could, if a minor mode is justified.  When this was previously
>>>> brought up, someone said the justification for a minor mode was too
>>>> weak in most cases.  But maybe we should revisit that idea.
>>> 
>>> I think a buffer-local `treesit-mode` plus a `global-treesit-mode` would
>>> make a lot of sense, from a user's perspective.  This way they don't
>>> have to hunt for the name of the boolean variable that their mode
>>> decided to use to control the use of treesitter: all modes use the same
>>> boolean variable called `treesit-mode`.
>> 
>> Usually users set buffer-local variables in a major mode hook, which
>> runs after the major mode is loaded, no? But major modes need to know
>> whether to use tree-sitter up-front.
> 
> What if the hook is a noop and the mode definition just checks if the
> function is a member?  Or is there no way to re-fontify a buffer?

IMO that’s a bit hacky, we have plenty better options.

> 
>> I don’t think xxx-mode-use-tree-sitter would be hard to find if every
>> mode uses this pattern. Though now we are discussing adding separate
>> major modes which wouldn’t use this variable. I think that indeed
>> could be confusing. (How do I know if xxx language uses
>> xxx-mode-use-tree-sitter or a separate major mode
>> xxx-tree-sitter-mode?)
> 
> I think the issue here is not so much discoverability, but consistency.
> Having to a different option for every mode can get annoying and is
> difficult to automate.  It is also unnecessarily decentralised.  That is
> why I think that having a single list like `treesit-modes' (by whatever
> name) would be nice to have.  Using the easy customisation interface
> you'd represent it as a set/radio menu where you get a list of supported
> languages you can tick.

That’s nice, but it wouldn’t make much sense to add A to the list when A-mode 
doesn’t actually support tree-sitter. I think of tree-sitter as something at 
major mode level.

> 
>>> Then again, to me a minor mode is something so cheap that the idea that
>>> "justification for a minor mode was too weak" is rather hard to grasp.
>> 
>> I don’t think there is too much problem using minor modes, but minor
>> modes wouldn’t fit very well with separate major modes. IMO it would
>> be weird if turning on tree-sitter-mode changes the major mode.
> 
> I don't get why a `tree-sitter-mode' should change the major mode?

My bad, I thought Theodor was saying he would add separate major modes 
alongside non-tree-sitter major modes for the same language. Reading his 
message I think he is only adding the tree-sitter powered mode into core and 
leaving the non-tree-sitter version out.

So IIUC we will have (a) major modes that supports both tree-sitter and 
non-tree-sitter, and (b) major modes that require tree-sitter to work.

Again, a M-x treesit-enable in a mode that requires tree-sitter to work doesn’t 
make much sense. I think having individual major-mode level toggle variables 
and a global toggle variable is conceptually more fit?

Yuan