<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 2:29 AM,  <span dir="ltr"><<a href="mailto:mskala@ansuz.sooke.bc.ca" target="_blank">mskala@ansuz.sooke.bc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, 18 Mar 2016, Reinhard Kotucha wrote:<br>
>  > hboxes, as directly as possible.  A script that replaces TeX can<br>
<br>
</span><span>> Matthew, honestly, I don't think that people didn't understand your<br>
> suggestion.  There are just a few problems and there is no real<br>
> benefit, IMO.<br>
><br>
> You suggested to put the wrappers into PATH and call the real programs<br>
<br>
</span>Maybe someone else suggested that; several people here have advocated<br>
wrapper scripts and I wasn't the first to do so.  I don't think I<br>
mentioned the PATH variable myself before now at all.<br>
<br>
I was actually thinking of leaving XeTeX where it is, under its original<br>
name, giving the wrapper script some completely different name, and then<br>
telling TeXworks to use the new name - which I expect should be possible<br>
because TeXworks already is capable of running multiple backends.  If<br>
TeXworks hard-codes the list of possible names of the TeX engine, then<br>
yes, it might be necessary to name the script something TeXworks can<br>
call... but possibilities for leaving it in place could include giving the<br>
script the name of some other TeX engine TeXworks can invoke (ugly, but<br>
it'd work) or putting the script in a PATH directory searched before the<br>
one that contains real XeTeX, so that it can replace real XeTeX without<br>
touching any other executables.<br>
<br>
There's an issue here of which I've been trying to politely not make a big<br>
deal, but:<br>
<br>
We have only one user demanding this.  If we even care at all, then we<br>
don't need a solution for everybody.  Just him.<br>
<br>
That means questions of portability to all operating systems, or of<br>
compatibility with software and features he doesn't use, are not really<br>
significant.  It also means the question "Who should write new code?" is<br>
not the false dilemma Philip Taylor has repeatedly claimed, with the<br>
answer necessarily being either "all TeX engine maintainers!" or "all<br>
front end maintainers!"<br>
<br>
It isn't *all* of any open-ended group.<br>
<br>
It's *one* person who wants his system to operate differently, who could<br>
have that by writing a script himself, and who has succeeded in winding us<br>
up to treat his very personal use case as if it needed to be universal.<br>
<br>
TeXworks; XeTeX (and specifically not XeLaTeX); whatever operating system<br>
Philip Taylor uses.  Not all front ends; not all TeX engines; not any<br>
LaTeX-specific feature; not all operating systems; only one user.  This is<br>
not a general issue and it does not need a universally portable solution.<br>
<span><br>
> another program which is supposed to be in PATH.  Nowadays EPS files<br>
> are converted to PDF on-the-fly, if necessary.  But it can only work<br>
> if the directory containing the TeX Live binaries is in PATH so that<br>
> epstopdf can be found.<br>
<br>
</span>Is that a TeX feature or a LaTeX feature?  Mr. Taylor famously doesn't use<br>
LaTeX, so if it's a LaTeX feature, breaking it doesn't matter - but it'd<br>
only be broken if epstopdf were taken out of PATH anyway, which I did not<br>
recommend.  (Does whatever searches for epstopdf even use PATH anyway?<br>
I'd've expected it to use kpsewhich, independently of PATH.  But this<br>
isn't relevant!)<br>
<br>
Even if it were necessary to take the real XeTeX out of PATH - which is<br>
not the case - why would that have anything to do with changing the name<br>
or location of epstopdf?<br>
<span><br>
> Your suggestion implies that there are two programs with the same<br>
> name name in different directories.  This is nasty and certainly<br>
<br>
</span>No, I intended that the script should not be named "xetex" and that real<br>
XeTeX should remain where it is.  If TeXworks hardcoded the name so that<br>
the script were forced to be named "xetex", then yes, things would become<br>
more complicated, but I don't think that is actually the case, and even if<br>
it were, it would not be a dealbreaker.<br>
<span><br>
> causes more problems than it solves.  And please consider that there<br>
> are zillions of TeX engines/formats nowadays and you need wrappers for<br>
> all of them.<br>
<br>
</span>Only the engine that one user uses, and it only has to work on his system.<br>
<span><br>
> order to save time.  But if your wrapper scans the log file in order<br>
> to determine the proper exit status, you don't save any time at all.<br>
<br>
</span>I think most of us agree that saving computation time is not a real<br>
consideration here.  You say so yourself, below.<br>
<span><br>
> The best solution is to run a script which inspects the log file after<br>
> each TeX run.<br>
<br>
</span>Yes, that's what I said.<br>
<br>
Apparently TeXworks's built-in feature for running postprocessing scripts<br>
isn't suitable for this purpose because the scripts run by that feature<br>
aren't able to tell TeXworks that TeX has "failed" in the way that causes<br>
it to open a log window, which was was what the user wanted.  But a<br>
wrapper script could do it by returning a nonzero exit code, so I think a<br>
wrapper script is the best solution.<br>
<span><br>
> Emacs/AUCTeX is doing this for more than two decades.<br>
> Programming languages like Perl or Lua are probably even faster than<br>
> Emacs Lisp.  Not to mention that computers are much faster than 20<br>
> years ago.<br>
<br>
</span>Indeed.<br>
<span><br>
> Phil assumed that scanning the log file is time consuming and thus<br>
> suggested configurable exit values.  But as Zdeněk already pointed<br>
> out, scanning the log file is not time consuming at all.<br>
<br>
</span>I agree.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Matthew Skala<br>
<a href="mailto:mskala@ansuz.sooke.bc.ca">mskala@ansuz.sooke.bc.ca</a>                 People before principles.<br>
<a href="http://ansuz.sooke.bc.ca/" target="_blank" rel="noreferrer">http://ansuz.sooke.bc.ca/</a></div></div></blockquote></div><br></div>