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

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