why should lst@definelanguage be preferred over lstdefinelanguage in a style [closed]

Question

My meta-discussion topic is about the question that follows:

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?

My answer was to change the value to iftrue in the corresponding line of \lst@definelanguage in the file lstmisc.sty of the listings package, and the document, therefore, would compile accordingly.

The only useful remark that one of the main commentators managed to say in the end, was in the lines of: I use \lstdefinelanguage because I don't know the internal commands. endquote. This however, left upon me a disconcerting impression that the commentator was just trying the mend this miserable tore up question. What else?

The other remarks were clearly copied verbatim from the listings manual. That is, the comments about the local file and the use of \lstdefinelanguage, with the corresponding language files that follow. Not surprisingly, the OP was desperately willing to accept this answer.

But this is clearly a vague excuse. A vague excuse that the OP was desperately willing to accept, So desperate in fact, that I am sure he regretted posting the question, he regretted further elaboration of its premises, and generally speaking, asking this kind of question to start with. Then my answer came in, which set off the alarms. Then back to the OP who should have done the homework but he didn't. The commentator, on the other hand, should have provided a better opinion, but he failed. And the bottom line is that this question that I loved so much, me, me, not the OP nor the commentator, is now, sadly, nowwhere to be found. Google cache no longer applies, and the realization that the best answer to fix it, was largely ignored and downvoted, is a fact now.

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

• No, you can't use \lst@definelanguage, because the manual is incorrect, but you can change it to \iftrue
• Yes, you can use \lst@definelanguage because the manual is correct, and you can change it to \iftrue
• It's up to you, you can't use \lst@definelanguage because the manual is incorrect, but you can change it to \iftrue
• It's not up to you, you can use \lst@definelanguage because the manual is correct, but you can change it to \iftrue
• It's not up to you, you can't use \lst@definelanguage because the manual is incorrect, but you can change it to \iftrue.

What are my options? If I only knew how to count. But most important, give me one reason why this question should be deleted.

Answer 1

I just realized that this question is (partly) about me as I was »the main commentator« so I want to present the story from my point of view:

I made honest comments on both question and answer about what I thought and still think:

I for my part am reluctant to change commands from packages and only do so if I know exactly what the changes are doing. Your answer suggested a change in \lst@definelanguage and I asked if you could explain exactly what the change does (except something along the lines of: »the code then works« which I didn't and still don't find a very satisfying answer...). It seemed to me (but maybe I was mistaken) that you knew where, when and why the \iffalse/\iftrue business makes a change so I asked for clarification.

Clarification never came and in consequence I went to study the listings code myself but I must confess that I failed to find out where exactly said \iffalse/\iftrue business makes a difference. (I found some hints but not enough for an answer...) I also studied the listings manual again and commented on the question how I interpreted it:

\lst@definelanguage is only meant to be used in a file called lstlang0.sty. listings already loads lstlang1.sty, lstlang2.sty and lstlang3.sty and would load lstlang0.sty if it finds it. lstlang0.sty is meant as a local addition for a user to have definitions of languages he often uses and in such a file \lst@definelanguage works just fine as it is. (I had tested this...) For every other application \lstdefinelanguage is the way to go. (IMHO the manual could be improved to be more explicit about this.)

I honestly think this is how the listings author intended the commands to be used and the OP seemed to agree with me and shortly after deleted the question. The correct answer here can of course only be given by the author of listings. Everything else is just interpretation of both code and manual. Generally it's up to an OP to decide which answer they deem correct - this is why there is the green tick for answers.

As to why the OP deleted his/her question: everybody is allowed at any point to delete their own question without having to justify it. I liked the question and so did others who voted for it but it's not up to me or anyone else to decide if the question should stay or not. So there's not much you or me or anyone else (except the OP) can do about the question being deleted.

If you really liked the question and think it's worth being there on the main site why don't you just ask a similar question yourself? That would be a perfectly valid thing to do IMHO :)

Answer 2

Well, to be honest, this is a pretty minor issue that can be fixed either, by biting the bullet and reading the code carefully, or mailing the author of the package. Other than that whether it is this or that is not much of a discussion material in my opinion.

There is no need to delete the question by the mods but also no need to undelete by the mods if the owner deleted it.

Couple of things to keep in mind; modifying the original files of the packages is really, really, really bad idea. You change the checksum hence on some systems it causes problems, you can't anticipate behavior of packages that rely on that package, you get name clashes of some other esoteric code in terms of backwards compatibility etc. etc.

So if possible fix it by patching the particular macro not changing any files.