From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Org babel does not work properly with included files Date: Thu, 05 May 2011 10:56:41 -0600 Message-ID: <87aaf0vpgb.fsf@gmail.com> References: <4DBDFE55.7080303@sift.info> <4DBE1B3D.8080007@sift.info> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:44048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI5Yl-0008UO-Cu for emacs-orgmode@gnu.org; Thu, 05 May 2011 16:54:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI5Yk-0004fW-2o for emacs-orgmode@gnu.org; Thu, 05 May 2011 16:54:07 -0400 Received: from mail-pz0-f41.google.com ([209.85.210.41]:63254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI5Yj-0004fL-UX for emacs-orgmode@gnu.org; Thu, 05 May 2011 16:54:06 -0400 Received: by pzk4 with SMTP id 4so1622096pzk.0 for ; Thu, 05 May 2011 13:54:04 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: rpgoldman@sift.info Cc: Org Mode 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 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/