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

[Mark Yagnatinsky]

I'd like to suggest a potentially dumb idea.  So far, I've seen only one
objection to keeping the console open based on the whatever the
after-typesetting scripts do.  Namely, that they might disagree with each
other, and then what is poor TeXworks to do?  But I say it's obvious what
it should do in that case: if at least one script wants it to stay open,
then it should stay open!  We already have a LogParser; why not use it?

On Fri, Mar 18, 2016 at 2:29 AM, <mskala at ansuz.sooke.bc.ca> wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20160318/3251e450/attachment.html>