Mode names for C-like tree-sitter modes

Mode names for C-like tree-sitter modes

[Yuan Fu]

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)

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?

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?

Yuan

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

[Theodor Thornhill]

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-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.

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.

Theo

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

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

[Theodor Thornhill]

On 14 November 2022 10:09:58 CET, Yuan Fu <casouri@gmail.com> wrote:
>
>
>> 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 ;-)
>

Hah! Why not just yuan-*-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.
>

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 :)

Theo

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

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

[Simen Heggestøyl]

Yuan Fu <casouri@gmail.com> writes:

>> On Nov 13, 2022, at 10:34 PM, Theodor Thornhill <theo@thornhill.no> wrote:
>> 
>> 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?

Sounds good to me!

The json-mode in GNU ELPA is SMIE based and pretty basic like you say,
though it has got some goodies like pretty printing and JSON path
display that I think would be good to keep.

-- Simen

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

[Stefan Monnier]

> Js-json-mode inherits from js-mode,

IIUC this was done because it was convenient rather than because it
was desirable.  So I don't think it's necessary to preserve this detail.


        Stefan

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

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 13 Nov 2022 17:16:13 -0800
> 
> 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 don't object to better names, but they should be better.
"neo-SOMETHING" doesn't strike me as better, because being "new" is a
momentary state.

> 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.

If they can be joined, I'd prefer that, as explained in another mail I
just sent.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think it’s fair to make C, C++ and Java modes independent,

Could you say that more clearly?  What would be independent of what?

                                                                 since
  > all the cc-mode options are invalidated when we use
  > tree-sitter.

Can you please describe the problem?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Theodor Thornhill]

On 15 November 2022 05:17:10 CET, Richard Stallman <rms@gnu.org> wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > I think it’s fair to make C, C++ and Java modes independent,
>
>Could you say that more clearly?  What would be independent of what?
>

We now have several modes for the same language. The tree-sitter variant of c-mode is c-ts-mode, with its own set of functionality. The Cc mode modes "own" the namespace which is the most intuitive to use - c-mode. We have discussed how to deal with the naming, and all approaches has its ups and downs. If we were to merge the codebase between the modes, and allowing the name to be the same we would blend two very different approaches and cause, in my opinion, unnecessary complication. Another downside is that cc mode set a lot of before/after-hooks, caches etc that are simply _not_ needed in the tree-sitter variant. Thus it makes sense not to blend them. 

Even though cc modes offer some functionality not present in the tree-sitter variant yet i think it's not the best idea to enable them side by side for performance reasons. Tree-sitter offers around an order of magnitude or more better performance, and losing some of that without very good reasons would be a shame.

So by independent we mean two modes for the C language that doesn't share any code. Two files, no requires or inherits between.

>                                                                 since
>  > all the cc-mode options are invalidated when we use
>  > tree-sitter.
>
>Can you please describe the problem?
>

Most is hopefully described above, but I think a better word is "unnecessary", not invalidated.

I hope that's a little clearer?