Subject: | |
From: | |
Reply To: | |
Date: | Wed, 10 Jun 2009 20:38:06 +0100 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|