Sender: |
|
Date: |
Thu, 22 May 2014 08:31:53 +0100 |
Reply-To: |
|
Message-ID: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
7bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=ISO-8859-1 |
From: |
|
Parts/Attachments: |
|
|
On 21/05/2014 23:14, [log in to unmask] wrote:
> Based on the discussion at http://tex.stackexchange.com/questions/179180
> there seems to be a problem with the definition of \__keys_bool_set:Nn.
> Namely, it is not obvious that the following code should fail
>
> \keys_define:nn { mymodule }
> {
> key-1 .choice: ,
> key-1 / choice-a .bool_set:N = \l_mymodule_choice_a_bool,
> key-1 / choice-b .bool_set:N = \l_mymodule_choice_b_bool
> }
> \keys_set:nn { mymodule } { key-1 = choice-a }
>
> and yet it hangs because \__keys_bool_set:Nn actually creates a choice
> key with the choices 'true' and 'false' under the hood.
>
> I feel it would be more natural if the code above behaved in the same
> way as the following:
>
> \keys_define:nn { mymodule }
> {
> key-2 .bool_set:N = \l_mymodule_choice_a_bool
> }
> \keys_set:nn { mymodule } { key-2 }
>
> In other words, the code that now hangs should just be setting the
> boolean to 'true'. If \__keys_bool_set:Nn and \__keys_bool_set_inverse:Nn
> were redefined along the lines of the code below, we'd get that result.
It's a bit more complicated than that :-)
If you look at the code, any case where someone sets up a 'choice of
choices' will fail. That's not good, and so before any worries about
booleans specifically I'll fix this more general issue. My feeling is
that trying to set up a 'choice of choices' key is an error in the
definition rather than at point of use, so I'm minded to trap such cases
and issue a error message. Does that sound reasonable? For example, what
is something like
key-1 .choice: ,
key-1 / choice-a .choice: ,
key-1 / choice-a / value-1 .code = ...
actually going to achieve?
I have an approach in mind: probably will be checked in later today.
> Finally, and a lower priority: it might also be useful to add the
> properties .bool_set_true:N and .bool_set_false:N as well. For example,
> they could work like this:
One the specifics of boolean keys, I can see the point here about
set_true/set_false as they match 'normal' variable setting. On the other
hand, the original design here was to recognise that a boolean key is
somewhat 'special': it is a choice from a limited range of values.
Moreover, my thinking was that enforcing "true"/"false" as the values
avoided the possible need for people to allow for "on"/"off" or
"yes"/"no" (I've worried about this in the past). It was also meant to
indicate that a boolean key should be one that 'reads' as
<thing> = (true|false)
rather than
<thing> = (foo|bar)
as that seems less useful to the end user (if the options are more
complex than true/false then some other description is needed at the
documentation level anyway).
--
Joseph Wright
|
|
|