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