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