Re: c-ts-mode style customization

[Daniel Colascione <dancol@dancol.org>]

[-- 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 --]