Why does passing a wrong (as in non-existing) option to listings upon package loading result in a non-terminating pdflatex run, instead of - say - a simple error message?


Section 2.2 Package loading of listings.pdf indicates that only the words 0.21, final, draft, savemem (and possibly some undocumented experimental switches) are valid options supported on package loading:


However, this didn't stop me from happily trying to include a basicstyle=\ttfamily option that should only be set via \lstset.

Strangely enough, this mistake didn't trigger a simple unknown option error, but instead captured pdflatex in an infinite loop with the last log output being:

! Missing \endcsname inserted.
<to be read again> 
l.2235 \lst@RequireAspects

MnWE (minimum not working example)

%% Ok

%% NOT Ok

\lstinline{int k = 0;}
  • \listings does use a own version of \ProcessOptions, handling the unknown option over to \lst@loadaspects
    – user31729
    Commented Apr 20, 2016 at 9:34

1 Answer 1


You may have noticed that even packages which sport key-value syntax in the options refrain from allowing control sequences in the values.

This has to do with how LaTeX manages the list of options, in order to zap spaces and divide it into pieces at commas.

Since \ttfamily is a command that's defined as robust with \DeclareRobustCommand, it is not allowed where \zap@space is expected to act on.

Low level errors are to be expected in this case, earlier than the package can issue the “unknown option” warning/error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .