Re: Org babel does not work properly with included files

["Eric Schulte" <schulte.eric@gmail.com>]

Robert Goldman <rpgoldman@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.

Also, this would seem to break Babel's current guarantee that code
blocks will be evaluated in the original Org-mode file.

If this were to be implemented, I think one option would be to perform
the following on export
1. make a copy of the original buffer
2. call `org-export-handle-include-files' in this copy
3. resolve all parameters in this copied buffer

The above shouldn't be difficult to implement, and creating the copy
shouldn't add too much computational time to the export process.

My concern is that expansion of included files may be more likely to
cause confusing behavior (e.g., by change the evaluation environment
between interactive evaluation and export) than it would to be used
constructively.

Maybe I have missed your initial use case.

Thanks -- Eric

p.s. Sorry about the delayed reply I've had very little mailing
     list connectivity lately

>
> best,
> r
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/