halt-on-error
jfbu
jfbu at free.fr
Wed Jul 17 10:00:36 CEST 2024
Hello Karl,
thanks for CCeing as I am not currently on the list
> Le 17 juil. 2024 à 00:07, Karl Berry <karl at freefriends.org> a écrit :
>
> Hi,
>
> With option -halt-on-error, the \errhelp contents is not displayed.
> Could there be an option showing it first, then stopping?
>
> What is the practical case where this would be helpful?
I recently contributed to the https://faq.gutenberg-asso.fr/index.html <https://faq.gutenberg-asso.fr/index.html>
project to produce a PDF version of their site. We are compiling
currently about 1850 examples externalized from the main LaTeX file.
Sometimes new examples are added, or edited, or there
is some update of packages usptream, and examples fail to compile.
Particularly during the phase where the system was built-up this
could mean dozens of such examples (many for example used
\og and \fg with \usepackage{french} rather than \usepackage[french]{babel)).
The whole process is a computer intensive task which first produces
the LaTeX file from the Markdown sources then launches the PDF build,
and on one hand we need to abort in case of error but not have to
fix errors one by one, as then each one would need perhaps 5 minutes build
at least before failure.
So I set up a mechanism which in case external builds fail will
accumulate
the related data and raise an error only at end{document}. And
we use -halt-on-error in case some error arises from the main LaTeX,
revealing perhaps faulty mark-up in the sources.
I had set up
LaTeX \PackageError so that it would print out a summary of
all encountered missing external files at \end{document},
so that we could easily go back to the sources. Alas,
as my MWE in TeX in my original post shows, the \errhelp
mechanism of TeX is dropped. And log file
will contain only \errmessage output (there is no console
output is empty because we trigger Latexmk with -silent option,
else the stdout scrolls more than ten thousand lines from
each LaTeX (and there are 2 or 3) due to the thousands
of external small Latexmk and pdfcrop.
You will say I could have used the first argument (after
fictitious package name) of \PackageError to spit out all
needed information, which is right.
In the end, I dropped the idea of using \PackageError
because unfortunately if using it there is no PDF
whatsoever in the end, so we really lose all
the work. Another method is used to pass the information
from LaTeX to the shell and make.
Sorry for long, but you asked and I explain why I was
motivated to make this feature request. I admit as
said in previous paragraph that any how the artificial
error used to report missing input files for whose
existence a careful wrapper avoided errors on the spot
is no good.
But I though that maybe LaTeX or other macro collections
do put sometimes useful information in \errhelp.
(but in the real world many people motivate alternatives to
TeX/LaTeX by "and we produce helpful error messages"
which I know will let people cringe, but remember we
consider the messages are helpful because we are in
fact experts)
There are situations where you use -batchmode -halt-on-error
and it is a bit frustrating that perhaps crucial information gets
completely lost if the macro layer has put useful things in
\errhelp.
>
> I can't say I'm enthused about tinkering with the hardly-ever-used
> -halt-on-error behavior at this point ... --thanks, karl.
Not my call, only a proposal you folks can ponder and
do or not do something...
I personally of course never experience errors with my own
code, so this is really only "maybe I should tell them about this".
Best,
Jean-François
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20240717/35862968/attachment-0001.htm>
More information about the tex-live
mailing list.