emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Charles Millar <millarc@verizon.net>
To: emacs-orgmode@gnu.org, Nicolas Goaziou <n.goaziou@gmail.com>
Subject: Re: [PATCH] Add catch-up all LaTeX errors
Date: Wed, 26 Mar 2014 18:33:30 -0400	[thread overview]
Message-ID: <533355BA.1030003@verizon.net> (raw)
In-Reply-To: <87zjkdt3le.fsf@gmail.com>

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

  parent reply	other threads:[~2014-03-26 22:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
     [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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533355BA.1030003@verizon.net \
    --to=millarc@verizon.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).