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:
===============================================================
#+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.
Is this a bug?
Chris
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
