Re: feature/tree-sitter: Where to Put C/C++ Stuff

[Theodor Thornhill]

Hi Yuan!

> Before we jump into discussions, I want to note that many of your
> (Theo’s) arguments seem to be against cc-mode rather than “using the
> same major mode”. For major modes that doesn’t use cc-mode (like
> python-mode), tree-sitter and non-tree-sitter features so far coexist
> just fine.
>

Yes, absolutely, but that's mostly because of the nature of complexity
in cc-mode.  For the record - I'm not against cc-mode, I'm actually
pretty impressed.  But I'm wary of the consequences of mixing
complexities here.  Also I'm not sure if cc-mode "owning" java-mode,
js-mode, c-mode, c++-mode etc makes sense.  They are their own
languages, and should maybe live as such.

>> 4: How do we know what to disable?
>> If there's a problem somewhere in the tree-sitter variant of the cc mode
>> derived new mode, and we see some issue - who makes the fix?  For
>> example, previously there was limited support for multiline strings in
>> cc mode, which took almost a year to finalize.  The tree-sitter variant
>> with more performance and accuracy took me maybe 20 minutes in a
>> work-meeting.  Should a feature that is simple to implement in the
>> tree-sitter variant wait for a similar cc mode implementation?  The
>> namespacing seems to suggest that yes, it should.
>
> I don’t think it should (which I think we both agree). And I don’t
> think it’s any problem if a major mode has some tree-sitter-powered
> feature that the non-tree-sitter version doesn’t have.
>

I agree.  For example I'm all for some variant of what we're doing in
js-mode.  I think we're still not there, but mixing _can_ be done.

>> 6: What are the goodies that we really need from CC mode?
>> CC mode provides indentation and font locking.  What else does it
>> provide that isn't replaceable pretty quickly?  I mean this not as a
>> contrarian, but out of real curiosity.  
>
> One thing I found, which might be the only thing, is filling,
> specifically filling the /* */ style comments while respecting all
> style of drawing stars in these comments. I mean all the style like
>
> /*
>  *
>  */
>
> /*=====================================
>
> =======================================*/
>
> Etc, etc. I tried to look at c-mask-paragraph, and it is very
> complicated. Maybe we can use c-fill-paragraph without setting up the
> rest of cc-mode?

Yes, this is true.  Either we can see if it's possible to reuse, or we
can roll our own down the line.  For the record.  Many things that tries
to use fill even in cc mode isn't 100%.  I doubt that using only parts
of cc mode is really feasible without it bleeding in other places, but I
don't have expertise to judge that alone.

>
>> My guess is that we can get to
>> feature parity and well beyond that in a very short amount of time, if
>> we're not hindered by merging everything.
>> 
>> 
>> Sorry for the long mail, but I think we are missing the point by viewing
>> tree-sitter simply as an engine to plop in aside cc mode for
>> convenience, and not the real infrastructure change it is.  There is no
>> need to sunset cc mode, but equally there is no need to limit tree-sitter.
>> 
>
> If mixing cc-mode and tree-sitter brings more problem than merit,
> maybe we can adopt a mutual exclusive policy, where a major mode
> either sets up cc-mode or uses tree-sitter, but never together.
>

This is my hope :-)

>> 
>>> Tree-sitter doesn't (and cannot) replace everything a major mode does
>>> for a programming language.  So a completely new mode means we through
>>> the baby with the bathwater.
>> 
>> I don't agree, but I'm very curious to what else would take a
>> significant effort _apart_ from indentation feature parity with cc mode is.
>
> Tree-sitter is just a tool, obviously there are things a major mode
> provides that doesn’t involve a parser, eg, python’s REPL. But I see
> no prblem putting this feature alongside tree-sitter features in the
> same major mode.
>

I agree with you here as well.

-- 
Theo