LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 25 Jun 2013 22:29:14 +0100
text/plain (47 lines)
On 20/06/2013 23:39, Joel C. Salomon wrote:
> On TeX.SE (, 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