emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] Add catch-up all LaTeX errors


From: Francesco Pizzolante
Subject: Re: [O] [PATCH] Add catch-up all LaTeX errors
Date: Thu, 27 Mar 2014 11:19:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt)


Hi Nicolas,

>>> IOW, it cannot tell the difference between a successful export and an
>>> export failure with an already existing PDFFILE.
>>
>> This is not true as this code checks for the `errors' variable in all
>> cases. With an already existing PDFFILE, you will end up with this
>> message: 'Process completed with errors: ...'.
>
> If "file.pdf" exists before the export, you will always get "Process
> completed", even if the current export was a total failure (e.g., no
> file produced).
>
> IIUC, you're really looking after a way to know if a pdf file was really
> produced. Reporting "Process completed with errors : [unknown error]"
> will certainly not help on this you because some errors are not fatal
> (i.e., they are skipped and the pdf file is still produced).
>
>> From my point of view, the issue comes from the fact that the `errors'
>> variable is not correctly filled in with errors from the LaTeX log file.
>
> [...]
>
>> While the wikibooks reference
>> (http://en.wikibooks.org/wiki/LaTeX/Errors_and_Warnings) tells that to
>> be sure to catch *all* errors, we have to check for any line beginning
>> with '!'.
>
> I agree, but this is not sufficient, see below.
>
>> Then, in the case where the `errors' variable would effectively contain
>> any error from the log file, the code you mention above would work in
>> any case.
>>
>> That's why I started with this patch (*and it works*):
>
> It depends on what you define as "working". We're talking about two
> different things. I think a better error system should report:
>
>   1. a PDF file not produced (or updated),
>   2. a PDF file produced with errors,
>   3. a PDF file produced with warnings (maybe),
>   4. a PDF file produced cleanly.
>
> 4 already works. Your patch improves 2, but 1 is still wrong.

OK, I understand your point: the whole process has to be reviewed and
improved.

But, at least, my patch (or something similar) goes in the right
direction providing a better catching of errors from the log file. Isn't
it?

Could we at least apply this patch (or a better one) that fixes this
single precise issue (catching all errors from the log file)?

Thanks for your help.

Regards,
 Francesco




reply via email to

[Prev in Thread] Current Thread [Next in Thread]