From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Malone Subject: Re: Two questions about using a =#+begin_src emacs-lisp= block Date: Mon, 21 Feb 2011 13:31:04 -0500 Message-ID: References: <874o7x5ms7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0063957053==" Return-path: Received: from [140.186.70.92] (port=35249 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PraXL-0008NJ-6r for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 13:31:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PraXJ-0002pG-Lu for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 13:31:07 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:64341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PraXJ-0002p5-C6 for emacs-orgmode@gnu.org; Mon, 21 Feb 2011 13:31:05 -0500 Received: by iyf13 with SMTP id 13so2989462iyf.0 for ; Mon, 21 Feb 2011 10:31:04 -0800 (PST) In-Reply-To: <874o7x5ms7.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: emacs-orgmode --===============0063957053== Content-Type: multipart/alternative; boundary=20cf305644a304ef52049ccf119d --20cf305644a304ef52049ccf119d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 21, 2011 at 12:17 PM, Eric Schulte wrote: > Chris Malone 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 --20cf305644a304ef52049ccf119d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 21, 2011 at 12:17 PM, Eric S= chulte <schu= lte.eric@gmail.com> wrote:
Chris Malone <chris.m.malone@gmail.com> writes:

> Hi,
>
> First off, my =3Dorg-mode=3D is up-to-date - just did a =3Dgit pull &a= mp;& make clean
> && make=3D. =A0Needless to say, the following were an issue be= fore then...
>
> * Question 1:
> Is there a way to force, upon export, an =3Demacs-lisp=3D session to b= e run
> within the current buffer? =A0For instance, the following code
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> #+begin_src emacs-lisp :exports both
> =A0(buffer-file-name)
>
> #+end_src
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> exports to LaTeX as
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> \begin{verbatim}
>
> (buffer-file-name)
>
> \end{verbatim}
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> In other words, as far as I can tell, the code is passed to the interp= reter,
> which does not know about the current buffer information, and therefor= e the
> result of the =3Demacs-lisp=3D code is an empty string. =A0By contrast= , if I use
> =3DC-c C-c=3D to evaluate the code block, then I get the proper result= printed
> in the =3D.org=3D 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). =A0This 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. =A0The "header arguments&quo= t; to
code blocks are calculated in the original buffer (so that things like
references will correctly resolve). =A0Given this, the following code
block will generate the output you are seeking...

#+begin_src emacs-lisp :var file-name=3D(buffer-file-name) :exports both =A0file-name
#+end_src

Hi Eric= ,

Thanks for this workaround - this does exactly what I want.
=A0=
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> #+results:
>
> : /home/cmalone/org_tests/python_class_lstings.org
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Ultimately, I'd like to, upon export, have a =3Demacs-lisp=3D code= block that
> does a regexp search on the file and returns a list of matches, which = can
> then be placed in a =3Dlatex=3D code block. =A0This sort of action suf= fers from
> the same issue as the =3D(buffer-file-name)=3D 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 th= e
> =3Demacs-lisp=3D code *TWICE* and then give a /Invalid read syntax: &q= uot;#"/ error
> in the message window?:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> #+begin_src emacs-lisp :exports
> both
> =A0(buffer-file-name)
>
> #+end_src
> #+begin_src sh :exports
> both
> =A0 ls
> -l
> #+end_src
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Note that this works fine as long as the =3D:exports=3D tag for the = =3Demacs-lisp=3D
> code block is *NOT* =3Dboth=3D or =3Dresults=3D. =A0Also note that the= value of the
> =3D:exports=3D tag on the =3Dsh=3D code block is irelevant for this er= ror to
> appear. =A0Also, it doesn't have to be this particular combination= of
> =3Demacs-lisp=3D and =3Dsh=3D blocks; for instance it fails with an = =3Demacs-lisp=3D and
> a =3Dpython=3D 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 =3D(setq org-confirm-babel-evalu= ate nil)=3D to my =3D.emacs=3D file, and indeed I am not asked about evalua= ting the code block, but I'm still getting the invalid syntax error whe= n =3Dorg-babel-exp=3D is called the second time on the =3Demacs-lisp=3D cod= e block.=A0 I should mention that this is somewhere in the byte-code, as th= e error is:

byte-code: Invalid read syntax: "#"

in the *Messages* = buffer.=A0 I still don't fully understand why it should be evaluating t= hat code block twice.

Chris
--20cf305644a304ef52049ccf119d-- --===============0063957053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0063957053==--