Subject: | |
From: | |
Reply To: | |
Date: | Mon, 22 Aug 2011 20:14:15 +0100 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On 22/08/2011 13:28, Ulrike Fischer wrote:
> Am Mon, 22 Aug 2011 11:40:23 +0100 schrieb Joseph Wright:
>
>
>> 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.
>
> I think I would prefer a list, it's more flexible (and easier to
> inspect if something goes wrong).
I have added the scheme broadly as outlined above to l3keys. Feedback
would be welcome. For example, does 'set_known' convey the appropriate
idea? Show the variable used for storing the 'return' value be fixes, or
flexible as in
\keys_set_known:nnN { <module> } { <keys> } <return-var>
--
Joseph Wright
|
|
|