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.