On 20/06/2013 23:39, Joel C. Salomon wrote: > On TeX.SE (http://tex.stackexchange.com/q/120258/2966), Prof. Enrico > “egreg” Gregorio helped me set up the below code, which sets up an > l3keys definition from a clist. > > Note that the property `.generate_choice:V` has to be created; is it > perhaps a useful addition to l3keys? > > Note also the way I've set the default value to the first element of > the clist. I would assume that the "idiomatic" way would be > > font .initial:o = { \clist_item:Nn \c_jcsfonts_clist {1} }, > > or something like that, but of course, the property `.initial:o` > doesn't exist. And unlike the rest of Expl3, there is no clean way to > generate variants of l3keys properties; egreg's code needed to call on > `\__`-private functions. Might this, too, be a useful addition to the > package? > > Code follows. > > —Joel Salomon I see that this is the second simultaneous thread on l3keys: clearly a useful part of expl3 :-) I'm not quite sure how to handle the general 'variant generation' question: unlike arbitrary functions, I'd imagine that the key properties form a defined set. On the other hand, it certainly would be possible to provide some form of interface to allow extensions: at the moment, 'not sure'! I guess for the moment I can look at adding some additional variants: the cost is low. The question reminds me of a broader point: the business about generating choices. My original preference was that properties should take a single "n"-type argument key-name .property:n = value as this uses 'all' of the value. That led to the .choice_code:n/.generate_choices:n stuff. Later, I was not so sure that was the best plan (not all that clear), hence bringing in .choices:nn to do both parts in one. (I see the other key-related thread also asks for 'two-part' key properties, so this looks not-unpopular as an interface.) I'd like to know what other people think of the two approaches. -- Joseph Wright