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