From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: Two questions about using a =#+begin_src emacs-lisp= block Date: Mon, 21 Feb 2011 14:19:03 -0800 Message-ID: References: <874o7x5ms7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=51524 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pre6B-0007EK-DX for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 17:19:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pre6A-0000gP-6G for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 17:19:19 -0500 Received: from mail-iw0-f169.google.com ([209.85.214.169]:32900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pre69-0000gJ-Vu for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 17:19:18 -0500 Received: by iwl42 with SMTP id 42so3288454iwl.0 for ; Mon, 21 Feb 2011 14:19:16 -0800 (PST) In-Reply-To: <874o7x5ms7.fsf@gmail.com> (Eric Schulte's message of "Mon, 21 Feb 2011 10:17:16 -0700") 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: Eric Schulte Cc: Chris Malone , emacs-orgmode "Eric Schulte" writes: > 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. Ideally this should be an implementation detail that is completely hidden from the user. So I'd say that the fact that execution on export does not behave like interactive execution is a bug. Should we consider fixing this? > > 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 > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode