3

since I've upgraded from TeX Live 2012 to TeX Live 2013, I have some trouble with a custom package. The package provides some commands that are intended to be used either as standalone commands or embedded within the \keys{} command provided by the menukeys package. The commands use a mechanism I've picked up somewhere to allow for an optional argument - don't know whether it's a good idea to do it that way, but it has worked so far. Now, for some reasons I don't fully understand, the system enters an endless loop until it hits the maximum stack size. Can someone please tell me what went wrong here and what I can do to prevent this?

Thanks Volker

MWE:

\documentclass{scrartcl}
\usepackage{menukeys}

% This would usually be part of my custom package...
\makeatletter
\def\foobar{\@ifnextchar[\@foobar{\@foobar[]}}
\def\@foobar[#1]#2{foo=#1, bar=#2}
\makeatother

\begin{document}
without optional argument: \foobar{FOO}

with optional argument: \foobar[BAR]{FOO} 

\keys{some key}

% the next line triggers the error: TeX capacity exceeded, sorry [input stack size=5000].
\keys{without optional argument: \foobar{FOO}}

\keys{with optional argument: \foobar[BAR]{FOO}}
\end{document}
  • 2
    \protected\def\foobar should do. BTW: why aren't you using \newcommand\foobar[2][]{foo=#1, bar=#2} (or, to avoid the error you're getting here, the robust version \newrobustcmd\foobar[2][]{foo=#1, bar=#2} provided by the etoolbox package)? – cgnieder Jul 7 '13 at 16:37
5

The last version of menukeys introduced some \edef which are wrong and lead to infinite recursion whenever commands such as \textbf or fragile command like yours are used.

You should define \foobar with \DeclareRobustCommand anyway, if you plan to use it in the argument to menukeys, but the current version would fail in the same way. So ideally you should have

\DeclareRobustCommand\foobar{\@ifnextchar[\@foobar{\@foobar[]}}

and if the wrong \edef are changed to the correct \protected@edef it might work. Even better, you should use \newcommand:

\newcommand{\foobar}[2][]{foo=#1, bar=#2}

without using explicitly \@ifnextchar.

For the moment, use

\protected\def\foobar{\@ifnextchar[\@foobar{\@foobar[]}}

The suspect \edef commands are at lines 582, 585, 590 and 593.


If I change the suspect \edef commands in menukeys.sty into \protected@edef, the error doesn't show.

  • I got the same stack error with Space bar: \keys{\makebox[2\width][c]{Space}}. Interestingly last TeXLive-2012 version is 1.1b, while TeXLive-2013 contains 1.1a, although package dates are chronological (newer in TeXLive-2013). I sent a bug report to the package author. – AlexG Jul 12 '13 at 9:07
  • @AlexG \keys{\makebox[2\width][c]{Space}} can't work also with the patched version, because \makebox is fragile. And using \protect doesn't help either: it should be \keys{\unexpanded{\makebox[2\width][c]{Space}}}. I don't know why the author added that "full expansion" step to the processing of the argument. – egreg Jul 12 '13 at 9:22
  • Thank you, @egreg, for providing the workaround! The reverse versioning of the package remains mysterious. – AlexG Jul 12 '13 at 9:29
  • I fixed this in version 1.2, which will be available on CTAN soon. – Tobi Jul 23 '13 at 11:15
  • @egreg: I had some more bugs which seem to be fixed by replacing \protected@edef by a simple \def. Is it possible to use \def instead or will that cause any other problems I don’t see yet? … I’d say it’s unnecessary that the \CurrentMenuelement is stored as expanded macro, is it? – Tobi Nov 24 '13 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.