Re: Tree-sitter indentation for js-mode & cc-mode

[Theodor Thornhill]

>> This is cool, but do we really want/need this?  I mean, now we're really
>> binding these implementations together and allowing all the legacy of CC
>> mode to blend in.  We also need knowledge of how CC mode names their
>> syntactic definitions.  IMO one of the big selling points of tree sitter
>> is that you can look at other editors implementation and get inspired
>> immediately.  Now we need deep knowledge of cc mode, don't we?  Also,
>> why would we want cc mode to calculate this for us?  I see what you're
>> trying to do, but _I_ think this is a step in the wrong direction.
>
>You have a point. I tried to blend in cc-mode because that’ll allow us support 
>“styles” and existing user customization. (Also I started out thinking it will 
>be easier to write indentation rules this way which turns out to be not true.) 
>Perhaps it’s better to come up with a new system for customizing indentation 
>style. I’ll revert this change.

I think we can do something similar to the font lock features, can't we? 

>> 
>> But the new one renders it like this:
>> ```
>> const fooClient = new Foo({
>>                            bucket: process.env.foo,
>>                          region: process.env.foo,
>>                          });
>> ```
>> 
>> I know this is a matter of tweaking, but it immediately makes me
>> question the reasoning to blend them.
>
>It’s largely my slip-up rather than inherit defect of the system, but I agree 
>with your opinion above.

Yes, absolutely. My intention was just to make the point with confusion in 
mixing semantics etc. By the way - I think adding more helpers and anchors like 
you've done is nice, so don't just revert blindly, unless you have to :-) 

>> looking up way to much the root of the tree, but you know the internals
>> here better than me.  Is this something we can optimize away? See the
>> attached report at the bottom.
>
>This is very strange, I need to look into it.
>

I'm happy to provide more info and profiling, as well as testing if need be! 

>> 

>> centralized variable to get most, if not all of the "auto-enabling"
>> benefits by just lifting it up:
>> 
>> ```
>>  ;;....
>> 
>>  (cond
>>   ;; Tree-sitter.
>>   ((treesit-ready-p 'js-mode 'javascript)
>>    ;; init all treesitter relevant stuff - can add in _some_ other
>>    ;; non-cc-mode settinigs, such as comment-start, etc above this.
>>    ;; We don't need the cache, detection of js-jsx or any of the
>>    ;; before-change-functions
>> 
>>    (treesit-major-mode-setup))
>>   ;; Elisp.
>>   (t
>>     ;; enable in normal cc mode stuff
>>    )))
>> 
>> ```
>> 
>> This way other hypothetical tree-sitter-v2 in the future is just a
>> simple cond, and no need to worry.
>> 
>> If I'm missing something important here, please let me know, but I
>> _really_ don't understand the reason for merging these implementations.
>
>I don’t have an educated opinion on this. If no one has objections I’ll follow 
>your professional advice ;-)
>

Hah - no professionalism here, but I've spent quite some time in the cc mode 
machinery. 

>> Anyway, thanks for your continued hard work!
>
>Many thanks to you, too!
>
>

My pleasure! 

Theo