From: Robert Goldman <rpgoldman@sift.info>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Org babel does not work properly with included files
Date: Thu, 05 May 2011 16:12:47 -0500 [thread overview]
Message-ID: <4DC312CF.6050408@sift.info> (raw)
In-Reply-To: <87aaf0vpgb.fsf@gmail.com>
On 5/5/11 May 5 -11:56 AM, Eric Schulte wrote:
> 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.
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
next prev parent reply other threads:[~2011-05-05 21:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-02 0:44 Org babel does not work properly with included files Robert Goldman
2011-05-02 1:33 ` Nick Dokos
2011-05-02 1:48 ` Robert P. Goldman
2011-05-02 3:43 ` Nick Dokos
2011-05-02 4:15 ` Robert P. Goldman
2011-05-02 1:52 ` Robert P. Goldman
2011-05-02 2:47 ` Robert Goldman
2011-05-05 16:56 ` Eric Schulte
2011-05-05 21:12 ` Robert Goldman [this message]
2011-05-05 21:27 ` Eric Schulte
2011-05-05 22:10 ` Robert Goldman
2011-05-11 14:24 ` Robert Goldman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DC312CF.6050408@sift.info \
--to=rpgoldman@sift.info \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).