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