Re: [O] [PATCH] Add catch-up all LaTeX errors
Hi Marcin, This is rather a workaround, but don't use Adobe Reader, use any other PDF viewer instead. (IIRC, there's also a workaround that makes Adobe Reader behave correctly, i.e. not lock the pdf file, but I can't find it now. See here, for example: http://stackoverflow.com/questions/4910029/possible-to-make-adobe-reader-not-hold-a-file-lock-on-windows) (I, for one, did welcome our new Linux overlords more than a decade ago, and don't experience that problem at all, using first xpdf, and now evince.;)) Thanks for your reply and your suggestion. I already use SumatraPDF (as suggested in your link) since a long time now to avoid this locking problem and it works very well. I'm taking this locking issue as an example to show that some errors are not catched up when we export to LaTeX. Best Regards, Francesco
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Isn't `orgfile' equal to `org-babel-exp-reference-buffer' in `org-latex-compile'? No, `org-babel-exp-reference-buffer' is a temporary buffer attached to no file. It cannot help to find original file. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Add catch-up all LaTeX errors
Nicolas Goaziou wrote: Sebastien Vauban sva-n...@mygooglest.com writes: Isn't `orgfile' equal to `org-babel-exp-reference-buffer' in `org-latex-compile'? No, `org-babel-exp-reference-buffer' is a temporary buffer attached to no file. It cannot help to find original file. OK. From reading the docstring, I thought it would contain the name of the original buffer. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: FWIW, I'm using this in some export code I have: (let* ((orgfile (buffer-file-name)) (base-name (file-name-base orgfile)) (htmlfile (concat base-name .html)) (pdffile (concat base-name .pdf))) ... (when (file-exists-p pdffile) (if (file-newer-than-file-p orgfile pdffile) (org-latex-export-to-pdf) (message PDF is up to date with Org file That way, we know if the PDF file has been (re-)produced: it must be newer than the Org file... True, but, unfortunately, `org-latex-compile' has no access to orgfile. It is possible to rely on `file-attributes' and compare creation time of the pdf file before export (if any) and the one after the export. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hello, Nicolas Goaziou wrote: Sebastien Vauban writes: FWIW, I'm using this in some export code I have: (let* ((orgfile (buffer-file-name)) (base-name (file-name-base orgfile)) (htmlfile (concat base-name .html)) (pdffile (concat base-name .pdf))) ... (when (file-exists-p pdffile) (if (file-newer-than-file-p orgfile pdffile) (org-latex-export-to-pdf) (message PDF is up to date with Org file That way, we know if the PDF file has been (re-)produced: it must be newer than the Org file... True, but, unfortunately, `org-latex-compile' has no access to orgfile. Isn't `orgfile' equal to `org-babel-exp-reference-buffer' in `org-latex-compile'? It is possible to rely on `file-attributes' and compare creation time of the pdf file before export (if any) and the one after the export. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add catch-up all LaTeX errors
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
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hi Charles, 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? You're observing the exact same issue I have. As you can see, in my initial email, I wrote: 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'. [...] To answer your question: yes, the problem exists iff the pdf, that is to be replaced, is opened in Adobe Reader. In this particular case, the problem comes from the fact that we do not catch *all* errors from the log file. Thanks a lot for your remarks. Regards, Francesco
Re: [O] [PATCH] Add catch-up all LaTeX errors
Dnia 2014-03-26, o godz. 18:33:30 Charles Millar mill...@verizon.net napisał(a): 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? This is rather a workaround, but don't use Adobe Reader, use any other PDF viewer instead. (IIRC, there's also a workaround that makes Adobe Reader behave correctly, i.e. not lock the pdf file, but I can't find it now. See here, for example: http://stackoverflow.com/questions/4910029/possible-to-make-adobe-reader-not-hold-a-file-lock-on-windows) (I, for one, did welcome our new Linux overlords more than a decade ago, and don't experience that problem at all, using first xpdf, and now evince.;)) Charlie Millar Hth, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hi, May I bump up this thread? Thanks for your help. Regards, Francesco Francesco Pizzolante wrote: Hi, This is not a definitive patch. It's just a first step in getting a better one. 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: (defcustom org-latex-known-errors '((Reference.*?undefined . [undefined reference]) (Citation.*?undefined . [undefined citation]) (Undefined control sequence . [undefined control sequence]) (^! LaTeX.*?Error . [LaTeX error]) (^! Package.*?Error . [package error]) (Runaway argument . Runaway argument)) [...] In order to be sure to check for ALL errors, we should check for any line beginning with '!' (http://en.wikibooks.org/wiki/LaTeX/Errors_and_Warnings). That's the idea of this patch. Though, the issue with this patch is that some error can match 2 messages, and you get the following display: Process completed with errors: [LaTeX error] [Unknown error] To this issue, I see 2 solutions: 1. Either catch all errors with a single regexp (and remove all other regexps): (defcustom org-latex-known-errors '((^!.* . LaTeX error)) [...] 2. Stop on the first error found and report it. In all cases, it would be much better to be able to report the error line such as: Process completed with errors: [! I can't write on file `toto.pdf'.] Can someone do this or help me to achieve it? Best regards, Francesco --- lisp/ox-latex.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 9262ded..2cffe38 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -862,7 +862,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'. (Undefined control sequence . [undefined control sequence]) (^! LaTeX.*?Error . [LaTeX error]) (^! Package.*?Error . [package error]) -(Runaway argument . Runaway argument)) +(Runaway argument . Runaway argument) +(^!.* . [Unknown error])) Alist of regular expressions and associated messages for the user. The regular expressions are used to find possible errors in the log of a latex-run. -- 1.7.9
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hello, Francesco Pizzolante fpz-djc/ipccudyqhejpep6iedvlejwur...@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) IOW, it cannot tell the difference between a successful export and an export failure with an already existing PDFFILE. This part needs to be improved. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Add catch-up all LaTeX errors
Hi Nicolas, Thanks for your answer. 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) 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: ...'. 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. As you can see in the following code, we do not catch error lines starting with '!' but *only* those starting with '! LaTeX...' and '! Package...': --8---cut here---start-8--- (defcustom org-latex-known-errors '((Reference.*?undefined . [undefined reference]) (Citation.*?undefined . [undefined citation]) (Undefined control sequence . [undefined control sequence]) (^! LaTeX.*?Error . [LaTeX error]) (^! Package.*?Error . [package error]) (Runaway argument . Runaway argument)) [...] --8---cut here---end---8--- 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 '!'. 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*): --- lisp/ox-latex.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 9262ded..2cffe38 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -862,7 +862,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'. (Undefined control sequence . [undefined control sequence]) (^! LaTeX.*?Error . [LaTeX error]) (^! Package.*?Error . [package error]) -(Runaway argument . Runaway argument)) +(Runaway argument . Runaway argument) +(^!.* . [Unknown error])) Alist of regular expressions and associated messages for the user. The regular expressions are used to find possible errors in the log of a latex-run. -- 1.7.9 The only issue is that the error reporting is not really helpfull (as my current patch only reports 'Unknown error' for any other error). Any suggestion is welcome. Best regards, Francesco
Re: [O] [PATCH] Add catch-up all LaTeX errors
Francesco Pizzolante f...@missioncriticalit.com writes: 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. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Add catch-up all LaTeX errors
Nicolas Goaziou wrote: Francesco Pizzolante f...@missioncriticalit.com writes: 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. FWIW, I'm using this in some export code I have: --8---cut here---start-8--- (let* ((orgfile (buffer-file-name)) (base-name (file-name-base orgfile)) (htmlfile (concat base-name .html)) (pdffile (concat base-name .pdf))) ... (when (file-exists-p pdffile) (if (file-newer-than-file-p orgfile pdffile) (org-latex-export-to-pdf) (message PDF is up to date with Org file --8---cut here---end---8--- That way, we know if the PDF file has been (re-)produced: it must be newer than the Org file... Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add catch-up all LaTeX errors
Nicolas Goaziou wrote: Hello, Nicholas and Francesco, Francesco Pizzolante fpz-djc/ipccudyqhejpep6iedvlejwur...@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
