# why is this error message line number wrong?

I have this very short TeX file

\documentclass[12pt]{report}
\usepackage[a4paper,widh=100mm,top=50mm]{geometry}
\begin{document}
test
\end{document}


in which I have made an mistake writing widh instead of width. Now when I compile via pdflatex I would expect something like

! Error message: blablabala
l.2 \usepackage[a4paper,widh=100mm,top=50mm]{geometry}


which would help me spot the line in which the error originated in my source file (that would be the second line).

! Package keyval Error: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

l.994 \ProcessOptionsKV[p]{Gm}


Why so? Furthermore how is it supposed to be helpful to , not only not show the line in which the error occurred, but even to show a different line in a different file, which?

My take on it is that l.994 \ProcessOptionsKV[p]{Gm} is some codepart that was called with my data from line 2 and the error only occured then and that it fine, but why then would the message not in addition state the file and a backtrack / trace to the actual line?

# update to clarify the issue

I made some more testing and adapted the tex source to this

\documentclass[12pt]{report}
\usepackage[a4paper,widh=100mm,top=50mm]{geometry}
\errmessage{line three intentionally throws an error}
\begin{document}
\end{document}


which on purpose throws an error in the third line and the output shows then

/usr/share/texmf-dist/tex/latex/geometry/geometry.sty:994: Package keyval Error
: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

l.994 \ProcessOptionsKV[p]{Gm}
%
)
./testerrorlinemadness.tex:3: line three intentionally throws an error.
l.3 ...e{line three intentionally throws an error}


clearly making the point that when raising the first error my source text file had not yet evaluated the third line and hence has imho no real excuse to **not to feature the current line number at occurrence of error*.

# Update, how would other languages handle error messages?

Since the comments and answers had a tendency to argue that it is completely natural and acceptable that the example feature would not report the more correct line number (the line where the error was provoked in the original tex file) I would like to show that other languages can indeed give a trace back to the point where the error occured.

To do so lets have a look at a short example how javascript would have handled a comparable error reporting task

// EXAMPLE how error message and propagation work in many another
// language (example javascript)
//
// description: what would be MACROS in latex such as /usepackage
// would be named FUNCTIONS in javascript.
// To keep with the example in latex and allow comparison
// we make up a two functions 1: "usepackage" and 2: "geometry"

function usepackage(parameter)
{
geometry(parameter);
}

function geometry(parameter)
{
ProcessOptionsKV=parameter.width.length;
}

// When now calling the usepackage correctly no error occurs
usepackage( {width:"12mm"} )

// But when providing wrong input, there is an error message
usepackage( {widh:"12mm"} )

// this is the error message
/*
Exception: TypeError: parameter.width is undefined
*/
// reading the message shows backtracingly line by line
// how the error came about. after the Error message it shows that
// the error occured in
// 1. function "geometry" in file "Scratchpad/1" line 16,
// which was called from
// 2. function "usepackage" in file "Scratchpad/1" line 11
// which was provided with the wrong input from
// 3. the file "Scratchpad/1" line 24
//

• Well, it does say "widh undefined" and widh happens once in your document... – heather Aug 12 '16 at 20:09
• You could run pdftex with the -file-line-error option (see, e.g., man pdftex). Edit: Also note that latex.ltx sets \errorcontextlines=-1; you could also reset that parameter. – GuM Aug 12 '16 at 20:13
• @heather smart ! But consider that this was purposively an short and simple example in which tracing of a word is easy. misspelling it to with in combination with some english text would not allow to spot that easily. My easy example is no real excuse or explanation why the error is not reported as I suggest, is it? – humanityANDpeace Aug 12 '16 at 20:47
• When it issues an error, TeX typically has many input sources pending, more or less equivalent to a stack of pending procedure calls. The \errorcontextlines parameter tells how many of these pending levels should be displayed to the user when an error occurs. The LaTeX format, of which latex.ltx is the source code, sets this number to -1 (no intermediate level is displayed), because its authors felt the user would have been shocked by the sight of LaTeX’s internal macros… (;-) – GuM Aug 12 '16 at 21:04
• @GustavoMezzetti at the point of the error tex does internally have a stack of open files and a file pointer to each of them so the OP is arguably correct that in some hypothetical system this stack could be exposed rather than just the line number of the most recently opened file, but it doesn't so that's that:-) – David Carlisle Aug 12 '16 at 21:18

If you want a more informative error message you can increase \errorcontextlines

\errorcontextlines=200
\documentclass[12pt]{report}
\usepackage[a4paper,widh=100mm,top=50mm]{geometry}
\begin{document}
test
\end{document}


produces

! Package keyval Error: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

\GenericError  ...
\endgroup
\KV@split ...x \KV@errx {\@tempa \space undefined}
\else \ifx \@empty #3\@emp...

\KV@do ...ax #1\@empty \else \KV@split #1==\relax
\expandafter \KV@do \fi
<argument> a4paper,widh=100mm,
top=50mm
\setkeys ... {KV@#1@}\let \@tempc \relax \KV@do #2
,\relax ,
\@ProcessOptionsKV ...keys {#2}{\@tempa }}\@tempa
\AtEndOfPackage {\let \@un...
l.994 \ProcessOptionsKV[p]{Gm}
%
?


This shows the macro expansion levels that lead to the error, by default LaTeX turns this off as it just exposes the implementation of the various commands that is not that interesting to most uses.

TeX has no record of where a particular macro was defined, only the definition that it has at the point of the error so it has no way of saying that the argument currently being processed by \ProcessOptionsKV was originally input from the line

\usepackage[a4paper,widh=100mm,top=50mm]{geometry}

• TeX would not need any record. A common pattern with other languages is a backtrace. Say /macro1 -> calls /macro2, in which an error occurs, then not only would /macro2 cause an error message to be printed out, it would also hand back to /macro1 the information about the error occuring, which before continuing the execution would be able to add the information of the file and line number from which the failing /macro2 was called. – humanityANDpeace Aug 12 '16 at 22:27
• the stack of macro execution is shown by \errorcontextlines but you want the stack of open file positions and as I comment above that is in the internals but not exposed. That would coincidentally give you the point where widh was entered, as \usepackage does \input. but \def\foo{ something \undefined} then 100 lines later use \foo you will get an error that \undefined is not defined, but tex has no record, even internally of where \foo was defined so it has no way of recording the line number or file where \undefined was entered. your widh example is not very different. – David Carlisle Aug 12 '16 at 22:33
• @humanityANDpeace also note that it's a macro expansion language there are no function calls and no real stack, macros are expanded inline pushing their expansions into the input stream, control does not pop back up a stack at the end of the definition as it does in a compiled function call. – David Carlisle Aug 12 '16 at 22:38
• very true. but that would not limit that the parsing of the source could not keep track of line numbers and execution sequence. Indeed as shown in the first update, after the error pdflatex continued in line 3 and could have therefore provided the information. I will have to look if there is a change to tweak (imho) improve pdflatex source. sorry for the lengthy comment. yet insightful for those with the problem of tracing error. – humanityANDpeace Aug 12 '16 at 22:47

Well, package geometry calls package keyval to validate the given options. The error message shows the line from the package that showed the error, package keyval. That is okay.

But you get the message that the invalid option widh was found.

Now you can search your code for the wrong spelled option.

If you have a greater look to the error message you will find:

("C:\Program Files\MiKTeX 2.9\tex\latex\geometry\geometry.cfg")

! Package keyval Error: widh undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
...

l.994 \ProcessOptionsKV[p]{Gm}
%
Try typing  <return>  to proceed.
If that doesn't work, type  X <return>  to quit.


Now you can see that package geometry causes the error message (first line in error message above).