emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

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