Hello Ulrike, >> I wonder if the pgfkeys idea of using one macro to create and set keys >> is confusing. [snip] >> do other people think that strict separation: [snip] >> is clearer? > > Yes. Okay, that fits with what I've been thinking. I'll look at this again and implement what I've suggested in my mail. >> The other question is how to make keys in this way. keys3 uses the idea >> of properties: >> >> key name/.property = value >> >> for example >> >> \module\my~key/.tl_set:N = \l_module_my_tl, >> \module\my~key/.default:n = {default} >> >> to create a key which will store its input in a tl. On the other hand, >> template uses and "extended key-value" approach: >> >> key name =<type> [default] <function> >> >> for example: >> >> my key =n [default] \l_module_my_tl [snip] > I would prefer the two step method -- because it probably means that > you can change the default independently from the function. That again fits broadly with my thinking. > (I haven't never really tried to use pgfkeys because the last time I > looked at it it wasn't babel safe and all the spaces in the key > names in the documentation make me nervous.) The babel problem remains with pgfkeys. Not a problem for LaTeX3 as everything will be built on l3keyval, which is active-character safe (or more accurately, has two routines, one of which is babel-safe and is therefore for user input). The spaces really should not be an issue: it is all building things from csname. With LaTeX2e package options with spaces *are* a problem, but that is not an issue for run-time keys and should not be for LaTeX3 package options! -- Joseph Wright