Tue, 16 Jul 2013 21:31:08 +0100
On 15/07/2013 05:55, Jura Pintar wrote:
>> For the moment I've gone with my simpler separation of 'keys which have
>> been set' and 'keys which have not'. I've yet to write the docs, which
>> may reveal issues, but my thinking currently is that key filtering is a
>> way to assign only some keys in particular contexts, but that elsewhere
>> either the 'balance' will be set or all keys will be set
> Fair enough. I'm more than happy with the last version! :)
> How would you feel about also adding Fitler/Groups versions of
> \ProcessKeysOptions and \ProcessKeysPackageOptions to l3keys2e?
At present I'm waiting to see what people thing of the code-level stuff.
At the same time, I'm not sure about making package option processing
too complex. The lesson I've learned is that keyval in options is
governed by the LaTeX2e kernel: options are expanded, and checking for
clashes doesn't 'know' about keyval. Thus I tend to think load-time
options should really be limited to things that need to happen there,
with later \<thing>setup to cover more complex option sets.
> There's a typo in row 291 of l3keys.dtx (should be '\enquote' in place
> of '\enquoe’).