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, <msk...@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 > 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
