When I compile my project with pdflatex, I get to see at which line the error has occurred, but the file is it claims the error has occurred in is incorrect since it always just says that it has occurred in the main .tex file, while it really has occurred in some other file. Double clicking on the error, which normally takes you straight to the problematic code line, is therefore useless. Why does pdflatex behave like this? Does anyone have a suggestion for what I can do to find the line that actually has caused the error, so I can know what pdflatex is complaining about?
[Tex/LaTex] Easy way to find the location of a compilation error
compilingerrors
Related Solutions
[To get this off the unanswered list]
You are using a really obsolete version of WinEdt...
Every version >=6 is able to locate the error in the right file.
It suffices that you set your main document as a "main file" through the command "Set Main File" available in the "Project" menu or in the Tree interface toolbar.
What's the most effective way to find the name of the file in which under- or over- full warnings occur?
Search the .log
file for the string erfull
(either in text editor or command-line tool). This will give you all the overfull and underfull box warnings. The warnings will tell you which lines in the source file the error came from, and the log file will also indicate which PDF page the error occurred on.
As you read through the log file you can see each inputted subfile as it is opened. The warnings that occur after each filename pertain to the line numbers in that file.
I have concocted a example to demonstrate this, which I hope will not be too confusing. The file below is structured like so:
Main file includes
section.tex
section.tex
inputstable1.tex
section.tex
inputssubsection.tex
subsection.tex
inputstable2.tex
Both of the table files create egregious box overflows.
The first erfull
warning in the main .log
file is this:
(./section.tex (./table1.tex)
Overfull \hbox (3524.03448pt too wide in paragraph at lines 12-11
Looking at the generated subfiles section.tex
and table1.tex
, we can see that the overfull tabular
environment in table1.tex
starts on line 12 of table1.tex
. This is the source of the 12
at the beginning of the page range in the warning.
table1
is input into section.tex
, on line 11 of section.tex
. This is the source of the 11
in the warning page range.
So the log message may be translated as follows:
I opened the file
section.tex
. Then I input the filetable1.tex
. When I input the file, I found an overfull\hbox
somewhere between line 12 oftable1.tex
and line 11 ofsection.tex
.
So to answer your question, how to find the name of the file in which the under- or overfull box occurs, it is in the file most recently referenced in the log file before the warning.
Here is the example:
\documentclass{article}
\usepackage[nopar]{lipsum}
\usepackage{filecontents}
%***************************************
\begin{filecontents}{table1.tex}
\begin{tabular}{llll}
a & b & c & \lipsum[1]\\
\end{tabular}
\end{filecontents}
%***************************************
\begin{filecontents}{table2.tex}
\begin{minipage}{1in}
\lipsum[1]
\end{minipage}
\end{filecontents}
%***************************************
\begin{filecontents}{subsection}
\subsection{Minipage}
\input{table2}
\end{filecontents}
%***************************************
\begin{filecontents}{section.tex}
\section{Confusion}
a
b
\input{table1}
d
e
f
\clearpage
\input{subsection}
\end{filecontents}
%***************************************
\begin{document}
\tableofcontents
\include{section}
\end{document}
Best Answer
It sounds like you're using some front-end application to compile. I can think of two possible ways to do some more error seeking:
1) Try only compiling the problem file. This may require temporary alteration of the preamble to make everything else work, but should still work after that.
2) What I would recommend: take it to the command line if you can. Trying running
pdflatex
(or just plain ol'latex
) on the whole project and go through the output to see where it errors out. (This should also be possible with whatever front-end compiler you're using; scrolling through the compilation log is all-telling.)