[texworks] [XeTeX] Overfull boxes return status of 0 in XeTeX

[Reinhard Kotucha]

On 2016-03-17 at 00:41:45 -0500, mskala at ansuz.sooke.bc.ca wrote:

 > On Wed, 16 Mar 2016, Stefan Löffler wrote:
 > > More importantly, though, several scripts could be run (say, one
 > > that looks only for errors and only that only looks for warnings)
 > > which could give contradicting results (e.g., no errors => close,
 > > warnings => don't
 > 
 > I think you're describing some kind of TeXworks-specific feature
 > for running scripts after the TeX engine, separately from running
 > the TeX engine.  That's different from what I had in mind, which
 > was to *replace* the TeX engine by a script that internally runs
 > TeX and then returns 0 or 1 conditional on whatever checks are
 > desired.  TeXworks would only see this as "TeX returned 1" without
 > knowing there was a script involved.  It only needs to be able to
 > run the script instead of TeX, which can be achieved by making the
 > script executable and telling TeXworks "use this executable file as
 > the TeX engine."
 > 
 > I was trying to address the request for TeX to return 1 on overfull
 > hboxes, as directly as possible.  A script that replaces TeX can
 > give that effect without needing any modifications to TeX nor
 > TeXworks.

Matthew, honestly, I don't think that people didn't understand your
suggestion.  There are just a few problems and there is no real
benefit, IMO.

You suggested to put the wrappers into PATH and call the real programs
with an absolute path.  This doesn't work if your tex file invokes
another program which is supposed to be in PATH.  Nowadays EPS files
are converted to PDF on-the-fly, if necessary.  But it can only work
if the directory containing the TeX Live binaries is in PATH so that
epstopdf can be found.

Your suggestion implies that there are two programs with the same
name name in different directories.  This is nasty and certainly
causes more problems than it solves.  And please consider that there
are zillions of TeX engines/formats nowadays and you need wrappers for
all of them.

Phil suggested to make the exit status of TeX engines configurable in
order to save time.  But if your wrapper scans the log file in order
to determine the proper exit status, you don't save any time at all.

The best solution is to run a script which inspects the log file after
each TeX run.  Emacs/AUCTeX is doing this for more than two decades.
Programming languages like Perl or Lua are probably even faster than
Emacs Lisp.  Not to mention that computers are much faster than 20
years ago.

Phil assumed that scanning the log file is time consuming and thus
suggested configurable exit values.  But as Zdeněk already pointed
out, scanning the log file is not time consuming at all.

Regards,
  Reinhard

-- 
------------------------------------------------------------------
Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:reinhard.kotucha at web.de
------------------------------------------------------------------