8

The listings manual (v1.5b, subsection 4.18) recommends using \lst@definelanguage instead of \lstdefinelanguage in a style file:

Where should I put my language definition? If you need the language for one particular document, put it into the preamble of that document. Otherwise create the local file lstlang0.sty or add the definition to that file, but use \lst@definelanguage instead of \lstdefinelanguage. [...]

However, I can't find a reason for this distinction between \lst@definelanguage and \lstdefinelanguage in either the manual or the developer guide. Is the distinction important?

You may be wondering why I'm asking this question... Well, I've managed to get everything working in my style file using \lstdefinelanguage. That said, I'd like to follow the guidelines laid out in the listings documentation as closely as possible.

However, if I simply substitute \lst@definelanguage for \lstdefinelanguage, I run into problems. Here is an MWE:

\documentclass{article}

\usepackage{filecontents}

% --- generate the style file ---
\begin{filecontents*}{mystyle.sty}
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{mystyle}

\DeclareOption*{\OptionNotUsed}  
\ProcessOptions\relax

\RequirePackage{listings}

\def\mylanguage{Mylanguage}
\expandafter\expandafter\expandafter\lstdefinelanguage%
\expandafter{\mylanguage}{keywords={foo}}

\endinput
\end{filecontents*}
% --- end of style file ---

\usepackage{mystyle}

\begin{document}
\begin{lstlisting}[language=Mylanguage]
foo bar baz
\end{lstlisting}

\end{document}

Everything is hunky-dory with the code above, but if I simply replace \lstdefinelanguage by \lst@definelanguage, the listings packages throws two errors:

Couldn't load requested language.

and

language mylanguage undefined.

This seems to contradict the manual's claim that \lstdefinelanguage and \lst@definelanguage have the same syntax; at least, based on my simple test, they don't seem equivalent when in comes to expansion of their first argument.

Should I use \lst@definelanguage instead of \lstdefinelanguage and how can I get the former to work in my MWE?

jub0bs
  • 58,916
  • Just to be clear: Your language is actually in a package file and this one you tried with \usepackage{yourlang.sty}? – Speravir Feb 17 '14 at 02:08
  • @Speravir Correct. See my edit. – jub0bs Feb 17 '14 at 06:35
  • 2
    From what I have traced (and the manual says the same): \lst@definelanguage is meant to be used in driver files only. There are three existing ones: lstlang1.sty, lstlang2.sty and lstlang3.sty. One can have a local file lstlang0.sty. In such a file \lst@definelanguage works and should be used, lstlang0.sty would be used by listings automatically if available. For all other use cases (which includes other packages) \lstdefinelanguage seems to be recommended. (I use the latter in my class for my package manuals). – cgnieder Feb 17 '14 at 18:38
  • (I lost track where the internals actually differ: it seems to have to do with how aspects are loaded...) – cgnieder Feb 17 '14 at 18:39
  • 1
    @cgnieder Thanks a lot for that. I had overlooked that discussion about the lstlang0.sty and friends in the developer guide. I had mistakenly assumed that, in the passage I quoted, lstlang0.sty was just a placeholder for some user .sty containing a language definition. You've comforted me in the thought that I can safely use \lstdefinelanguage in my style file. If you make that an answer, I'll accept it. – jub0bs Feb 17 '14 at 20:15
  • @cgnieder I guess the premise of the question is wrong, so maybe I should just delete it... – jub0bs Feb 17 '14 at 23:54
  • @Jubobs , if the manual recommends using \lst@definelanguage, it's just beyond me that you would not use \lst@UserCommand\lst@definelanguage{\lst@DefLang\iftrue}. instead. Of course, we go back to point A, in which the author meant that it is preferable to use lst@definelanguage instead of lstdefinelanguage. Put it to a test, by replacing it to \lst@UserCommand\lst@definelanguage{\lst@DefLang\iftrue} test it out. It must be changed for the sake of reasoning. Whether you or I or cgnieder do not like it, it must be changed – doed Feb 18 '14 at 05:26
  • @Jubobs isn't that what has been suggested since the beginning of TeX? Of course it's better to be safe. But if things are not working, they must be changed. If they collapse, then something else must be done about it. – doed Feb 18 '14 at 05:32
  • 4
    This question is off-topic because it simply stems from a misinterpretation of the listings documentation. – jub0bs Mar 10 '14 at 12:40

0 Answers0