Subject: | |
From: | |
Reply To: | |
Date: | Tue, 25 Jun 2013 09:06:56 +0100 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Hello Jura,
On 14/06/2013 11:05, Jura Pintar wrote:
> Dear all,
>
> I’ve recently been re-implementing some of my projects in L3, and
> finding myself having to jump through some hoops to get things I had
> working smoothly in pgfkeys work equivalently well with l3keys. In
> particular, filtering and redirecting keys has been a bit of a chore.
I'm not entirely surprised: pgfkeys is 'object oriented' in a way that
l3keys is not. I also wrote most of it at a time when filtering in
pgfkeys was not developed, so did not even have this in mind as part fo
the process.
> In
> light of this, I have a couple of suggestions for features that could be
> added to the module in due course (to better illustrate what I have in
> mind, I’ve written a quick-and-dirty implementation - appended at the
> bottom of this email; the code seems to work, but I fully expect more
> experienced people could greatly improve it).
Most of the l3keys properties are just wrappers around .code:n, so I
wouldn't bet on it :-)
> 1) It would be good to add a .meta:nn property that takes a path as its
> first argument, so that we could do things like
>
> \keys_define:nn { module / subgroup-i }
> { key-i .code:n = { < code > } }
> \keys_define:nn { module / subgroup-ii }
> { key-ii .meta:nn = { module / subgroup-i } { key-i = #1 } }
>
> instead of having to write
>
> \keys_define:nn { module / subgroup-ii }
> { key-i .code:n = { \keys_set:nn { module / subgroup-i } { key-i = #1 } } }
>
> as is the case right now.
Sounds reasonable: anyone else have a view before I add it?
> 2) It would also be useful to provide a \keys_set_in_subgroups:nnn
> command which would take a list of subgroups in the second
> argument-place, and would cycle through all the subgroups looking for
> keys given in the third argument-place. Then we could write things like
>
> \keys_set_in_subgroups:nnn { module } { subgroup-i , subgroup-ii }
> { key-i = foo , key-ii = bar }
>
> instead of
>
> \keys_set:nn { module / subgroup-i } { key-i = foo }
> \keys_set:nn { module / subgroup-ii } { key-ii = bar }
>
> More importantly, we could then easily define user commands that set
> different subsets of keys. A further command \keys_set_known_in_subgroups:nnnN
> could then be used to catch keys that don’t exist in any of the
> specified subgroups. If this suggestion is accepted, it would also be
> useful to then extend l3keys2e with something like
>
> \ProcessKeysOptionsInSoubgroups { < module > } { < subgroup list > }
>
> so we can use filtering in this context as well.
Here I'm less certain, both in functionality and name terms. I wonder if
we might have a real-life use case for this?
--
Joseph Wright
|
|
|