Correct line numbers for errors/warnings

[GoogleCodeExporter]

I often see an error such as:

LaTeX Warning: Reference `fig:assign-by-x' on page 76 undefined on input line 2

That line should be 232, its cut off because of the 80 character limit, and
placed on the next line. It would be great if we could get the right line
number.

This is tricky because I can't figure out how to get latex to use more than
80 chars. See
http://stackoverflow.com/questions/1289680/latex-command-line-line-length/128986
6
for a not hugely useful discussion.

I guess you'll have to parse across the newline boundary in the case of an
80 character line ending in numbers where the next line starts with numbers?

Original issue reported on code.google.com by paul.biggar on 17 Aug 2009 at 8:23

• Merged into: #54

[GoogleCodeExporter]

OK, I've found the solution, and its trivial. Its explained in the link above. 
This
patch should do it, though I didn't know the best place to put this, or the 
number to
use.

Index: Makefile
===================================================================
--- Makefile    (revision 1934)
+++ Makefile    (working copy)
@@ -1335,7 +1335,7 @@
 # LaTeX invocations
 #
 # $(call latex,<tex file>,[<extra LaTeX args>])
-run-latex  = $(LATEX) --interaction=batchmode $(if $2,$2,) $1 > /dev/null
+run-latex  = max_print_line=120 $(LATEX) --interaction=batchmode $(if $2,$2,) 
$1 >
/dev/null

 # $(call latex-color-log,<LaTeX stem>)
 latex-color-log    = $(color_tex) $1.log

Original comment by paul.biggar on 18 Aug 2009 at 2:00

[GoogleCodeExporter]

This may seem strange, but I'm actually more in favor of parsing over newlines 
than 
changing mysterious environment variables, especially in light of the comment 
in this 
file:

http://www.nd.edu/~hpcc/solaris8_usr_local/src/teTeX00/texmf.cnf

Apparently it is "inadvisable" to change these parameters.  :-)
There are several places in the code that span newlines in their parsing logic, 
since 
finding graphic filenames often involves doing just that, so I think we can 
manage 
this, too.  I'll take a look at it (though maybe not terribly soon)

Original comment by shiblon on 18 Aug 2009 at 3:23

• Changed state: Accepted

[GoogleCodeExporter]

That does make sense. Presumably, there is some limit anyway, which would 
eventually
be hit, and then you would need to new parsing logic anyway.

I'll stick with this change locally, until this is fixed.

Thanks.

Original comment by paul.biggar on 18 Aug 2009 at 3:58

[GoogleCodeExporter]

I note that vim's errorformat breaks with my change. This further demonstrates 
that
parsing is the right way to go.

Original comment by paul.biggar on 18 Aug 2009 at 5:32

[GoogleCodeExporter]

Okay, I have a fix for this.  Please let me know what you think of it in r55.

It turned out to be a really cool sed hack, and it makes all of the rest of the 
error 
processing more robust to multiple line splits.  Thankfully, LaTeX log output 
separates each "thought" with a blank line, so it was easy to split the log 
into 
paragraphs using SED, and then handle each one differently when we hit a blank 
line.

The lines are output as-is in the log file, so errorformat in vim should now 
work, at 
least for basic latex errors and warnings.

Please let me know if r55 works for you, and if it does, I'll upload an 
official tarball.

Original comment by shiblon on 28 Aug 2009 at 3:21

• Changed state: Fixed

[GoogleCodeExporter]

This doesn't work for me. I don't understand the cool sed hack, so I haven't 
really
been able to debug it. I suspect that is the problem with "cool sed hacks" ;)

I'm not sure what the intention was though. Are you trying to store the complete
error paragraph? Hmmm, maybe that is the intention, but it changes behaviour 
quite a
bit. This might be the nicer behaviour, I'd have to think about it, but I'm not 
certain.

I attach 2 files: old_log is with version 2.1.27, new_log is revision r55.

Sed is GNU sed version 4.1.5
Latex is pdfTeX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6)

Basically, I just use plain Ubuntu 9.04 defaults.

Original comment by paul.biggar on 28 Aug 2009 at 11:02

Attachments:

• new_log
• old_log

[GoogleCodeExporter]

Yes, the intent was to operate on each paragraph as a whole, and colorize the 
whole 
thing.  That works fine on my machine, which is using an ancient version of sed 
(it's a 
mac), so I assumed it would work for you.

The logs you gave me are interesting.  Do you, by chance, have the actual log 
file 
sitting around that these sprang from?  In order to debug this properly, I need 
the 
source.log file and the new output (assuming your filename is "source.tex").

Original comment by shiblon on 29 Aug 2009 at 3:17

• Changed state: Started

[GoogleCodeExporter]

The warning/error output fix is now fixed per issue 54, so I'm marking this a 
duplicate.

Original comment by shiblon on 19 Nov 2009 at 7:01

• Changed state: Duplicate