# When error lines are divided into three parts?

Usually TeX divides error lines to two parts. But sometimes three. When and why this happens? Consider the following example. If final \hfil is removed, only two lines are displayed at the top, but with \hfil three.

\headline={\ifnum\pageno=1 \hfil Title\hfil\elsePage\dotfill\the\pageno\hfil\fi}
hello world
\bye

• also search "actually three" here tex.stackexchange.com/questions/491891/… – Igor Liferenko Jan 28 at 3:33
• Posted an answer :-) Short version is that it would be good to get the default texmf.cnf in TL tweaked slightly IMO (ensure error_line < max_print_line). – ShreevatsaR Jan 28 at 8:23
• Check the license of rsTeX; according to the author it's "all rights reserved" and for educational use only (it's definitely educational; I'm glad to be able to study it). I don't have much insight into how kpathsea works or the different versions, but another option (if it's just for personal use) may be to simply spawn a kpsewhich process and read its output :-) – ShreevatsaR Jan 29 at 2:41
• On differences in DVI output, see this question. A difference in \showoutput would be more serious. – ShreevatsaR Jan 29 at 5:20

This is the result of interaction between two configuration options that TeX has (among many others):

• error_line, the "width of context lines on terminal error messages", i.e. the maximum number of characters in an error message "line".

• max_print_line, the "width of longest text lines output", i.e. the length at which line-wrapping (by inserting hard newlines) happens.

Normally, TeX prints an error message in two "lines":

• The first line contains up to half_error_line characters, say k characters happen to be printed.

• The second "line" then contains k spaces, followed by up to error_line - k characters, so that its total length is bounded by error_line.

Now, a weird thing happens when error_linemax_print_line: while the (up to) error_line characters are being printed (on the second line), we can hit max_print_line, and then TeX will wrap the line by inserting a newline character!

This can be somewhat confusing (see the example error output below), so IMO it's best to set error_line < max_print_line.

The original tex.web, as written, sets error_line = 72 and max_print_line = 79, and leaves it up to the local installation to change those values. Any TeX implementation that uses these exact values will not have this problem.

In TeX Live, where these can be configured at runtime (in texmf.cnf or via environment variables), these values are both set to 79 in the default texmf.cnf, leading to a blank line when exactly 79 characters happen to be printed in the second error "line". It would be worse if max_print_line were to be set less than error_line, as we can then get ugly output like (your file with max_print_line=73 error_line=79 tex):

! Undefined control sequence.
<inserted text> ... =1 \hfil Title\hfil \elsePage
\dotfill \the \pageno \
hfi...
}\vss }\nointerlineskip

van...


-- here in the first pair of error lines (spread over three physical lines) \hfil has been split, in the second pair of error lines there's a confusing blank line, and in the third pair \ad on one line and van... on the next looks mysterious.

IMO in an ideal world:

• TeX would check that error_line < max_print_line, or at least document it as an expectation. I have no idea why this is not enforced.

• TeX Live would change its defaults to something like 78 and 79, instead of 79 for both.

Personally, one of the first things I do with a TeX installation is to set

half_error_line=238
error_line=254
max_print_line=1000000


in my texmf.cnf, so that there's no line wrapping and error lines are as long as possible.

Edit: By setting max_print_line much smaller than error_line, we can even have (what are supposed to be) pairs of error lines occupying nine physical lines:

% Quotes from DEK
\def\email{Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn\theory certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don't have time for such study.}
\def\theory{If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning\lp some attention to theoretical things; it will improve your practice.}
\def\lp{Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a comput\err to do. The practitioner....}

\email

\bye


Run with

max_print_line=60 half_error_line=238 error_line=254 tex err.tex


to get:

This is TeX, Version 3.14159265 (TeX Live 2019/Debian) (preloaded format=tex)
(./err.tex
! Undefined control sequence.
\lp ->Let us change our traditional attitude to the construc
to instruct a computer what to do, let us concentrate rathe
r on explaining to human beings what we want a comput\err

to
do. The pr...
\theory ...you find that you're spending almost all your tim
e on theory, start turning some attention to practical thing
s; it will improve your theories. If you find that you're sp
ending almost all your time on practice, start turning\lp

so
me attentio...
\email ... wonderful thing for people whose role in life is
to be on top of things. But not for me; my role is to be on
the bottom of things. What I do takes long hours of studying
and uninterruptible concentration. I try to learn\theory

ce
rtain areas...
l.5 \email

? x
No pages of output.

• Interestingly, half_error_line is checked against error_line in @<Check the constant'' values for consistency@>=. – Igor Liferenko Jan 28 at 8:27
• Maybe this should be reported to DEK for consideration? – Igor Liferenko Jan 28 at 8:37
• @IgorLiferenko It could be reported, but this seems like such a basic thing and I imagine should have been used by so many people that this is probably either well-known and/or impossible to change. But yeah doesn't hurt to report, might be good to "get a ruling" / some words anyway. :-) – ShreevatsaR Jan 28 at 13:44
• About "where is this documented": the TL guide and the web2c manual (tug.org/texinfohtml/web2c.html#Runtime-options) both mention that parameters can be overridden in texmf.cnf. (The text is essentially the same in both.) I did not mention max_print_line etc. specifically, just a couple of the memory parameters that, in the past, people might actually have wanted to adjust. I didn't and don't want to list every single parameter, since there are 40+ and it would be painful. Anyone who is interested enough can read texmf.cnf, as the text points out. – Karl Berry Jan 28 at 23:26
• @KarlBerry Ah cool, thanks. I had a vague (evidently incorrect) memory of having read it in documentation somewhere at some point, and was struggling quite a bit to find that page again, and wondering if it went offline (along with the old site at tex.loria.fr say) or I was just poor at searching. :-) Now I guess that maybe what I had read was the texmf.cnf file itself. Thanks for clarifying, that makes sense. – ShreevatsaR Jan 29 at 0:06