Nicolas Goaziou <n.goaz...@gmail.com> writes:
> Hello,
>
> t...@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
