From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Two questions about using a =#+begin_src emacs-lisp= block Date: Mon, 21 Feb 2011 10:17:16 -0700 Message-ID: <874o7x5ms7.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=47305 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrZPL-0006oq-Bl for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 12:18:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrZPI-00053a-DV for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 12:18:45 -0500 Received: from mail-yw0-f41.google.com ([209.85.213.41]:57706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrZPI-00052E-Ae for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 12:18:44 -0500 Received: by mail-yw0-f41.google.com with SMTP id 5so988423yws.0 for ; Mon, 21 Feb 2011 09:18:44 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Chris Malone Cc: emacs-orgmode Chris Malone writes: > Hi, > > First off, my =org-mode= is up-to-date - just did a =git pull && make clean > && make=. Needless to say, the following were an issue before then... > > * Question 1: > Is there a way to force, upon export, an =emacs-lisp= session to be run > within the current buffer? For instance, the following code > > =============================================================== > #+begin_src emacs-lisp :exports both > (buffer-file-name) > > #+end_src > =============================================================== > > exports to LaTeX as > > =============================================================== > \begin{verbatim} > > (buffer-file-name) > > \end{verbatim} > > > > > =============================================================== > > In other words, as far as I can tell, the code is passed to the interpreter, > which does not know about the current buffer information, and therefore the > result of the =emacs-lisp= code is an empty string. By contrast, if I use > =C-c C-c= to evaluate the code block, then I get the proper result printed > in the =.org= buffer: > Hi Chris, This is due to the fact that during export Org-mode copies the entire buffer contents into a new export buffer (which is not associated with any file, hence `buffer-file-name' returning nothing). This is done so that the exporter can operate destructively on the file contents without affecting the original buffer. There is a way to work around this issue. The "header arguments" to code blocks are calculated in the original buffer (so that things like references will correctly resolve). Given this, the following code block will generate the output you are seeking... #+begin_src emacs-lisp :var file-name=(buffer-file-name) :exports both file-name #+end_src > > =============================================================== > #+results: > > : /home/cmalone/org_tests/python_class_lstings.org > =============================================================== > > Ultimately, I'd like to, upon export, have a =emacs-lisp= code block that > does a regexp search on the file and returns a list of matches, which can > then be placed in a =latex= code block. This sort of action suffers from > the same issue as the =(buffer-file-name)= code - in essence this is a > minimal (non)working example. > > * Question 2: > Why does the following code, upon export, ask if I want to evaluate the > =emacs-lisp= code *TWICE* and then give a /Invalid read syntax: "#"/ error > in the message window?: > > =============================================================== > #+begin_src emacs-lisp :exports > both > (buffer-file-name) > > #+end_src > #+begin_src sh :exports > both > ls > -l > #+end_src > =============================================================== > > Note that this works fine as long as the =:exports= tag for the =emacs-lisp= > code block is *NOT* =both= or =results=. Also note that the value of the > =:exports= tag on the =sh= code block is irelevant for this error to > appear. Also, it doesn't have to be this particular combination of > =emacs-lisp= and =sh= blocks; for instance it fails with an =emacs-lisp= and > a =python= source block. > I can't reproduce this bug, try setting `org-confirm-babel-evaluate' to nil. Best -- Eric > > Is this a bug? > > Chris