1

Why does a choice key not save it’s value to a macro as a cmd key and as the corresponding xkeyval \define@choicekey do?

In the following example I have to define my@key manually by using the callback.

\documentclass{article}

\usepackage{keyreader}

\krddefinekeys*{CL}[my]{%
   choice/keya/one/
      one,two,three/\def\mykeya{#1};
   choice/keyb/aa/
      aa,bb,cc,dd;
}

\begin{document}
\mykeya% works
and
%\mykeyb% doesn't work
\end{document}

With xkeyval it is possible to define a bin i.e. a macro that saves the value:

\define@choicekey*{CL}{keyc}[\mybin]{alpha,beta,gamma,epsilon}[alpha]{}

an later \mybin holds the value of keyc

Tobi
  • 56,353

1 Answers1

2

The command \define@choicekey of the xkeyval package doesn't yield a macro of the form \<macro-prefix>@<key-name> to hold the user input. The command \krddefinekeys of the keyreader package uses xkeyval's \define@choicekey in the background.

The feature you're asking for is available only in the ltxkeys package. Try the following:

\documentclass{article}
\usepackage{ltxkeys}
\makeatletter
\ltxkeys@declarekeys*{fam}[my]{%
% choice/<key name>.{<alternate values>}/<default>/<callback>;
  choice/keya.{one,two,three}/one;
  choice/keyb.{aa,bb,cc,dd}/aa;
% cmd/<key name>/<default>/<callback>;
  cmd/keyc/cc/\def\xc##1{##1xx#1};
}
\makeatother

\begin{document}
\mykeya, \mykeyb\space and \mykeyc
\end{document}
Ahmed Musa
  • 11,742
  • But I can define a bin to save the value, please see my edit. Thath’s what I meant but had it wrong in my mind O:-) – Tobi Mar 04 '12 at 02:34
  • Yes, you can define two bins \bina (to hold current user value) and \binb (to hold the numerical order of the user input, starting from 0). Your \mybin is well placed. NOTE: It is advisable to always provide a key prefix (eg, [TOB]) and a family (eg, {tobi}). – Ahmed Musa Mar 04 '12 at 03:19
  • OK. But I can’t define a bin with \krddefinekeys right?. Why is it better to define a prefix? And why it this argument optional, though? – Tobi Mar 04 '12 at 12:20
  • I have uploaded onto CTAN a version of keyreader package that allows macro prefixes to be used in \krddefinekeys for choice keys (like it has always been for command keys). It will take perhaps 24 hours before the upload is propagated to mirror sites. So for a choice key keya, you can now have \mykeya as you wanted. Note: Providing both key prefix and family makes your keys unique and reduces the chances of name clashes within and between packages. The default value of key prefix is often KV. – Ahmed Musa Mar 04 '12 at 16:03
  • Thanks for the upload! I’ll do my update tomorrow. But if I define a <mpprefix> (\my) in my example the prefix isn’t uses anywhere, is it? – Tobi Mar 04 '12 at 17:22
  • @Tobi: What do you mean by 'isn't used anywhere'? After the upgrade, your example above should work for \mykeya and \mykeyb. You won't need to define \def\mykeya{#1} yourself. – Ahmed Musa Mar 04 '12 at 21:27
  • In my understanding of the prefix it is used do define the macros saving the value, e.g. \cmdKV@keya. But if I define the mprefix it’s \mykeya so the prefix isn’t used and for that can’t help to avoid conflicts … – Tobi Mar 05 '12 at 00:51
  • @Tobi: If you define your own macro prefix (my as in your example above), then \cmd<keyprefix>@<family>@<keyname> will not be formed and used internally. You can avoid name clash by choosing a unique macro prefix (say, tobi@mypkg@). Another point: in the \krddefinekeys command, the bins for choice keys are always \krduserinput and \krdorder. You can access these bins in the callback but you will hardly need them. This is because the alternative actions, for which the bins were invented by the author of xkeyval package, are already specified within \krddefinekeys by .do=. – Ahmed Musa Mar 05 '12 at 15:19
  • OK, thanks! So in my case, i.e. macro prefix is unique, the prefix isn’t necessary? – Tobi Mar 05 '12 at 15:38
  • I think by 'the prefix isn’t necessary' you're referring to the key prefix and not the macro prefix. Both are not necessary but both are useful. The key prefix is used to define the key macro, normally of the form \<keyprefix>@<family>@<keyname>. Here when both <keyprefix> and <family> are present, they make it less likely that two keys by different authors will have the same key macro, even if they had the same family. If you use only <family> and no <keyprefix>, then an existing family might easily be overwritten. – Ahmed Musa Mar 05 '12 at 17:39
  • The starred variant of \krddefinekeys will raise an error when an existing key is being redefined. So if you must not give <keyprefix>, you should consider using the starred variant of \krddefinekeys always. – Ahmed Musa Mar 05 '12 at 17:39