With the simple equation environment;

\documentclass{article}
\usepackage{amsmath}
\begin{document}
$$a \foo b$$
\end{document}


you can see a helpful error message, which editors like Kile understands;

! Undefined control sequence.
l.5  a \foo
b


Making it report 5: Undefined control sequence a \foo

But if you do the same in an amsmath environment, such as the popular align

\documentclass{article}
\usepackage{amsmath}
\begin{document}
\begin{align}
a \foo b
\end{align}
\end{document}


you get the unhelpful error (and it comes up twice);

! Undefined control sequence.
<argument>  a \foo
b
l.6 \end{align}


which makes Kile report; 6: Undefined control sequence \end{align}.

Checking the log is tedious and ultimately unrewarding, because not even in there can I find the actual line which contained the undefined control sequence. Can this awful behavior be helped in any way?

-
eqnarray turns out like equation, but there are of plenty or other reasons to not use that. –  Mikael Öhman Nov 30 '12 at 18:21
how errors are reported isn't strictly limited to amsmath, but is an underlying design feature of tex. kile isn't parsing the log in the most useful way. –  barbara beeton Nov 30 '12 at 18:44
@barbarabeeton In defense of Kile, the TeX log is not written in the most useful way, either. As @MikaelÖhman rightly observes, the line number of the offending \foo is not written out. Now imagine to write a parser that takes all this into account, and is working with all kinds of user defined macros and environments... –  mafp Dec 11 '12 at 22:07
@mafp -- i'm not meaning to knock kile; learning to deal with the tex log is a brain-numbing exercise at the best of times. but it's what knuth has given us, so unless tex itself is rewritten to provide more scrutable information, it's what we have to live with. maybe i can find someone to write a guide for tugboat on how to decipher the log more effectively; there isn't anything like that now that i can discover from a quick scan of the cumulative contents. it would be useful. –  barbara beeton Dec 11 '12 at 22:45

Simple answer: no. The align environment works very differently from equation: all of the material has to be read before any typesetting. (In that sense, it's similar to the beamer class frame environment, which people also ask similar questions about.) The material to be aligned has to be read before it is typeset to allow measurement, so it's not an option to simply 'drop' this.

-
The fact that Kile chooses to claim that end{align is undefined rather than \foo is I guess down to how it parses the .log file. I doubt much can be done there without re-writing the parser. –  Joseph Wright Nov 30 '12 at 16:54

The undefined command is, in both cases, the the last token on the line after the error message, which is the documented behaviour here.

Thus the issue is not with TeX or the amsmath package but with the parsing of the log file by Kile which appears to be in error given your description. Perhaps you should raise a bug report with the editor.

Note that the line number has to be that of \end{align} rather than the line that contains the undefined command as the latter is not available. You see the same behaviour if you go

  \def\mycommand{..... \foo .....}


There is no error at that point but if \mycommand is used then you will get an undefined command \foo error message, showing the line number where \mycommand was used not where \foo is used in its definition.

-
The reason the \end{align} line is where \foo is used (rather than the obvious alternative of where it is written in the file) is that align first gathers, then re-typesets its argument, with the actual material presumably being finally placed "on paper" in the course of \end{align}, and not where it first appears in your TeX file. –  Ryan Reich Nov 30 '12 at 17:06
@david I regret mentioning Kile as an example. As I mentioned, even looking at the log, without the expected line number its mostly pointless. I'm not suggesting its not following specifications or that it's inconsistent. I'm just saying that it's not at all helpful to me. –  Mikael Öhman Nov 30 '12 at 18:05
The line number just is not there even internally. Even the file might not be there. When a macro is defined in TeX white space is normalised and there is no record of where the original definition was made. If the definition is dumped in a format the file may be gone altogether. Only when the macro is used will any undefined commands or other errors be found. –  David Carlisle Nov 30 '12 at 18:34
@David: You're right but the connection with the present question is a little obscure. It's true that in \def\mycommand{\foo}...\mycommand, the error is reported on the latter line, not the one with \def. This does not apparently concern \begin{align}\foo\end{align} because there is no \def evident (\foo is right there in the file) but functionally, it becomes the situation because align collects its contents without expanding them, much as \def. The expansion then occurs in \end{align}. To appearances, though, it's not obvious why this phenomenon is the one that occurs. –  Ryan Reich Nov 30 '12 at 19:06