A recent update to my TeX Live installation appears to have given rise to an incompatibility between two packages: pageslts and tikz. The following document does not compile:


The error I get is:

! Undefined control sequence.
\@currname ->\@nil

l.10 \begin{document}

It is possible to workaround this problem by loading tikz before loading pageslts. However, this would require me to load tikz in custom class and package files since I use pageslts there. If possible, I'd like to avoid doing this as most of my documents do not require TikZ and I'd rather not load it when not needed.

One approach would obviously be to create class/package options allowing me to specify when TikZ is required. However, I'm wondering if that is the best approach or if there's a better solution.

Right now, pageslts is causing me a great deal of grief - this is the second package I've discovered must now be loaded first. (At least the first case gave me a semi-helpful error message.)

So if there is a good alternative to pageslts, I'd be interested in learning about it since the package seems to have suddenly become rather finicky and no longer gets along nicely with anything else!

  • I'd call this a bug. By the way, pageslts calls \listfiles, which is very annoying. – egreg Aug 14 '15 at 22:11
  • @egreg Oh, is it this that's responsible? I was going to track that down but the errors have been taking priority. It is, indeed, very annoying. Is it a bug even though changing the loading order avoids the error? mathtools also now must be loaded before pageslts. The documentation says that the package no longer requires e-TeX but I'm not clear why that is meant to be such an advantage! – cfr Aug 14 '15 at 22:18
  • The problem with \listfiles shouldn't be connected with the bug. – egreg Aug 14 '15 at 22:23
  • @egreg I didn't really expect it to be ;). But is it a bug if it just requires a different load order? That's not uncommon, after all. – cfr Aug 14 '15 at 22:25

The bug is in lines 115–119 of pageslts.sty, where \@currname is used in a \@for cycle, leaving a definition of \@currname, which is unexpected.

If I change the three occurrences of \@currname with \next, the problem disappears.

Of course, also the appearance of \listfiles on line 111 is wrong, but this is unrelated, only annoying.

The macro \@currname is used during package loading, for making a stack in order to correctly reset the status of @ as a letter or as an “other character”. It is also reused in \listfiles as the placeholder for a \@for cycle, but in that case it's not a problem, because \listfiles is processed only at the end of a job. The similar usage by pageslts instead is wrong, because it clearly interferes with package loading. If you add \errorcontextlines=100 at the beginning of the test file you get

! Undefined control sequence.
\@currname ->\@nil 

\@pushfilename ...ef \@currnamestack {{\@currname 
                                                  }{\@currext }{\the \catcod...

\@onefilewithoptions #1[#2][#3]#4->\@pushfilename 
                                                  \xdef \@currname {#1}\glob...

\reserved@a ...ds[{}][{2007/11/11}]\@pkgextension 
<argument> ...uirePackage {pdftexcmds}[2007/11/11]
                                                  \expandafter \ifx \csname ...

\@secondoftwo #1#2->#2

\@begindocumenthook ...base}[2009/07/12]\fi \fi }}
                                                   \pgfsys@atbegindocument \...

\document ...ent \@firstofone \@begindocumenthook 
                                                  \ifdim \topskip <1sp\globa...
l.5 \begin{document}

showing that the problem is when processing \RequirePackage{pdftexcmds}.

  • 1
    Thanks! I've reported this to the package author, quoting the first two paragraphs of your answer. I agree \listfiles is annoying but I suppose it isn't technically wrong. – cfr Aug 14 '15 at 22:55
  • I don't entirely understand why using \@currname is a problem, though. – cfr Aug 14 '15 at 23:05
  • Be nice if the updated version of atveryend was available, too, but it is not yet on CTAN despite the note dating it to 1st August :(. – cfr Aug 14 '15 at 23:06

This was indeed a bug. Thank you for reporting it! Version 1.2e as of 2015/08/17 (should become available soon at CTAN, has been submitted 2015-08-17 21:24 CEST) uses \next, as suggested in egreg's answer, and also does no longer include the \listfiles. (The example file still includes \listfiles, because it is to be expected that possible problems with the example might be connected to the use of either older or newer versions of other packages.) The requested atveryend has been dated later 2015/08/01, because before that date there was no new version, and the next version (whether 2015/08/18 or 2016/01/01) will surely have this fixed. - I marked this answer "community wiki", upvotes and accepted answer should (in my humble opinion) go to egreg's answer!

  • Thank you very much! And thank you also for the email telling me this. You might consider using something a bit more package-specific than \next, though. My hacked version is currently using \@pageslts@currname just to be on the safe side ;). – cfr Aug 17 '15 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.