User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
References: <C58398B6-8915-458C-AF38-F3C82F9342B2@gmail.com>                   
            <4E4FF538.7070601@morningstar2.co.uk>           
            <9788A2B7-3E8F-4D2C-A52E-10999BCB59FA@gmail.com>           
            <4E516DF2.4040002@morningstar2.co.uk>
            <104nbkj0nr84x.dlg@nililand.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E523217.2080408@morningstar2.co.uk>
Date:         Mon, 22 Aug 2011 11:40:23 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: couple of l3keys notes
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <104nbkj0nr84x.dlg@nililand.de>
Precedence: list
Status: R

On 22/08/2011 09:05, Ulrike Fischer wrote:
> In chessboard I use the xkeyval feature to pass remaining keys to
> order the processing: I have three types of keys: initialization,
> setting properties of the board, filling the board which must be
> processed in this order. 
> 
> So I'm using something like this
> \def\chessboard #1 {
>   \setkeys*  {init} {#1}
>   \setrmkeys*{set}  {#1}
>   \setrmkeys {fill} {#1}
> 
> The main difference in this approach compared to three simple
> \setkeys commands are in the *:  It means that unknown keys will
> pass the first setkeys but the last \setrmkeys command will give an
> error if there remains a key unknown. Can this be done with l3keys?

Currently this can be done only using an approach similar to the one
Will outlined, for example

\keys_define:nn { chess / init }
  { unknown .code:n = { \chess_keys_filter:n {#1} } }
\keys_define:nn { chess / set}
  { unknown .code:n = { \chess_keys_filter:n {#1} } }

\cs_new_protected:Nn \chess_keys_filter:n
  {
    \clist_put_right:Nx \l_chess_keys_leftover_clist
      { \l_keys_key_tl = { \exp_not:n {#1} } }
  }

\cs_new_protected:Nn \chess_keys_set:nn
  {
    \clist_clear:N \l_chess_keys_leftover_clist
    \keys_set:nn { chess /#1 } {#2}
  }
\cs_generate_variant:Nn \chess_keys_set:nn { nV }

\cs_new_protected:Npn \chessboard #1
  {
    \chess_keys_filter:nn { init } {#1}
    \chess_keys_filter:nV { set }  \l_chess_keys_leftover_clist
    \keys_set:nV { chess / fill } \l_chess_keys_leftover_clist
  }

where the fact that "unknown .code:n" is not set for "chess / fill"
means that the standard unknown routine (i.e. an error) still applies.

Now while this is okay, the point I guess is that a cleaner interface is
desirable. One simple approach would be to define \keys_set_known:nn,
which does the same as \keys_set:nn but (a) raises no error for unknown
keys and (b) stores unknowns in some defined place. This might lead to

  \keys_set_known:nn { chess / init } {#1}
  \keys_set_known:nV { chess / set } \l_keys_unknown_keyvals_clist
  \keys_set:nV { chess / fill } \l_keys_unknown_keyvals_clist

(I'm imagining \l_keys_unknown_keyvals_clist contains the keys plus
values, with \l_keys_unknown_keys_clist just containing the key names.)

An obvious question then is whether to provide an 'internal' recycle,
similar to \setrmkeys, or just to provide the list as a variable and
leave it to the programmer to do the recycling.
--
Joseph Wright