[lltx] quietening lualatex console output

[Reinhard Kotucha]

On 29 January 2011 Philipp Stephani wrote:

 > I think LuaTeX should aim for more sane output in general, similar
 > to other non-TeX compilers. That means:
 > - No printing of page numbers (already possible), file names
 >   (suggested in http://tracker.luatex.org/view.php?id=535) and
 >   similar nonsense. People who are interested in which files are
 >   loaded can use the filename recorder.
 > - All messages use file:line:message style, even those that come
 >   from \write or Lua print() or texio.write()
 > - \scrollmode (i.e. no user interaction) by default
 > - Primitives or Lua functions for printing errors, warnings and
 >   informational messages
 > - Getting rid of \errhelp
 > - Messages are never broken across lines; every message is exactly
 >   one line; newline chars in messages are converted to spaces
 > - No continuation of messages
 > - No log file
 > - Error messages go to stderr
 > - No banner

Sorry, I disagree, especially if you say:

 > I don't think this has to be configurable. 

The log files are definitely needed.  There is no other way to debug
things and the .fls files are not sufficient at all.  The log files
contain a lot of useful information.  Did you ever noticed that they
contain much more information than screen output?  Without log files
there is absolutely no way to solve other people's problems.

 > The current mess probably needs to stay for compatibility reasons,
 > but a command line option --sane-output could be added that
 > switches output to the sensible style GCC and most other compiler
 > use.

There is such an option already, called --interaction.  And come on,
the error messages provided by other compilers/interpreters are not
better than those provided by [La]TeX, often even worse.

Now, let me comment your suggestions in detail:

 > - No printing of page numbers (already possible), file names
 >   (suggested in http://tracker.luatex.org/view.php?id=535) and
 >   similar nonsense. 

I don't see any benefit if page numbers are suppressed, but this can
be done at macro level.  Just switch to \batchmode temporarily when a
page is shipped out.  Requires to patch the output routine, not much
fun in LaTeX, admittedly.

 >   People who are interested in which files are loaded can use the
 >   filename recorder.

No.  It just traces open() system calls.  But some files are loading
others, and it's often necessary to find out WHY a particular file is
loaded at all.  This information is not present in .fls files.

 > - All messages use file:line:message style, even those that come
 >   from \write or Lua print() or texio.write()

There is a command line option already.  If it doesn't support files
opened by \openin and \openout, I agree with you that such an
enhancement is welcome. 

Regarding Lua, I think that "file:line:" style messages are only
useful for error messages, not for print() or texio.write() in
general. 

 > - \scrollmode (i.e. no user interaction) by default

I don't know why you are so much interested in changing default
values.  There are many programs (TeX IDEs) which expect a particular
behavior.  I don't see any good reason to break them for no good
reason. 

 > - Primitives or Lua functions for printing errors, warnings and
 >   informational messages

Better Lua functions than TeX primitives.  However, it would be nice
if Lua can determine name of the current TeX input file (which
contains the Lua code) and the line number.

 > - Getting rid of \errhelp

WHY????  It's just a token register which can be accessed from the
command line.  There is absolutely no reason to get rid of it.
If you aren't interested, just don't ask for help.

BTW, the LaTeX help messages are quite laconic because when LaTeX2e
was released, RAM wasn't as cheap as today.  But AFAIR the LaTeX team
considered to read more detailed help messages from an external file
in a future release.  If messages are read from an external file, it's
quite easy to provide them in different languages too.

 > - Messages are never broken across lines; every message is exactly
 >   one line; newline chars in messages are converted to spaces

This is supported by TeX Live already, though admittedly not well
documented.  The length of lines in the log file and on terminals can
be changed in texmf.cnf or in the environment.  The variable
max_print_line takes a number as an argument.  The default is 79.

Try this on the command line:

  max_print_line=10000 pdftex story \\bye

 > - No continuation of messages

What does it mean?

 > - No log file

They are definitely needed.  I could imagine an option to turn them
off.  But such an option shouldn't be documented. :)

 > - Error messages go to stderr

Yes, we are living in the 21st century.  Even Windows supports stderr
for some time past.  Maybe it breaks some TeX IDEs which capture
screen output, but I suppose that most of them read the log file
anyway.  The only TeX primitive involved is \errmessage, AFAIK.
Shouldn't be difficult to implement.  Maybe a compatibility switch is
needed.

 > - No banner

--interaction=batchmode

Of course, I'm aware that we are living in a world where most people
refuse to read documentation, error messages, log files, or whatever
tells them what they've done wrong.  Instead, they complain "My
document doesn't compile anymore", "I got an error", "I'm using WinEDT
and it complains about an 'Undefined control sequence..'", or "How can
I get rid of the file 'missfonts.log'?", without providing any useful
information.  Looking into a log file or reading an error message
themselves is obviously far beyond their capabilities.

But the only way to help those poor souls is to ask them to send us
their log files.  Do you really propose to abolish them?

What you suggest isn't worth to break compatibility.  And many of your
suggestions are already supported, though not enabled by default.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------