From mboxrd@z Thu Jan  1 00:00:00 1970
From: tsd@tsdye.com (Thomas S. Dye)
Subject: Re: New LaTeX exporter and #+call:
Date: Sat, 15 Sep 2012 09:16:14 -1000
Message-ID: <m1627f2j29.fsf@poto.myhome.westell.com>
References: <m1ipbg2uro.fsf@poto.myhome.westell.com> <871ui3ifd3.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([208.118.235.92]:33352)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <tsd@tsdye.com>) id 1TCxqo-0004P2-Ld
	for emacs-orgmode@gnu.org; Sat, 15 Sep 2012 15:16:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <tsd@tsdye.com>) id 1TCxqn-0001GZ-HJ
	for emacs-orgmode@gnu.org; Sat, 15 Sep 2012 15:16:22 -0400
Received: from oproxy12-pub.bluehost.com ([50.87.16.10]:43136)
	by eggs.gnu.org with smtp (Exim 4.71) (envelope-from <tsd@tsdye.com>)
	id 1TCxqn-0001GN-7d
	for emacs-orgmode@gnu.org; Sat, 15 Sep 2012 15:16:21 -0400
In-Reply-To: <871ui3ifd3.fsf@gmail.com> (Nicolas Goaziou's message of "Sat, 15
	Sep 2012 15:29:28 +0200")
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org-mode <emacs-orgmode@gnu.org>

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