Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Transfer-Encoding: 8bit
Message-ID:  <C58398B6-8915-458C-AF38-F3C82F9342B2@gmail.com>
Date:         Sun, 21 Aug 2011 00:46:29 +0930
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: couple of l3keys notes
To: LATEX-L@listserv.uni-heidelberg.de
Precedence: list
Status: R

Hi all,

I'm in the process of converting fontspec from using xkeyval to the keyval interface in expl3 (l3keys). (The main reason for this, besides to better eat our own dogfood, is to remove some restrictions that xkeyval imposes such as not being loadable before \documentclass.)

While doing so I've come up with some notes; comments welcome. I really have enjoyed the conversion, it should be said. What was a little clumsy in xkeyval has generally ended being much cleaner in l3keys. Not to detract from xkeyval, however -- I've been using it for many years and my original code certainly wasn't the cleanest; this is the first time I remember refactoring this options code so it's been mouldering for a while.

* * *

1.

It seems a bit strange that "generate-choices" requires two calls:

\keys_define:nn {fontspec-preparse} {
  Renderer .choice-code:n = { ... } ,
  Renderer .generate-choices:n = {AAT,ICU,Graphite,Full,Basic}
}

(Especially when the code is quite long, the final line can get a bit lost.)
What do you think of an additional keys function on the lines of:

\keys_define:nn {fontspec-preparse} {
  Renderer .choices:nn = {AAT,ICU,Graphite,Full,Basic}{ ... }
}

(Actually now I ponder this a little more I seem to remember it was a design goal for l3keys not to have key functions that take multiple arguments...am I recalling correctly? If that is the case, do we want to reconsider this?)


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?


3.

I think it's generally useful to be able to filter lists of keys into their various modules. (Well, I do it in fontspec and it's the kind of thing that makes inheritance of values easy.)

For example, given a keyval list #1 it's often nice to be able to say

\keys_set:nn {foo} {#1}
...
\keys_set:nn {bar} { <remainder of keys not set by "foo"> }

In xkeyval this is done in a simple manner by assigning all unset keys to a macro that can be accessed later; e.g., if it were like this in l3keys:

\keys_set:nn {foo} {#1}
...
\keys_set:nV {bar} \l_keys_previous_unset_clist

You could also imagine doing it more explicitly with a "filtering" function:

\keys_filter:nnNN {foo} {#1} \l_keys_included_clist \l_keys_leftover_clist
\keys_set:nV {foo} \l_keys_included_clist
...
\keys_set:nV {bar} \l_keys_leftover_clist


I'll provide my own local definition of the xkeyval approach in fontspec; do you think one of these should be added to l3keys proper? If the former, I imagine it would have to act in concert with the current "unknown" key setting. But I'm more in favour of the latter choice because it would then not conflict with current error handling.


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

*  *  *

That's all for tonight!

-- Will