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