On 5/5/11 May 5 -11:56 AM, Eric Schulte wrote: > Robert Goldman <rpgold...@sift.info> 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 actually be contained in the original file. >> > > The above is a good summary. Babel ensures that code blocks will be > evaluated in the original buffer, so that they can e.g., reference a > code block outside of the exported subtree when only exporting a > subtree. > >> >> This seems like a substantial reorganization from the original, which >> attempts to do both tasks in the original file (and fails for included >> files). >> > > 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 code block parameters supposed to appear /with/ the code block? So here's the use case: I have a file chapter.org. This contains a full draft of a chapter of my manual. I finish it and circulate it for comments, then get it ready for inclusion. Now I have manual.org and I want to include the main body of chapter.org (typically there's some front matter I leave off). When I put the #include in manual.org, the source code snippets in chapter.org, which used to work, no longer do. This doesn't seem like /such/ a crazy use case that it shouldn't work, does it? [btw, I am not entirely sure I know what "header parameters" are --- are these the parameters that come from the #+begin_src line? If so, shouldn't they definitely be read from the #+begin_src line? They can't very well be read from manual.org, which doesn't contain the #+begin_src line.] Sorry if I wasn't clear in my original message. Best, r
