GNU bug report logs -
#59763
29.0.60; Filling for c-ts-mode
Previous Next
Reported by: Yuan Fu <casouri <at> gmail.com>
Date: Fri, 2 Dec 2022 05:34:01 UTC
Severity: wishlist
Found in version 29.0.60
Done: Yuan Fu <casouri <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Yuan Fu <casouri <at> gmail.com> writes:
> Theodor Thornhill <theo <at> thornhill.no> writes:
>
>> On 25 December 2022 02:30:35 CET, Yuan Fu <casouri <at> gmail.com> wrote:
>>>
>>>Theodor Thornhill <theo <at> thornhill.no> writes:
>>>
>>>> On 24 December 2022 09:36:21 CET, Yuan Fu <casouri <at> gmail.com> wrote:
>>>>>
>>>>>Theodor Thornhill <theo <at> thornhill.no> writes:
>>>>>
>>>>>> Yuan Fu <casouri <at> gmail.com> writes:
>>>>>>
>>>>>>>> On Dec 2, 2022, at 6:58 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>>>>>
>>>>>>>>> From: Yuan Fu <casouri <at> 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 :-)
Theo
This bug report was last modified 2 years and 135 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.