c-ts-mode style customization

c-ts-mode style customization

[Daniel Colascione]

Shouldn't customization of styles in c-ts-mode look more like cc-mode's
style machinery? Right now, the closest thing we have to defining a new
style is add-advice on c-ts-mode--indent-styles, which isn't
particularly convenient or future-proof. You can't drop a new style in,
say, .dir-locals.

Re: c-ts-mode style customization

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Wed, 22 Mar 2023 11:53:41 -0400
> 
> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
> style machinery?

Ideally, yes, or at least as close as reasonably possible.

Patches welcome.

Re: c-ts-mode style customization

[Yuan Fu]

> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
> 
> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
> style machinery? Right now, the closest thing we have to defining a new
> style is add-advice on c-ts-mode--indent-styles, which isn't
> particularly convenient or future-proof. You can't drop a new style in,
> say, .dir-locals.
> 

Actually, you can define a custom function, say, c-ts-mode-my-style, and set c-ts-mode-indent-style to the name of it.

Yuan

Re: c-ts-mode style customization

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]



On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com> wrote:

>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
>>
>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
>> style machinery? Right now, the closest thing we have to defining a new
>> style is add-advice on c-ts-mode--indent-styles, which isn't
>> particularly convenient or future-proof. You can't drop a new style in,
>> say, .dir-locals.
>
> Actually, you can define a custom function, say, c-ts-mode-my-style, and 
> set c-ts-mode-indent-style to the name of it.
>
> Yuan


But that doesn't add the new style to the UI selection menu and doesn't let 
you define a style in dir-locals. IMHO, cc-mode got this right.


[-- Attachment #2: Type: text/html, Size: 1703 bytes --]

Re: c-ts-mode style customization

[Yuan Fu]

> On Mar 22, 2023, at 5:05 PM, Daniel Colascione <dancol@dancol.org> wrote:
> 
> 
> 
> On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com> wrote:
> 
>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
>>> 
>>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
>>> style machinery? Right now, the closest thing we have to defining a new
>>> style is add-advice on c-ts-mode--indent-styles, which isn't
>>> particularly convenient or future-proof. You can't drop a new style in,
>>> say, .dir-locals.
>>> 
>> 
>> Actually, you can define a custom function, say, c-ts-mode-my-style, and set c-ts-mode-indent-style to the name of it.
>> 
>> Yuan
> 
> 
> But that doesn't add the new style to the UI selection menu and doesn't let you define a style in dir-locals. IMHO, cc-mode got this right.

You can set c-ts-mode-indent-style in dir-locals, no? You have a point for UI selection, we can add a c-ts-mode-indent-style-alist that maps style names to rules/functions that returns rules, like c-style-alist.

Yuan

Re: c-ts-mode style customization

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]



On March 22, 2023 20:21:22 Yuan Fu <casouri@gmail.com> wrote:

>> On Mar 22, 2023, at 5:05 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>
>>
>>
>> On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com> wrote:
>>
>>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>
>>>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
>>>> style machinery? Right now, the closest thing we have to defining a new
>>>> style is add-advice on c-ts-mode--indent-styles, which isn't
>>>> particularly convenient or future-proof. You can't drop a new style in,
>>>> say, .dir-locals.
>>>
>>> Actually, you can define a custom function, say, c-ts-mode-my-style, and 
>>> set c-ts-mode-indent-style to the name of it.
>>>
>>> Yuan
>>
>>
>> But that doesn't add the new style to the UI selection menu and doesn't let 
>> you define a style in dir-locals. IMHO, cc-mode got this right.
>
> You can set c-ts-mode-indent-style in dir-locals, no?

No, because I can set that variable only to one of the predefined styles or 
to a function, and a function isn't a safe value of a directory local variable.

> You have a point for UI selection, we can add a 
> c-ts-mode-indent-style-alist that maps style names to rules/functions that 
> returns rules, like c-style-alist.

Why this emphasis on functions? Why would we want the alist values to be 
functions instead of just lists of rules?


[-- Attachment #2: Type: text/html, Size: 3184 bytes --]

Re: c-ts-mode style customization

[Yuan Fu]

> On Mar 22, 2023, at 9:55 PM, Daniel Colascione <dancol@dancol.org> wrote:
> 
> 
> 
> On March 22, 2023 20:21:22 Yuan Fu <casouri@gmail.com> wrote:
> 
>>> On Mar 22, 2023, at 5:05 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>> 
>>> 
>>> 
>>> On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com> wrote:
>>> 
>>>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>> 
>>>>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
>>>>> style machinery? Right now, the closest thing we have to defining a new
>>>>> style is add-advice on c-ts-mode--indent-styles, which isn't
>>>>> particularly convenient or future-proof. You can't drop a new style in,
>>>>> say, .dir-locals.
>>>>> 
>>>> 
>>>> Actually, you can define a custom function, say, c-ts-mode-my-style, and set c-ts-mode-indent-style to the name of it.
>>>> 
>>>> Yuan
>>> 
>>> 
>>> But that doesn't add the new style to the UI selection menu and doesn't let you define a style in dir-locals. IMHO, cc-mode got this right.
>> 
>> You can set c-ts-mode-indent-style in dir-locals, no?
> 
> 
> No, because I can set that variable only to one of the predefined styles or to a function, and a function isn't a safe value of a directory local variable.

I see, then an alist should solve this.

> 
>> You have a point for UI selection, we can add a c-ts-mode-indent-style-alist that maps style names to rules/functions that returns rules, like c-style-alist.
> 
> Why this emphasis on functions? Why would we want the alist values to be functions instead of just lists of rules?

Nothing except that that’s how it is right now. It certainly wouldn’t harm to allow functions, no?

Anyway, I agree with the general idea. I’ll add the option to set a rule alist.

Yuan

Re: c-ts-mode style customization

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]



On March 23, 2023 15:20:50 Yuan Fu <casouri@gmail.com> wrote:

>> On Mar 22, 2023, at 9:55 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>
>>
>>
>> On March 22, 2023 20:21:22 Yuan Fu <casouri@gmail.com> wrote:
>>
>>>> On Mar 22, 2023, at 5:05 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>
>>>>
>>>>
>>>> On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com> wrote:
>>>>
>>>>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>>>
>>>>>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
>>>>>> style machinery? Right now, the closest thing we have to defining a new
>>>>>> style is add-advice on c-ts-mode--indent-styles, which isn't
>>>>>> particularly convenient or future-proof. You can't drop a new style in,
>>>>>> say, .dir-locals.
>>>>>
>>>>> Actually, you can define a custom function, say, c-ts-mode-my-style, and 
>>>>> set c-ts-mode-indent-style to the name of it.
>>>>>
>>>>> Yuan
>>>>
>>>>
>>>> But that doesn't add the new style to the UI selection menu and doesn't let 
>>>> you define a style in dir-locals. IMHO, cc-mode got this right.
>>>
>>> You can set c-ts-mode-indent-style in dir-locals, no?
>>
>>
>> No, because I can set that variable only to one of the predefined styles or 
>> to a function, and a function isn't a safe value of a directory local variable.
>
> I see, then an alist should solve this.
>
>>
>>> You have a point for UI selection, we can add a 
>>> c-ts-mode-indent-style-alist that maps style names to rules/functions that 
>>> returns rules, like c-style-alist.
>>
>> Why this emphasis on functions? Why would we want the alist values to be 
>> functions instead of just lists of rules?
>
> Nothing except that that’s how it is right now. It certainly wouldn’t harm 
> to allow functions, no?
>
> Anyway, I agree with the general idea. I’ll add the option to set a rule alist.

I gave you a concrete example of a disadvantage of using functions that 
return data over just using plain data. The principle of least power 
applies here.



>
> Yuan


[-- Attachment #2: Type: text/html, Size: 4873 bytes --]

Re: c-ts-mode style customization

[Yuan Fu]

> On Mar 23, 2023, at 2:06 PM, Daniel Colascione <dancol@dancol.org> wrote:
> 
> 
> 
> On March 23, 2023 15:20:50 Yuan Fu <casouri@gmail.com> wrote:
> 
>>> On Mar 22, 2023, at 9:55 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>> 
>>> 
>>> 
>>> On March 22, 2023 20:21:22 Yuan Fu <casouri@gmail.com> wrote:
>>> 
>>>>> On Mar 22, 2023, at 5:05 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com> wrote:
>>>>> 
>>>>>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>>>> 
>>>>>>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's
>>>>>>> style machinery? Right now, the closest thing we have to defining a new
>>>>>>> style is add-advice on c-ts-mode--indent-styles, which isn't
>>>>>>> particularly convenient or future-proof. You can't drop a new style in,
>>>>>>> say, .dir-locals.
>>>>>>> 
>>>>>> 
>>>>>> Actually, you can define a custom function, say, c-ts-mode-my-style, and set c-ts-mode-indent-style to the name of it.
>>>>>> 
>>>>>> Yuan
>>>>> 
>>>>> 
>>>>> But that doesn't add the new style to the UI selection menu and doesn't let you define a style in dir-locals. IMHO, cc-mode got this right.
>>>> 
>>>> You can set c-ts-mode-indent-style in dir-locals, no?
>>> 
>>> 
>>> No, because I can set that variable only to one of the predefined styles or to a function, and a function isn't a safe value of a directory local variable.
>> 
>> I see, then an alist should solve this.
>> 
>>> 
>>>> You have a point for UI selection, we can add a c-ts-mode-indent-style-alist that maps style names to rules/functions that returns rules, like c-style-alist.
>>> 
>>> Why this emphasis on functions? Why would we want the alist values to be functions instead of just lists of rules?
>> 
>> Nothing except that that’s how it is right now. It certainly wouldn’t harm to allow functions, no?
>> 
>> Anyway, I agree with the general idea. I’ll add the option to set a rule alist.
> 
> 
> I gave you a concrete example of a disadvantage of using functions that return data over just using plain data. The principle of least power applies here.

Still, it’s largely harmless, and could prove useful for some people, also it’s too late to remove it from emacs-29. And since it’s in emacs-29, I don’t want to go through the trouble removing it in emacs-30 in a backward-compatible way.

Yuan

Re: c-ts-mode style customization

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 23 Mar 2023 16:44:31 -0700
> Cc: emacs-devel@gnu.org
> 
> >> Anyway, I agree with the general idea. I’ll add the option to set a rule alist.
> > 
> > 
> > I gave you a concrete example of a disadvantage of using functions that return data over just using plain data. The principle of least power applies here.
> 
> Still, it’s largely harmless, and could prove useful for some people, also it’s too late to remove it from emacs-29. And since it’s in emacs-29, I don’t want to go through the trouble removing it in emacs-30 in a backward-compatible way.

While all this is true, the question is how bad the problem is.
Daniel says the TS modes are unusable for him due to this issue.

Daniel, could you please post a recipe, starting from "emacs -Q", to
reproduce the "blinking" during editing you described up-thread?
Preferably while editing some code that one can meet reasonably
frequently in practice.  I'd like to play with the example and see
whether the problem is serious enough for us to try to solve it ASAP.
TIA.

Re: c-ts-mode style customization

[Yuan Fu]

> On Mar 23, 2023, at 11:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 23 Mar 2023 16:44:31 -0700
>> Cc: emacs-devel@gnu.org
>> 
>>>> Anyway, I agree with the general idea. I’ll add the option to set a rule alist.
>>> 
>>> 
>>> I gave you a concrete example of a disadvantage of using functions that return data over just using plain data. The principle of least power applies here.
>> 
>> Still, it’s largely harmless, and could prove useful for some people, also it’s too late to remove it from emacs-29. And since it’s in emacs-29, I don’t want to go through the trouble removing it in emacs-30 in a backward-compatible way.
> 
> While all this is true, the question is how bad the problem is.
> Daniel says the TS modes are unusable for him due to this issue.
> 
> Daniel, could you please post a recipe, starting from "emacs -Q", to
> reproduce the "blinking" during editing you described up-thread?
> Preferably while editing some code that one can meet reasonably
> frequently in practice.  I'd like to play with the example and see
> whether the problem is serious enough for us to try to solve it ASAP.
> TIA.

I think you mean the other thread?

Yuan

Re: c-ts-mode style customization

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 24 Mar 2023 00:02:04 -0700
> Cc: dancol@dancol.org,
>  emacs-devel@gnu.org
> 
> 
> 
> > On Mar 23, 2023, at 11:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Thu, 23 Mar 2023 16:44:31 -0700
> >> Cc: emacs-devel@gnu.org
> >> 
> >>>> Anyway, I agree with the general idea. I’ll add the option to set a rule alist.
> >>> 
> >>> 
> >>> I gave you a concrete example of a disadvantage of using functions that return data over just using plain data. The principle of least power applies here.
> >> 
> >> Still, it’s largely harmless, and could prove useful for some people, also it’s too late to remove it from emacs-29. And since it’s in emacs-29, I don’t want to go through the trouble removing it in emacs-30 in a backward-compatible way.
> > 
> > While all this is true, the question is how bad the problem is.
> > Daniel says the TS modes are unusable for him due to this issue.
> > 
> > Daniel, could you please post a recipe, starting from "emacs -Q", to
> > reproduce the "blinking" during editing you described up-thread?
> > Preferably while editing some code that one can meet reasonably
> > frequently in practice.  I'd like to play with the example and see
> > whether the problem is serious enough for us to try to solve it ASAP.
> > TIA.
> 
> I think you mean the other thread?

Yes, sorry about that.