I would say we can close this bug report as INVALID.
AFAICT, the actual problem was happening simply because of the incorrect
treatment of missing links during export, which is now fixed. When that
got fixed, my issue went away.
best,
r
On 5/5/11 May 5 -4:27 PM, Eric Schulte wrote:
>>>
>>> I'm not sure that the current behavior is a bug. Is it reasonable to
>>> place code block parameters into an included file? These parameters
>>> would not be successfully found during interactive evaluation, and could
>>> only plausibly be use
>>
>> I'm not sure that the current behavior is a bug. Is it reasonable to
>> place code block parameters into an included file? These parameters
>> would not be successfully found during interactive evaluation, and could
>> only plausibly be used during export as you anticipated.
>
> Aren't the
On 5/5/11 May 5 -11:56 AM, Eric Schulte wrote:
> Robert Goldman writes:
>
>> Looking over this some more, I see that the challenge is to:
>>
>> 1. read the file parameters (whatever they are) from the original file
>> (hence opening the file from the link) and
>>
>> 2. read the header parameter
Robert Goldman writes:
> Looking over this some more, I see that the challenge is to:
>
> 1. read the file parameters (whatever they are) from the original file
> (hence opening the file from the link) and
>
> 2. read the header parameters from the export buffer, since the header
> may not actu
Yes. That's right, the single source block was a simplification for the
example. It was abstracted from a more complicated case with a dozen or so
source blocks in the subordinate filter. But thanks for the suggestion.
Hope we can find a fix!
Best
R
--
Sent from my Android phone with K-9 Mail.
Robert P. Goldman wrote:
> Sorry, I think I have created a red herring here by leaving that code blo=
> ck in both files. To see what the problem really is, consider the case wh=
> ere the source code block appears ONLY in the included file.
>
> (I tested the source block in the master file to
Looking over this some more, I see that the challenge is to:
1. read the file parameters (whatever they are) from the original file
(hence opening the file from the link) and
2. read the header parameters from the export buffer, since the header
may not actually be contained in the original fil
Also note that if you have an included file with MULTIPLE code blocks, this
approach won't generalize
Best,
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Nick Dokos wrote:
Robert Goldman wrote: foo.org: > * Purpose > > This
document is intended to demonstrate th
Sorry, I think I have created a red herring here by leaving that code block in
both files. To see what the problem really is, consider the case where the
source code block appears ONLY in the included file.
(I tested the source block in the master file to make sure it worked before I
copied it
Robert Goldman wrote:
foo.org:
> * Purpose
>
> This document is intended to demonstrate that src buffer evaluation in
> subsidiary, included files, does not work.
>
> * Demo
>
> #+include "~/src/org-test/bar.org"
>
>
bar.org:
> * Here's the demo
>
> #+begin_src sh :exports results :result
Here's the problem: when org-babel goes to look for parameters when executing
a source block, it looks for them in the parent source file, and not in the
parent source file with the included materials. Here is the function that goes
awry:
(defmacro org-babel-exp-in-export-file (lang &rest bo
12 matches
Mail list logo
