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