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

[Charles Millar <millarc@verizon.net>]

Nicolas Goaziou wrote:
>
>
> Hello,
>
Nicholas and Francesco,

> "Francesco Pizzolante"
> <fpz-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org> writes:
>
>>> The issue is the fact that, when exporting to PDF, in some cases, Org tells
>>> that the export has been done successfully while the PDF file has not been
>>> produced!
>>>
>>> As an example, if you open the target PDF file with Adobe Reader and, in the
>>> meantime, you export your Org file again to PDF, you'll see that Org will tell
>>> you it's OK (Process Completed) while, if you look at the *Org PDF LaTeX
>>> Output* buffer, you'll see an error such as:
>>>
>>> ! I can't write on file `toto.pdf'.
>>> [...]
>>>
>>> The problem comes from the fact that Org just checks for a couple of error
>>> messages (defined in org-latex-known-errors) and report it's OK if it doesn't
>>> find those messages:
>
> Errors are not related to your problem. Actually, "ox-latex.el" uses
> a rather weak check to know if process was successful or not:
>
>    (if (not (file-exists-p pdffile))
>        (error (concat (format "PDF file %s wasn't produced" pdffile)
>                       (when errors (concat ": " errors))))
>      ...
>      (message (concat "Process completed"
>                       (if (not errors) "." (concat " with errors: " errors)))))
>
First, I have subsequent messages in this thread and the discussion.

Should Nick's observation, that

> IOW, it cannot tell the difference between a successful export and an
> export failure with an already existing PDF


also include the qualification that the existing PDF file is also opened 
at the time of the second export? I base this on Francesco's example 
above and the following.

I usually export a subtree to LaTeX as PDF file and open. If I make 
small corrections to the subtree and export again, AND forget to close 
the PDF file that is already opened from the earlier export, Org reports 
a successful export; however, the "revised" exported PDF does not exist. 
(Also I use EXPORT_FILE_NAME: in PROPERTIES as the top of the subtree.)

If I remember to close the first exported PDF, the revised subtree 
exports OK.

I'm just curious, does the problem exist iff the pdf, that is to be 
replaced, is opened?

Charlie Millar