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