The LaTeX kernel provides the 'scratch' macros \@tempa, etc., and \reserved@a, etc. These are used for a variety of purposes. Which should be used as temporary space by general users/programmers?

  • I have to admit I have been using the plain TeX conventions here, using \0, \1, etc. But I never dared let any code that I don't have complete control over run between defining and using these macros. Havn't been burned by it yet. – Harald Hanche-Olsen Aug 24 '18 at 21:07
  • I happened to stumble across this similar question: tex.stackexchange.com/questions/88252/… – David Purton Aug 25 '18 at 15:49

The \reserved@... macros are reserved for use by the LaTeX team only: they should not be used by others. On the other hand, the macros \@temp... are available for general scratch use.

This is because low-level parts of the kernel need to have reliable storage for internal use. The \reserved@... series provide this, and using them may cause unexpected issues in apparently unrelated code. No such reliance takes place with the \@temp... series.

If you are patching a kernel macro and using the reserved names exactly as the kernel does, you might of course need to use one. This is however an extremely limited set of circumstances.

| improve this answer | |

LaTeX2.09 used \@tempa, ... as scratch macros, but by the time LaTeX2e was being designed so many style files (packages) were using the same "scratch" macros they were not really "safe" any more so we used \reserved@a,... in the format code, documented as not to be used by other packages. So \@tempa and friends have no special status now, although they are commonly used because many common packages have a history that goes back to latex2.09 (ie before 1994).

But really for any package being written now there is no need to use these generic scratch macros at all. If your package is called wibble.sty use \wibble@a, \wibble@b,... etc.

In 1994, on a 640K PC running emtex there were only about 50 command names left after loading latex2e+amsmath, and so it made sense for as much code as possible to re-use the same command names. With a modern texlive or miktex installation there are typically several hundred thousand command names available in the string pool and obfuscating the code and running the risk of clashes with other packages by re-using some generic command names is probably taking a risk with no actual potential gain.

| improve this answer | |
  • The 'throw away' temporaries are handy for ad hoc code, mainly: that was the context in which the initial query arose. – Joseph Wright Aug 24 '18 at 20:22
  • 5
    @JosephWright yes but one person's ad hoc code ends up being someone else's go-to package 20 years later:-) – David Carlisle Aug 24 '18 at 20:24
  • I just got bitten by \@tempdima being used both by \rule and by \l@section: I was hacking into \l@section and trying to use the \@tempdima configured by it in the parameters of an extra \rule, but to no avail of course as \rule itselfs resets \@tempdima. – user4686 Aug 25 '18 at 9:59

When writing code from scratch that might be used by people other than me, then I tend to write everything within an own namespace where each macro-name has its own prefix formed by the name of the project/package, trailed by an @ and an acronym denoting the person who wrote that code. E.g., for project foobar I don't use \@tempa but I use \foobar@UD@tempa. If I could easily use digits within names of control sequences, I would in many places include version number / date of submission into the namespace-prefix also.
Exception: Macro-names for macros for the user-level.

Besides this I tend to redefine whatsoever "scratch" macros not introduced by me within local scopes only, where at the moment of finishing producing whatsoever boxes, these local scopes are already closed again so that my temporary redefinitions don't interfere during moments where the output-routine is in action. (One can have fun in situations where \globaldefs might have a positive value. ;-) )

Another issue are macros where hooks like \everypar or \everyeof get modified. Modifying somebody else's macros, e.g., scratch-macros from the kernel, might probably affect the way in which things triggered by those hooks are done. This in turn might cause problems.

E.g., recently there was a thread macros - inaccurate hyperlink to customly defined theorems where changing the kernel's box-register \@labels happened even without the user being aware of that:

The labels of the text of a theorem-like environment were to be nested into another itemize-like environment. First the material for typesetting both the theorem-like environment's label and for placing an anchor for hyperlinks was placed into the box-register \@labels. Theorem-like environments rely on \everypar for typesetting the content of that box-register. But the content of that box-register was replaced due to the itemize-like-environment before the \everypar-hook was carried out. This time with material where no anchor for hyperlinks was placed. Thus hyperref-functionality was broken.

So, problems with changing things belonging to the kernel can even happen without users knowing/intending that.

| improve this answer | |

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.