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

[mskala at ansuz.sooke.bc.ca]

On Fri, 18 Mar 2016, Reinhard Kotucha wrote:
>  > hboxes, as directly as possible.  A script that replaces TeX can

> 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

Maybe someone else suggested that; several people here have advocated
wrapper scripts and I wasn't the first to do so.  I don't think I
mentioned the PATH variable myself before now at all.

I was actually thinking of leaving XeTeX where it is, under its original
name, giving the wrapper script some completely different name, and then
telling TeXworks to use the new name - which I expect should be possible
because TeXworks already is capable of running multiple backends.  If
TeXworks hard-codes the list of possible names of the TeX engine, then
yes, it might be necessary to name the script something TeXworks can
call... but possibilities for leaving it in place could include giving the
script the name of some other TeX engine TeXworks can invoke (ugly, but
it'd work) or putting the script in a PATH directory searched before the
one that contains real XeTeX, so that it can replace real XeTeX without
touching any other executables.

There's an issue here of which I've been trying to politely not make a big
deal, but:

We have only one user demanding this.  If we even care at all, then we
don't need a solution for everybody.  Just him.

That means questions of portability to all operating systems, or of
compatibility with software and features he doesn't use, are not really
significant.  It also means the question "Who should write new code?" is
not the false dilemma Philip Taylor has repeatedly claimed, with the
answer necessarily being either "all TeX engine maintainers!" or "all
front end maintainers!"

It isn't *all* of any open-ended group.

It's *one* person who wants his system to operate differently, who could
have that by writing a script himself, and who has succeeded in winding us
up to treat his very personal use case as if it needed to be universal.

TeXworks; XeTeX (and specifically not XeLaTeX); whatever operating system
Philip Taylor uses.  Not all front ends; not all TeX engines; not any
LaTeX-specific feature; not all operating systems; only one user.  This is
not a general issue and it does not need a universally portable solution.

> 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.

Is that a TeX feature or a LaTeX feature?  Mr. Taylor famously doesn't use
LaTeX, so if it's a LaTeX feature, breaking it doesn't matter - but it'd
only be broken if epstopdf were taken out of PATH anyway, which I did not
recommend.  (Does whatever searches for epstopdf even use PATH anyway?
I'd've expected it to use kpsewhich, independently of PATH.  But this
isn't relevant!)

Even if it were necessary to take the real XeTeX out of PATH - which is
not the case - why would that have anything to do with changing the name
or location of epstopdf?

> Your suggestion implies that there are two programs with the same
> name name in different directories.  This is nasty and certainly

No, I intended that the script should not be named "xetex" and that real
XeTeX should remain where it is.  If TeXworks hardcoded the name so that
the script were forced to be named "xetex", then yes, things would become
more complicated, but I don't think that is actually the case, and even if
it were, it would not be a dealbreaker.

> 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.

Only the engine that one user uses, and it only has to work on his system.

> 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.

I think most of us agree that saving computation time is not a real
consideration here.  You say so yourself, below.

> The best solution is to run a script which inspects the log file after
> each TeX run.

Yes, that's what I said.

Apparently TeXworks's built-in feature for running postprocessing scripts
isn't suitable for this purpose because the scripts run by that feature
aren't able to tell TeXworks that TeX has "failed" in the way that causes
it to open a log window, which was was what the user wanted.  But a
wrapper script could do it by returning a nonzero exit code, so I think a
wrapper script is the best solution.

> 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.

Indeed.

> 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.

I agree.

-- 
Matthew Skala
mskala at ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/