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 msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/
-------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
