LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 22 Aug 2011 11:40:23 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1
From:
Joseph Wright <[log in to unmask]>
Parts/Attachments:
text/plain (66 lines)
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

ATOM RSS1 RSS2