Re: Mode names for C-like tree-sitter modes

[Yuan Fu]

> On Nov 13, 2022, at 10:34 PM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> 
> On 14 November 2022 02:16:13 CET, Yuan Fu <casouri@gmail.com> wrote:
>> Thanks to Theo’s great work, we now have tree-sitter powered major modes for 
>> C, C++, Java, JSON, CSS. Right now they are named c-ts-mode, c++-ts-mode, 
>> java-ts-mode, etc. And c-ts-mode and c++-ts-mode inherits from a dummy mode 
>> c-ts-mode--base-mode.
>> 
>> I think it’s fair to make C, C++ and Java modes independent, since all the 
>> cc-mode options are invalidated when we use tree-sitter. However, their name 
>> could be improved, IMO. But I can’t think of anything better than c-ts-mode 
>> :-)
>> 
>> (neo-c-mode… just saying)
>> 
> 
> I agree and can't think of a better name either...

c-nouveau-mode ;-)

> 
>> c-ts-mode--base-mode should probably be a public mode, since the intention 
>> (IIUC) is enable users to configure C and C++ together, by adding hooks to 
>> this base-mode. So something like c-base-mode or c-ts-base-mode?
>> 
> 
> Sure!
> 
>> CSS and JSON could be merged with current modes, I think. Css-ts-mode could 
>> merge with css-mode, and json-ts-mode could be merged with js-json-mode. Or 
>> we can just have a dedicated json-mode.
>> 
>> Theo, WDYT?
>> 
> 
> That's fine with me. In any case I think we should remove tree-sitter support 
> from js-json-mode (or merge them). I think there exist a json-mode  in both 
> elpa and melpa, adding another isn't the best idea I think. 
> 
> Not sure what is best, really.

Js-json-mode inherits from js-mode, which complicates the matter if tree-sitter 
is enabled for js-mode… Probably should remove tree-sitter from js-json-mode. 
Also if we decided cc-mode and tree-sitter should be mutually exclusive (which 
we kind of have), we should remove some cc-mode init in js-mode that runs even 
when tree-sitter is enabled.

The json-mode you mentioned is on ELPA, and is fairly small, we might be able 
to merge json-ts-mode with it. Simen, WDYT?

> 
> My vote goes to merging css and keeping others separate, but I don't have the 
> strongest opinion there. 
> 
> I can prepare such a patch after we decide on something.

I can also do it, that’ll save us some patching and merging ;-)

Yuan