# Error in listings file when combined with \lstset and unicode-math package

Today, I wanted to compile a document that worked flawlessly earlier that year. However, LuaLaTex was complaining about some code lines inside of a C++ listing. I boiled the problem down to the following minimal example:

test.tex:

\documentclass{article}
\usepackage{unicode-math}
\usepackage{listings}
\lstset{basicstyle=\scriptsize}
\begin{document}
\lstinputlisting{test.cpp}
\end{document}


test.cpp:

int main()
{
return (int)(-1.l);
}


If I compile with lualatex test.tex I get the following :

(./test.cpp
! Missing number, treated as zero.
global
l.3   return (int)(-1.l
);
?


If I uncomment the unicode-math package or the lstset command or use xelatex, it compiles just fine. What's wrong?

• Welcome to TeX.SX! What is your lualatex --version? It works fine for me :/ Mar 28, 2018 at 15:32
• I can reproduce the problem on MikTeX's LuaLaTeX 1.07.0 (Win 10). An even shorter MWE is \documentclass{article} \usepackage{unicode-math} \usepackage{listings} \lstset{basicstyle=\scriptsize} \begin{document} \begin{lstlisting} - \end{lstlisting} \end{document} Mar 28, 2018 at 15:32
• @PhelypeOleinik it fails with texlive 2018 pretest Mar 28, 2018 at 15:33
• @PhelypeOleinik I'm using LuaTeX, Version 1.0.4 (TeX Live 2017/Arch Linux). Mar 28, 2018 at 19:10
• What's wrong? No idea :) github.com/wspr/unicode-math/issues/454 Mar 29, 2018 at 5:15

It works if you make sure that scriptsize math is set up before listings starts:

\documentclass{article}
\usepackage{unicode-math}
\usepackage{listings}
\lstset{basicstyle=\scriptsize}

\begin{document}
\sbox0{\scriptsize $x$}
\lstinputlisting{test.cpp}
\end{document}

• This walks, swims and quacks like a bug. Any idea what is to blame here? The minus seems to be the problematic character here. But using XeLaTeX solves the issue and so does not loading unicode-math. Mar 28, 2018 at 15:45
• @moewe see Ulrike's answer Mar 29, 2018 at 11:03

The problem is that fontspec/unicode-math reads font dimens with luacode. And while catcodes in the tex code are frozen when the code is read the first time this is not true for values you get from directlua: there the catcode settings of the execution time matters. So when trying to setup the font in the middle of lstlisting (which activates all chars) things explodes.

A similar problem was here Who's at fault with this error concerning csquotes and LuaLaTeX?

The problem can be resolved by explicitly setting the catcode table in the first argument of tex.sprint when reading the dimens. I added this suggestion to the github tracker of unicode-math.

\documentclass{article}
\usepackage{unicode-math}
\RequirePackage{luacode}
\begin{luacode}
local latexcatcodetable = luatexbase.registernumber("catcodetable@latex")
function fontspec.mathfontdimen(fnt, str)
if mathdimens then
tex.sprint(latexcatcodetable,mathdimens)
tex.sprint(latexcatcodetable,"sp")
else
tex.sprint(latexcatcodetable,"0pt")
end
end
\end{luacode}

\usepackage{listings}

\lstset{basicstyle=\scriptsize}
\begin{document}

\begin{lstlisting}
-
\end{lstlisting}

\end{document}

• you can use latex defined as local latex = luatexbase.registernumber("catcodetable@latex") instead of luatexbase.catcodetables.latex then you don't need luatexbase (or luacode) packages. Mar 29, 2018 at 9:28
• @DavidCarlisle I edited the answer (and I need luacode for the example ...) Mar 29, 2018 at 9:35
• I find it's usually simpler to use \directlua directly Mar 29, 2018 at 9:55
• @DavidCarlisle Hm. yes. But I normally avoid directlua for more than three lines -- I'm getting to easily confused when I want to comment parts of the code. Mar 29, 2018 at 10:47
• Ohhhh of course. This isn’t the first bug like this to have reared its head. Thanks! Mar 29, 2018 at 11:58