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

[Theodor Thornhill]

>>> 
>>>> 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.
>>
>
> Strong agree there :)
>
>>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
>
> If that causes you less work just go ahead :)
>

I actually think it makes the most sense to extract javascript ts
support into ts-mode.el.  And then rename ts-mode.el to js-ts-mode.el.
Keep js.el vanilla, avoid tree-sitter altogether there, and keep
ourselves headache free. Then these modes also will follow the naming
scheme we have now, and will possibly make migration to a different
naming scheme easier.  It actually makes sense from a tree-sitter
perspective, considering that the typescript tree-sitter grammar
inherits javascript.  We also require js in ts-mode.el, but _only_ for
the exported tree-sitter convenience functions. js-ts-mode could also
imply javascript-typescript-mode, not just javascript-tree-sitter-mode,
which also kindof make sense.

What do you think?


-- 
Theo