On March 23, 2023 15:20:50 Yuan Fu wrote: >> On Mar 22, 2023, at 9:55 PM, Daniel Colascione wrote: >> >> >> >> On March 22, 2023 20:21:22 Yuan Fu wrote: >> >>>> On Mar 22, 2023, at 5:05 PM, Daniel Colascione wrote: >>>> >>>> >>>> >>>> On March 22, 2023 19:58:22 Yuan Fu wrote: >>>> >>>>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione 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