5

I want to include Matlab code in my document. The mcode package used to do a great job in combination with my scrbook document class. However, I recently updated my KOMAscript family to version 3.12 and now the mcode package causes an error (incomplete \iffalse). The errror only occurs when I \include a \chapter; not when I prevent the use of \include. The MWE below reproduces the error; the error disappears when I change scrbook into book. Can anyone help me solve the problem?

\begin{filecontents}{testchap.tex}
\chapter{matlab code}
\mcode{function}
\end{filecontents}

\documentclass{scrbook}
\usepackage{mcode}
\usepackage{filecontents}

\begin{document}
\include{testchap}
\end{document}
Sander
  • 147
  • 1
    Not an answer to your question, but... consider using the matlab-prettifier package instead of mcode; see this answer. – jub0bs Mar 05 '14 at 21:01
  • Please make your code compilable (if possible), or at least complete it with \documentclass{...}, the required \usepackage's, \begin{document}, and \end{document}. That may seem tedious to you, but think of the extra work it represents for TeX.SX users willing to give you a hand. Help them help you: remove that one hurdle between you and a solution to your problem. – jub0bs Mar 05 '14 at 21:02
  • The code is already a complete MWE, including the required packages and \begin{document}, and end{document}. – Sander Mar 05 '14 at 21:15
  • Why are you using a filecontents environment before loading the filecontents package? – jub0bs Mar 05 '14 at 21:20
  • Inspired - but possibly incorrectly - by another example on this forum ... it does work though ;-) – Sander Mar 05 '14 at 21:31
  • 1
    @Sander well the filecontents package isn't used at all, it's just loaded so "work" depends on your definition, also as you see in my MWE you don't actually need to include a file at all, simply having \chapter is enough. – David Carlisle Mar 05 '14 at 21:48
  • mcode seems not to be on CTAN. So, a link to it would have been useful. I want to link instead to Werner’s answer with a link: What can I use to typeset MATLAB code in my document?. – Speravir Mar 06 '14 at 02:46

2 Answers2

9

scrbook defines a macro \ifnumbered that isn't a TeX if which is not necessarily wrong but it is a bit dangerous and here mcode pushes you over a cliff.

You can restore scrbook s definition:

\documentclass{scrbook}
\let\zz\ifnumbered
\usepackage{mcode}
\let\ifnumbered\zz

\begin{document}

%\tracingall
\chapter{matlab code}





\end{document}
David Carlisle
  • 757,742
  • +1 Well spotted. Of course, I'm biased against mcode but, in all objectivity, it's a shame it doesn't use @ in its internals. – jub0bs Mar 05 '14 at 21:10
  • @Jubobs I'd say it was scrbook mostly to blame for this clash:-) – David Carlisle Mar 05 '14 at 21:11
  • 1
    mcode uses an \ifnumbered switch, which is set to true if the mcode package option called numbered is used. Arguably, that switch should have been called \mcode@ifnumbered or something like that. I don't think scrbook should be blamed, here :) But I agree that starting a macro by "\if" when that macro is not a switch is bad practice. – jub0bs Mar 05 '14 at 21:13
  • @Jubobs there is a well entrenched convention going back to plain tex that macros called \ifzzzz are defined via \newif and have definition that is always \iftrue or \iffalse, had scrbook followed that convention it wouldn't matter if two packages define the same if. – David Carlisle Mar 05 '14 at 21:16
  • I guess both mcode and scrbook should be blamed, but for different reasons. – jub0bs Mar 05 '14 at 21:17
  • @DavidCarlisle It may not have mattered for this case, because scrbook only uses \ifnumbered locally. But mcode sets it globally and it would matter if another package (globally) defined the same if. So mcode really should have privatized their command. – Dan Mar 07 '14 at 19:26
  • @Dan well more important than who defined \ifwhatever is who gets the green tick and I see that's you in this case:-) – David Carlisle Mar 07 '14 at 20:29
5

Both komascript classes and mcode define \ifnumbered in incompatible ways. This is surely the cause of the problem. One or the other (ideally both) should change the name of this switch, especially if it is needed only for internal purposes. I edited mcode.sty, changing instances of "numbered" (in \ifnumbered and \numberedtrue) to "mcode@numbered", and the MWE compiled fine.

\ifnumbered is used by scrbook.cls to discriminate between numbered and unnumbered chapters. It is used by mcode to discriminate between numbered and unnumbered code lines. In both cases it does seem to be an internal command and care should have been taken to choose a name not likely to cause such a conflict.

A workaround is to perform the described edits of mcode.sty. Here's the diff:

100,101c100,101
< \newif\ifnumbered
< \DeclareOption{numbered}{\numberedtrue}
---
> \newif\ifmcode@numbered
> \DeclareOption{numbered}{\mcode@numberedtrue}
118c118
< \ifnumbered\typeout{ - line numbering enabled}\else\fi
---
> \ifmcode@numbered\typeout{ - line numbering enabled}\else\fi
141c141
< \ifx\textquotesingle\undefined%
---
> \ifx\textquotesingle\undefined%
202c202
< \ifnumbered% numbered option
---
> \ifmcode@numbered% numbered option
212c212
<   \ifnumbered%
---
>   \ifmcode@numbered%
Dan
  • 6,899