From: "Eric Schulte" <schulte.eric@gmail.com>
To: Chris Malone <chris.m.malone@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Two questions about using a =#+begin_src emacs-lisp= block
Date: Mon, 21 Feb 2011 10:17:16 -0700 [thread overview]
Message-ID: <874o7x5ms7.fsf@gmail.com> (raw)
In-Reply-To: AANLkTim_aCMkZPLQxFfN0qkLEO4UNKaS4d8hs22N+G0X@mail.gmail.com
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
next prev parent reply other threads:[~2011-02-21 17:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-20 22:08 Two questions about using a =#+begin_src emacs-lisp= block Chris Malone
2011-02-21 17:17 ` Eric Schulte [this message]
2011-02-21 18:31 ` Chris Malone
2011-02-21 19:48 ` Eric Schulte
2011-02-22 15:06 ` Chris Malone
2011-02-22 16:54 ` Eric Schulte
2011-02-22 16:57 ` Chris Malone
2011-02-22 18:06 ` Eric Schulte
2011-02-22 18:23 ` chris.m.malone
2011-02-22 18:45 ` Achim Gratz
2011-02-21 22:19 ` Dan Davison
2011-02-21 22:34 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874o7x5ms7.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=chris.m.malone@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).