TexShop will not compile without trashing aux files after every error

I have a couple of LaTeX files with the same problem. If I produce an error, fix it, and then try to compile a pdf, I get the following error.

)Runaway argument?
{{
! File ended while scanning use of \@newl@ablel.
<inserted text>
\par
l.90 \begin{document}


If I then click on the console or trash my .aux file, it compiles fine. Any thoughts on what is going on and how to prevent this annoying extra step?

• I hope you mean compile a TeX file. :) Aug 7, 2013 at 19:52
• Welcome to TeX.SX! Unfortunately, some bad errors cause corruption in the .aux file. Sometimes just passing over the error, instead of interrupting the LaTeX run, can cure it by writing a correct file at the end of the run. Aug 7, 2013 at 19:53
• But once the error is fixed and the corrupt .aux file is deleted, that file compiles fine? Obviously, not every error should produce so terrible an error. Also: is 'the same problem' due to the same bad command..?
– jon
Aug 7, 2013 at 22:14
• This is the weird thing. Once a file decides it wants to do this, it doesn't matter what type of error, the same problem happens. However, lots of my files recompile just fine after clicking apply. From the responses I have gotten, it sounds like I just need to deal with it. Aug 8, 2013 at 0:21
• never saw \@newl@ablel but only \@newl@bel ...
– user4686
Jan 23, 2016 at 21:49

This is the nature of the beast...

TeX employs an (external) auxiliary .aux file to store information at/of every run. This file is used extensively when dealing with labels and references (see Understanding how references and labels work) since the output routine only flushes pages after having collected enough content to fill it (and perhaps more). As is evident from your error snippet, it deals with an offending \label usage.

Here's the sequence that causes the error:

2. \label-information is stored in .aux. This information will be read during a subsequent compilation. If problematic code is written to the .aux, you will only pick it up in this subsequent run. However, this run itself may compile without problem.
3. You compile your document again in order to make sure the references settle. However, now the problematic code is read in, causing the error.

Note that, even during the second compile (item 3 above) you are still writing problematic code to the .aux. So, even if you fix it and recompile, the problem will still show in the subsequent compile.

Some problems are recoverable, but others are fatal, depending on when you are writing the information to the .aux. In a worst-case scenario - when the problem persists even though you've fixed your code - delete the offending .aux and recompile (at least twice).

How do you avoid this annoying extra step? Don't make mistakes... :) Well, at least not when dealing with content written to the .aux file.