On 21/08/2011 08:41, Will Robertson wrote:
>> I'd agree that this may not be ideal in this particular case, as choices
>> are somewhat different from other ideas. I'm happy to make this switch
>> if it feels overall more 'natural' to do ".choices:nn". After all, the
>> entire idea of l3keys is to make defining key-value input as easy as
>> possible.
> 
> I think it's worth trying out, but I'd prefer it if I wasn't the only one saying it was a good idea.

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?

> While we're talking about .choices: I should mention another item that popped into my head. Would it be worth having another key function along the lines of ".add_choice:n {...}" so you could write
> 
> \keys_define:nn {foo}
>   {
>     bar .choices_code:n {...} ,
>     bar .generate_choices:n {a,b,c}
>   }
> ...
> \keys_define:nn {foo} % perhaps inside some user-facing code
>   {
>     bar .add_choice:n {d}
>   }
> 
> ? The idea being that key choices could be extensible. Again, I'm not 100% sure this is even a good idea, but it's something that I kinda do in fontspec (for adding new font features), although it's not a major part of the code. (And I can also use the manual choice generation code to implement, so it's not critical.)

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.

>>  \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.

>>> 4.
>>>
>>> Implicit mapping for multiple key choices; what do you think the expected behaviour is here?
>>>
>>> \keys_define:nn {foo}
>>>  {
>>>    key .choice: ,
>>>    key / aaa .code:n = \typeout{aaa} ,
>>>    key / bbb .code:n = \typeout{bbb} ,
>>>  }
>>> \keys_set:nn {foo} {key={aaa,bbb}}
>>>
>>> I would be inclined to disallow "," inside a choice name (if that's not already the case) and automatically map over this list. Is this a bad idea? (Of course, happy to do this manually in my own code.)
>>
>> Here I'm a bit confused. The idea of a multiple-choice key is that they
>> are mutually-exclusive. I guess that you have a particular use case in
>> mind here, but I wonder if that means you have some badly-defined keys.
>> Could you give more detail on this?
> 
> 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.)

(Still need to come back on point 3.)
--
Joseph Wright