On 21/08/2011, at 3:26 AM, Joseph Wright wrote:

>> It seems a bit strange that "generate-choices" requires two calls:
> 
> Originally, l3keys followed pgfkeys in having multi-argument keys: we
> originally had '.choices:nn'!

Ah, my memory is short, it seems :)


> However, it seemed to me at the time that
> the concept with a key sis that you set some key to some value, and that
> this worked best in a one-to-one fashion. Thus l3keys has nothing
> directly equivalent to pgfkeys' ".code 2 args", ".code args" or similar.

Right, I think this is what I was thinking of in my earlier comments.


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

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



>> 2.
>> 
>> There is currently a conditional "\keys_if_exist:nnTF" (and friends). What do you think of, additionally, "\keys_if_choice_exist:nnnTF" for which, say,
>> 
>>   \keys_if_choice_exist_p:nnn {fontspec-preparse} {Renderer} {AAT}
>> 
>> returns true?
> 
> Easy to implement, as if is simply an alternative take on
> \keys_if_exist:nnTF. One obvious question is whether you check that
> <key> is a choice in the first place, and if not what the 'correct'
> answer is
> 
>  \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.)


>> 3.
>> 
>> I think it's generally useful to be able to filter lists of keys into their various modules.
> 
> When I was writing l3keys, this idea was not really available in
> pgfkeys. However, there is now a  filter add-on to pgfkeys which does
> exactly what you describe. (See the Tikz manual, section 'Key
> Filtering'.) I find some of the current pgfkeys approach a bit hard to
> follow, so if we do want to go this way will probably come up with a
> proposal of my own. I'll come back on this once I've given it some more
> thought, and hopefully will have an interface idea.

Sure; thanks. I don't think this needs to be too complex; at a bare minimum the xkeyval approach of returning the unset keys works for most cases.


>> 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}]

or

    [CharacterVariant={0.1,4.2,7.8}]

(although that latter one needs a more complex interface that I haven't written yet. Not sure if they'll end up being "0.1" or "0/1" or even "0=1" -- what they mean for "m.n" is "use the $n$-th variation of the character-that-can-be-varied with arbitrary index $m$". For example, you might have a font that has multiple ampersands corresponding to the character variant "0".)

I haven't given much thought to how other packages do things, but assuming mutually-exclusive keys (at least for ones that are defined "manually") might be a little restrictive in some cases. However, I'm perfectly happy to work around this myself in the meantime so perhaps this is an area where I should take a step back and start thinking about a better fontspec interface.

(Of course the old one would still be maintained for backwards compatibility.)


>  (In general, if a key sets several
> things then it is probably best defined as a meta-key which sets several
> other keys. See for example the "mode" or "detect-all" keys in siunitx.)

Thanks, I'll take a closer look.

-- Will