* [PATCH] Add catch-up all LaTeX errors
@ 2013-10-11 8:11 Francesco Pizzolante
[not found] ` <87vc14i5wp.fsf-oHC15RC7JGTNLxjTenLetw@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Francesco Pizzolante @ 2013-10-11 8:11 UTC (permalink / raw)
To: mailing-list-org-mode
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:
--8<---------------cut here---------------start------------->8---
! I can't write on file `toto.pdf'.
[...]
--8<---------------cut here---------------end--------------->8---
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:
--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---
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:
--8<---------------cut here---------------start------------->8---
Process completed with errors: [LaTeX error] [Unknown error]
--8<---------------cut here---------------end--------------->8---
To this issue, I see 2 solutions:
1. Either catch all errors with a single regexp (and remove all other regexps):
--8<---------------cut here---------------start------------->8---
(defcustom org-latex-known-errors
'(("^!.*" . "LaTeX error"))
[...]
--8<---------------cut here---------------end--------------->8---
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:
--8<---------------cut here---------------start------------->8---
Process completed with errors: [! I can't write on file `toto.pdf'.]
--8<---------------cut here---------------end--------------->8---
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
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
[not found] ` <87vc14i5wp.fsf-oHC15RC7JGTNLxjTenLetw@public.gmane.org>
@ 2014-03-26 14:36 ` Francesco Pizzolante
2014-03-26 14:51 ` Nicolas Goaziou
0 siblings, 1 reply; 15+ messages in thread
From: Francesco Pizzolante @ 2014-03-26 14:36 UTC (permalink / raw)
To: mailing-list-org-mode
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
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-26 14:36 ` Francesco Pizzolante
@ 2014-03-26 14:51 ` Nicolas Goaziou
[not found] ` <87zjkdt3le.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-26 22:33 ` Charles Millar
0 siblings, 2 replies; 15+ messages in thread
From: Nicolas Goaziou @ 2014-03-26 14:51 UTC (permalink / raw)
To: Francesco Pizzolante; +Cc: mailing-list-org-mode
Hello,
"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)))))
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
[not found] ` <87zjkdt3le.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2014-03-26 15:39 ` Francesco Pizzolante
2014-03-26 16:12 ` Nicolas Goaziou
0 siblings, 1 reply; 15+ messages in thread
From: Francesco Pizzolante @ 2014-03-26 15:39 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: mailing-list-org-mode, Francesco Pizzolante
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
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-26 15:39 ` Francesco Pizzolante
@ 2014-03-26 16:12 ` Nicolas Goaziou
2014-03-26 18:55 ` Sebastien Vauban
[not found] ` <87vbv1szuv.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 2 replies; 15+ messages in thread
From: Nicolas Goaziou @ 2014-03-26 16:12 UTC (permalink / raw)
To: Francesco Pizzolante; +Cc: mailing-list-org-mode, Francesco Pizzolante
"Francesco Pizzolante" <fpz@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-26 16:12 ` Nicolas Goaziou
@ 2014-03-26 18:55 ` Sebastien Vauban
2014-03-27 10:02 ` Nicolas Goaziou
[not found] ` <87vbv1szuv.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1 sibling, 1 reply; 15+ messages in thread
From: Sebastien Vauban @ 2014-03-26 18:55 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Nicolas Goaziou wrote:
> "Francesco Pizzolante" <fpz-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-26 14:51 ` Nicolas Goaziou
[not found] ` <87zjkdt3le.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2014-03-26 22:33 ` Charles Millar
[not found] ` <533355BA.1030003-H+0wwilmMs3R7s880joybQ@public.gmane.org>
2014-03-28 4:40 ` Marcin Borkowski
1 sibling, 2 replies; 15+ messages in thread
From: Charles Millar @ 2014-03-26 22:33 UTC (permalink / raw)
To: emacs-orgmode, Nicolas Goaziou
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-26 18:55 ` Sebastien Vauban
@ 2014-03-27 10:02 ` Nicolas Goaziou
2014-03-27 10:17 ` Sebastien Vauban
0 siblings, 1 reply; 15+ messages in thread
From: Nicolas Goaziou @ 2014-03-27 10:02 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
Hello,
Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-27 10:02 ` Nicolas Goaziou
@ 2014-03-27 10:17 ` Sebastien Vauban
2014-03-28 10:59 ` Nicolas Goaziou
0 siblings, 1 reply; 15+ messages in thread
From: Sebastien Vauban @ 2014-03-27 10:17 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
[not found] ` <87vbv1szuv.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2014-03-27 10:19 ` Francesco Pizzolante
0 siblings, 0 replies; 15+ messages in thread
From: Francesco Pizzolante @ 2014-03-27 10:19 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: mailing-list-org-mode, Francesco Pizzolante
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
[not found] ` <533355BA.1030003-H+0wwilmMs3R7s880joybQ@public.gmane.org>
@ 2014-03-27 10:27 ` Francesco Pizzolante
0 siblings, 0 replies; 15+ messages in thread
From: Francesco Pizzolante @ 2014-03-27 10:27 UTC (permalink / raw)
To: Charles Millar; +Cc: Nicolas Goaziou, emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-26 22:33 ` Charles Millar
[not found] ` <533355BA.1030003-H+0wwilmMs3R7s880joybQ@public.gmane.org>
@ 2014-03-28 4:40 ` Marcin Borkowski
2014-03-28 8:14 ` Francesco Pizzolante
1 sibling, 1 reply; 15+ messages in thread
From: Marcin Borkowski @ 2014-03-28 4:40 UTC (permalink / raw)
To: emacs-orgmode
Dnia 2014-03-26, o godz. 18:33:30
Charles Millar <millarc@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-28 4:40 ` Marcin Borkowski
@ 2014-03-28 8:14 ` Francesco Pizzolante
0 siblings, 0 replies; 15+ messages in thread
From: Francesco Pizzolante @ 2014-03-28 8:14 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-27 10:17 ` Sebastien Vauban
@ 2014-03-28 10:59 ` Nicolas Goaziou
2014-03-28 13:53 ` Sebastien Vauban
0 siblings, 1 reply; 15+ messages in thread
From: Nicolas Goaziou @ 2014-03-28 10:59 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
Hello,
Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Add catch-up all LaTeX errors
2014-03-28 10:59 ` Nicolas Goaziou
@ 2014-03-28 13:53 ` Sebastien Vauban
0 siblings, 0 replies; 15+ messages in thread
From: Sebastien Vauban @ 2014-03-28 13:53 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Nicolas Goaziou wrote:
> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@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.
OK. From reading the docstring, I thought it would contain the name of
the original buffer.
Best regards,
Seb
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-03-28 13:53 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-11 8:11 [PATCH] Add catch-up all LaTeX errors Francesco Pizzolante
[not found] ` <87vc14i5wp.fsf-oHC15RC7JGTNLxjTenLetw@public.gmane.org>
2014-03-26 14:36 ` Francesco Pizzolante
2014-03-26 14:51 ` Nicolas Goaziou
[not found] ` <87zjkdt3le.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-26 15:39 ` Francesco Pizzolante
2014-03-26 16:12 ` Nicolas Goaziou
2014-03-26 18:55 ` Sebastien Vauban
2014-03-27 10:02 ` Nicolas Goaziou
2014-03-27 10:17 ` Sebastien Vauban
2014-03-28 10:59 ` Nicolas Goaziou
2014-03-28 13:53 ` Sebastien Vauban
[not found] ` <87vbv1szuv.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-27 10:19 ` Francesco Pizzolante
2014-03-26 22:33 ` Charles Millar
[not found] ` <533355BA.1030003-H+0wwilmMs3R7s880joybQ@public.gmane.org>
2014-03-27 10:27 ` Francesco Pizzolante
2014-03-28 4:40 ` Marcin Borkowski
2014-03-28 8:14 ` Francesco Pizzolante
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).