On 21/08/2011, at 6:48 PM, Joseph Wright wrote: > I think this has been raised before, actually. I've never been 100% > happy with .generate_choices: anyway. I'll add a function as an > experimental addition, in case we need to change it again. Perhaps > ".autochoices:nn" to reflect the fact that choices can also be made > manually? I'm happy with either .auto_choices:nn or .choices:nn. I think it's clear enough that manual choices will work either way. >> \keys_define:nn {foo} % perhaps inside some user-facing code >> { >> bar .add_choice:n {d} >> } >> >> ? The idea being that key choices could be extensible. > > Life gets a bit complicated tracking which option number is which if you > do this. I think in a case such as this I'd favour sticking to making > choices manually, as the additional benefit does not seem to balance out > with the complexity. Ah, I'd not thought about that. You're right, this would be messy; forget this! >>> \keys_if_choice_exist_p:nnn { <fam> }{ <some-non-choice-key> } >>> { <whatever> } >> >> I'd be happy with always returning false here -- I don't think a warning or error message would be very helpful in the long run although I could be mistaken. (A case where Morten's "TFE" signature might have come in handy.) > > Added to code: this one seems non-controversial enough. Thanks. >> I suppose fontspec is a little odd in its keyval approach when viewed through this lens. It's perfectly reasonable (in fontspec!) to write options like >> >> [Numbers={OldStyle,Proportional}] > > To me, this looks like a meta-option of two boolean choices. We don't > currently have a 'meta-in-other-paths', so I'd do something like > > \keys_define:nn { fontspec } > { Numbers .code:n = \keys_set:nn { fontspec / Numbers } {#1} } > \keys_define:nn { fontspec / Numbers } > { > OldStyle .bool_set:N = \l_fontspec_Numbers_OldStyle_bool , > Proportional .bool_set:N = \l_fontspec_Numbers_Proportional_bool , > } > > Perhaps we need something like ".multichoice:", which would do the same > as the above automatically. (This is not that disimilar to what .choice: > does.) This is essentially the approach I was using with xkeyval; I always thought it was a bit clunky (admittedly, less so here). I think I like the idea of .multichoice:, as having both mutually-exclusive and multiple-choice options seems like a fairly sensible breakdown -- does anyone else have any comments on this? -- Will