Re: Two questions about using a =#+begin_src emacs-lisp= block

[Dan Davison <dandavison7@gmail.com>]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> 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.

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