☰

xkeyval define@choicekey - 哪些宏定义无需？

tag-icon • tag-icon macros package-options xkeyval
xkeyval define@choicekey - 哪些宏定义无需？

这xkeyval 手册给出以下语法\define@choicekey*：

\define@choicekey*[〈pre〉]{〈fam〉}{〈key〉}[〈bin〉]{〈al〉}[〈dft〉]{〈func〉}

... 可选项〈bin〉应包含一个或两个控制序列（宏）。第一个将用于存储输入检查中使用的用户输入（因此，当使用带星号的版本时，使用小写字母）

如果我不使用<bin>? 它们是否在我的整个文档中定义，还是仅适用于<func>?

答案1

我们以手册第 7 页的例子为例：

\documentclass{article}
\usepackage{xkeyval}

\makeatletter
\define@key{fam}{key}{%
  I will first check your input, please wait.\\
  \XKV@cc*+[\val]{#1}{true,false}{%
    The input \val\ was correct, we proceed.\\
  }{%
    The input \val\ was incorrect and was ignored.\\
  }%
  I finished the input check.
}
\makeatother

\begin{document}

\setkeys{fam}{key=true}

\val

\begingroup
\setkeys{fam}{key=blurb}

\val
\endgroup

\val

\end{document}

输出为

在此处输入图片描述

因此您会看到，它\val保留了设置键时所赋予的值，并尊重分组。

我在 GuIT 论坛上发现这一点时，一位用户正在定义一个\val宏，并得到了一些惊喜。该文档使用了该类suftesi，它xkeyval利用了类似

\define@choicekey{}{structure}[\val\nr]
    {book,article,collection}[book]{%
      [...irrelevant code...]%
    }

和其他类似设置。每次使用键的设置\val都会导致破坏的定义\val。

我写信给软件包的作者，请他修改示例，以便“bins”@中有一些特殊的名称，但没有得到答复。

至少，suftesi将代码改为使用\suftesi@val并\suftesi@nr用作箱子。

如果您不使用 bin，则在用户级别不会定义任何宏，只有内部宏。

我刚刚检查了 LaTeX 树并且我的怀疑是正确的：许多包使用

\define@choicekey+[<pre>]{<fam>}{<key>}[\val\nr]{...[code]...}

因为手册xkeyval没有明确说明在设置密钥之后箱子的定义是否仍然存在。

\val如果密钥仅在包加载时设置，并且用户为或添加了个人定义，则不会产生不利影响\nr。但如果密钥是在文档开始处（或之后）设置的，则很可能会破坏用户的定义。

太糟糕了。无论如何，如今有比 更好的基于键值的接口xkeyval。

相关内容