bug#59763: 29.0.60; Filling for c-ts-mode

[Yuan Fu <casouri@gmail.com>]

> On Dec 26, 2022, at 2:03 PM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> Theodor Thornhill <theo@thornhill.no> writes:
>> 
>>> On 25 December 2022 02:30:35 CET, Yuan Fu <casouri@gmail.com> wrote:
>>>> 
>>>> Theodor Thornhill <theo@thornhill.no> writes:
>>>> 
>>>>> On 24 December 2022 09:36:21 CET, Yuan Fu <casouri@gmail.com> wrote:
>>>>>> 
>>>>>> Theodor Thornhill <theo@thornhill.no> writes:
>>>>>> 
>>>>>>> Yuan Fu <casouri@gmail.com> writes:
>>>>>>> 
>>>>>>>>> On Dec 2, 2022, at 6:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>>>>>> 
>>>>>>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>>>>>>> Date: Thu, 1 Dec 2022 21:33:06 -0800
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> IMO For c-ts-mode to be usable we need to have at least a basic filling
>>>>>>>>>> function. Below is the function I have in my init.el, could someone have
>>>>>>>>>> a look and see if it’s good? Alternatively we could copy out the comment
>>>>>>>>>> and fill it in a temp buffer with c-mode, but I didn’t have the time to try
>>>>>>>>>> it out and see how well it works.
>>>>>>>>> 
>>>>>>>>> Thanks.
>>>>>>>>> 
>>>>>>>>> From quick testing, I see a problem:
>>>>>>>>> 
>>>>>>>>> . Visit dispnew.c and go to the comment that starts on line 324.  Delete
>>>>>>>>>   the newline between the two lines of the comment, and invoke the
>>>>>>>>>   function.  Observe how the first non-blank character of the comment's
>>>>>>>>>   second line is aligned with the "/*" on the previous line, not with the
>>>>>>>>>   text after "/*" as I'd expect.
>>>>>>>> 
>>>>>>>> I see. I’ll need to look at how cc-mode fill comments.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Btw, this command should be bound to M-q in ts-c-mode.
>>>>>>>> 
>>>>>>>> Will do, once our fill function works well. BTW, Theo, if you have any
>>>>>>>> idea, don’t hesitate to go ahead :-) No obligations, of course.
>>>>>>>> 
>>>>>>>> Yuan
>>>>>>> 
>>>>>>> Sure!  Added to my list :)  I had a function at some point that used
>>>>>>> c-mode to do this. I'll see if I can polish it a little.
>>>>>> 
>>>>>> I did some work in filling, it should work like cc-mode in like 90% of
>>>>>> the cases now, yay!
>>>>>> 
>>>>>> Yuan
>>>>> 
>>>>> Nice! For all cc-ts-modes?
>>>> 
>>>> I only added for c and c++, but support for other modes should be
>>>> identical. And I think we should have something equivalent to cc-mode’s
>>>> init which sets up things that are the same in all C-like languages,
>>>> basically comments and filling.
>> 
>> I added indent and filling for other C-like modes.
>> 
>>>> But I wonder where should we put it, I guess it’s fine to leave it in
>>>> c-ts-mode, since there really isn’t much code. Having other modes to
>>>> require c-ts-mode shouldn’t be a big problem, I think?
>>>> 
>>>> Yuan
>>> 
>>> How about just having treesit-utils.el, or something like that? There
>>> are probably many things in the future that will be common among
>>> modes, yet won't really warrant inheritance. I think we have such an
>>> example in js/typescript too, iirc.
>> 
>> If it’s shared across all tree-sitter modes, it should be in treesit.el,
>> of course. We are talking about things shared by tree-sitter C-like
>> modes, so the scope is smaller.
>> 
>> Since right now it’s only a handful functions, I made other modes
>> require c-ts-mode.el. In the future if things accumulate, we can put
>> things into a separate file (c-ts-mode-common.el or something).
>> 
> 
> Sure.  I just don't like it when these namespaces blend too much.  But
> your call :-)

It can be treesit-c-common.el or something. We’ll figure it out when the time comes ;-)

Yuan