On Mon, Feb 21, 2011 at 12:17 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Chris Malone <chris.m.malone@gmail.com> 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
>
> Hi Eric,

Thanks for this workaround - this does exactly what I want.


> >
> > ===============================================================
> > #+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
>

I added =(setq org-confirm-babel-evaluate nil)= to my =.emacs= file, and
indeed I am not asked about evaluating the code block, but I'm still getting
the invalid syntax error when =org-babel-exp= is called the second time on
the =emacs-lisp= code block.  I should mention that this is somewhere in the
byte-code, as the error is:

byte-code: Invalid read syntax: "#"

in the *Messages* buffer.  I still don't fully understand why it should be
evaluating that code block twice.

Chris