Philip, you’ve made your point many times now, and I am pretty certain that
everybody has understood it. Please accept that that does not imply that
everybody also needs to agree with your conclusion. Please also be respectful
of other people’s time.
Regards,
Roland
> 18 mar 2016 kl. 10:55
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
Are you /determined/ not to let this matter be brought to a close,
Arthur, in just the same way that you were clearly determined not to
allow the debate on Greek & Latin hyphenation be brought to a close on
another list ? My sole contribution to this thread post 13th inst. was
one response in
On Wed, 16 Mar 2016, Stefan Löffler wrote:
> More importantly, though, several scripts could be run (say, one that
> looks only for errors and only that only looks for warnings) which could
> give contradicting results (e.g., no errors => close, warnings => don't
I think you're describing some
2016-03-18 10:55 GMT+01:00 Philip Taylor :
>
>
> Arthur Reutenauer wrote:
>
> > Of course they can /know/: by inspecting the log file. It contains
> > the exact transcript of the TeX run, and thus reflects all of TeX's
> > knowledge about what happened when compiling the
Here, here (or is it "Hear, hear"?)
Peter W.
On 18/03/16 19:19, Roland Kuhn wrote:
Please, this is clearly not leading anywhere, and it has long since diverged
from the topics this list has been created for.
18 mar 2016 kl. 19:20 skrev Philip Taylor :
Are you
On Fri, Mar 18, 2016 at 12:07:26PM +, Philip Taylor wrote:
> You will, I am sure, be
> aware that I had not pursued the topic for some time
That's simply not true.
Arthur
--
Please, this is clearly not leading anywhere, and it has long since diverged
from the topics this list has been created for.
> 18 mar 2016 kl. 19:20 skrev Philip Taylor :
>
> Are you /determined/ not to let this matter be brought to a close,
> Arthur, in just the same way
Dear Akira-san --
> As Stefan says:
>
> SL> However, it can be worked around relatively easily by manually
> SL> opening the console (which should then remain open until closed
> manually).
>
> I think it is best to open the console window manually
> by CTRL+\. Then the console window is not
Zdeněk Wagner wrote:
> Even now it is possible to swich to \scrollmode or \nonstopmode and
> issue \errmsg although no error appeared. As another test I inserted the
> following:
>
> \setbox254=\hbox to .1pt{A}
>
> It reports an overfull hbox although the box is never used. Thus if the
> code
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
Dear Philip,
As Stefan says:
SL> However, it can be worked around relatively easily by manually
SL> opening the console (which should then remain open until closed manually).
I think it is best to open the console window manually
by CTRL+\. Then the console window is not closed, and you can
Den 19 mar 2016 11:00 skrev "Philip Taylor" :
>
>
>
> Reinhard Kotucha wrote:
>
> > It's true that only TeX /knows/ whether bad boxes occurred during a
> > TeX run. But TeX passes this knowledge to the log file, hence
> > nothing is lost and the log file even provides more
On 2016-03-17 at 00:41:45 -0500, msk...@ansuz.sooke.bc.ca wrote:
> On Wed, 16 Mar 2016, Stefan Löffler wrote:
> > More importantly, though, several scripts could be run (say, one
> > that looks only for errors and only that only looks for warnings)
> > which could give contradicting results
Reinhard Kotucha wrote:
> 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.
Whether or not scanning the log file is time-consuming is not really my
Roland Kuhn wrote:
> Philip, you’ve made your point many times now, and I am pretty
> certain that everybody has understood it.
Unfortunately it would seem that Arthur had not. You will, I am sure, be
aware that I had not pursued the topic for some time until Arthur
elected to join the
Hi,
I believe there has been some misunderstanding here that I'd like to try
to clear up.
Personally, I think that the exit code policy of TeX is good. IMO, exit
codes should be (and are) used to report fundamental errors (such as
"program not found" or "I don't understand this input"), not for
Arthur Reutenauer wrote:
> Of course they can /know/: by inspecting the log file. It contains
> the exact transcript of the TeX run, and thus reflects all of TeX's
> knowledge about what happened when compiling the file; as far as
> overfull \hbox'es, etc. are concerned.
Augmented by anything
On Thu, Mar 17, 2016 at 11:58:34PM +, Philip Taylor wrote:
> The key point is this : only *TeX (where *TeX is any derivative
> of TeX; I do not wish to suggest modifying TeX itself out of respect for
> Don's wishes) /knows/ whether (e.g.,) an overfull \hbox has been
> generated during
On 2016-03-17 at 23:58:34 +, Philip Taylor wrote:
>
>
> Reinhard Kotucha wrote:
>
> > 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
On 13/03/2016 1:26 PM, Philip Taylor wrote:
msk...@ansuz.sooke.bc.ca wrote:
If a script begins with the characters "#!" and the name of a script
interpreter, and has the execute bit set, then it can be executed like any
other program, and the front end can run it the same way the front end
Philip Taylor wrote:
> Yes, it is the "inspecting the log file" that I am trying to avoid, in
> the interests of efficiency; an inspection of the log file should be
> required (as it currently is) only if the status code returned by *TeX
> is non-zero.
Or to put it even more simply :
Zdeněk Wagner wrote:
> Is such a tiny time so important?
No, but the correct approach is (IMHO, of course). We can either extend
*TeX (for a very small set of *TeX) to conditionally return a non-zero
status IFF some pre-determined set of constraints obtain, or we can
require each
It depends how efficiently the script is designed. I have a perl script
that calculates the MD5 sum of the aux file before running (Xe)LaTex (if it
does not exist, it is first created) and after and then compares the
result. If the difer, it means that (Xe)LaTeX must be run again. If the
document
Jonathan Kew wrote:
> I assume TeXworks will run an AfterTypeset script whether the tool it's
> run exits with zero or non-zero code (won't it?).
As far as I can tell, from the combination of Stefan's reply and my own
observations of the behaviour of TeXworks, TeXworks runs such a script
(to
25 matches
Mail list logo