LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Thu, 22 May 2014 08:31:53 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=ISO-8859-1
Joseph Wright <[log in to unmask]>
text/plain (72 lines)
On 21/05/2014 23:14, [log in to unmask] wrote:
> Based on the discussion at
> 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