From: Chris Malone <chris.m.malone@gmail.com>
To: Eric Schulte <schulte.eric@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 13:31:04 -0500 [thread overview]
Message-ID: <AANLkTinkE689tOEGyV7X-Y_VuYr-sx1d9bVmfwpP9U8Z@mail.gmail.com> (raw)
In-Reply-To: <874o7x5ms7.fsf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4203 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 5524 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
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
next prev parent reply other threads:[~2011-02-21 18:31 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
2011-02-21 18:31 ` Chris Malone [this message]
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=AANLkTinkE689tOEGyV7X-Y_VuYr-sx1d9bVmfwpP9U8Z@mail.gmail.com \
--to=chris.m.malone@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/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).