emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: tsd@tsdye.com (Thomas S. Dye)
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: New LaTeX exporter and #+call:
Date: Sat, 15 Sep 2012 09:16:14 -1000	[thread overview]
Message-ID: <m1627f2j29.fsf@poto.myhome.westell.com> (raw)
In-Reply-To: <871ui3ifd3.fsf@gmail.com> (Nicolas Goaziou's message of "Sat, 15 Sep 2012 15:29:28 +0200")

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> #+call: lines appear to flummox the new LaTeX exporter.
>>
>> This exports as I expect:
>>
>> #+caption[Old wood]: Old wood graph.
>> #+label: fig:old-wood
>> #+results: old-wood[:file old-wood.pdf]():results file
>> [[file:old-wood.pdf]]
>
> It doesn't matter here, but #+label ought to be to #+name in the new
> exporter.
>
Thanks.

>> But this yields "\url{file://nil}":
>>
>> #+call: old-wood[:file old-wood.pdf]() :results file
>> #+caption[Old wood]: Old wood graph.
>> #+label: fig:old-wood
>> #+results: old-wood[:file old-wood.pdf]():results file
>> [[file:old-wood.pdf]]
>
> I cannot reproduce the problem. It may be an hiccup in your "old-wood"
> src-block, which you didn't provide.
>
> You may try to eval:
>
>   (let ((org-current-export-file (current-buffer)))
> (org-export-blocks-preprocess))
>
> in a copy of the buffer you're trying to export. It will reveal what the
> parser really see. Is there anything suspicious?

Interesting.  If I evaluate org-export-blocks-preprocess, all looks well
and the resulting buffer exports correctly with org-export-dispatch.
The evaluated results of the #+call: lines are present in the
preprocessed buffer, and the #+call: lines themselves are gone.

Apparently, something else happens when the original buffer is exported
with org-export-dispatch. This route appears to ignore the evaluated
results of the #+call: lines and instead uses the results of a new call.
This was failing for me because I'd set :eval no-export on the source
code blocks after I'd evaluated the #+call: lines in the buffer,
thinking that the exporter would find the results and use them.

Thanks for your help, and apologies for the noisy posts.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

      reply	other threads:[~2012-09-15 19:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-14 20:51 New LaTeX exporter and #+call: Thomas S. Dye
2012-09-15 13:29 ` Nicolas Goaziou
2012-09-15 19:16   ` Thomas S. Dye [this message]

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=m1627f2j29.fsf@poto.myhome.westell.com \
    --to=tsd@tsdye.com \
    --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).