Two questions about using a =#+begin_src emacs-lisp= block

Two questions about using a =#+begin_src emacs-lisp= block

[Chris Malone]

[-- Attachment #1.1: Type: text/plain, Size: 2393 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3477 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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Eric Schulte]

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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Chris Malone]

[-- 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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Eric Schulte]

Chris Malone <chris.m.malone@gmail.com> writes:
[...]
>
> 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.
>

Hmm, it may be worth cleaning out all compiled .elc files from within
Org-mode, the calling org-reload, and see if the problem persists.

Best -- Eric

>
> Chris

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Dan Davison]

"Eric Schulte" <schulte.eric@gmail.com> writes:

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

Ideally this should be an implementation detail that is completely
hidden from the user. So I'd say that the fact that execution on export
does not behave like interactive execution is a bug. Should we consider
fixing this?

>
> 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
>
> _______________________________________________
> 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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Eric Schulte]

[...]
>>
>> 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.
>
> Ideally this should be an implementation detail that is completely
> hidden from the user. So I'd say that the fact that execution on export
> does not behave like interactive execution is a bug. Should we consider
> fixing this?
>

I'd push back on considering this a bug.

Babel currently makes no guarantees about the location in which
evaluation takes place (other than the :dir header argument), and I
would consider it an implementation detail that evaluation of emacs-lisp
does sometimes take place inside the Org-mode buffer (this is not true,
nor could it be for any other language).  By contrast Babel *does*
guarantee that header arguments are resolved in the original Org-mode
buffer, a guarantee that we explicitly maintain during export despite
the Org-mode buffer shuffling.

Best -- Eric

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Chris Malone]

[-- Attachment #1.1: Type: text/plain, Size: 1082 bytes --]

Hi Eric,

I removed all the compiled elisp files, and the problem still persists.
Next step will be a completely fresh install from git; my current version is
up to date, but maybe there was some conflict that git didn't complain
about...

Chris

On Mon, Feb 21, 2011 at 2:48 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Chris Malone <chris.m.malone@gmail.com> writes:
> [...]
> >
> > 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.
> >
>
> Hmm, it may be worth cleaning out all compiled .elc files from within
> Org-mode, the calling org-reload, and see if the problem persists.
>
> Best -- Eric
>
> >
> > Chris
>

[-- Attachment #1.2: Type: text/html, Size: 1559 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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Eric Schulte]

Chris Malone <chris.m.malone@gmail.com> writes:

> Hi Eric,
>
> I removed all the compiled elisp files, and the problem still persists.
> Next step will be a completely fresh install from git; my current version is
> up to date, but maybe there was some conflict that git didn't complain
> about...
>

Before doing that could you re-send a minimal example with instruction
for how to reproduce the problem, and I'll give it another shot.

Thanks -- Eric

>
> Chris
>
> On Mon, Feb 21, 2011 at 2:48 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>
>> Chris Malone <chris.m.malone@gmail.com> writes:
>> [...]
>> >
>> > 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.
>> >
>>
>> Hmm, it may be worth cleaning out all compiled .elc files from within
>> Org-mode, the calling org-reload, and see if the problem persists.
>>
>> Best -- Eric
>>
>> >
>> > Chris
>>

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Chris Malone]

[-- Attachment #1.1: Type: text/plain, Size: 6147 bytes --]

Ok, this is still perplexing me, as I have a new version from git and I
still get the error.  The following is complete list (sorry for the long
email!) of what I have done:

* Get a fresh copy of =org-mode= from git and byte-compile:

#+begin_src: sh
  cd ~/install/org-mode
  mkdir new_git_clone
  cd new_git_clone
  git clone git://orgmode.org/org-mode.git
  cd org-mode; make &> make.out
  ln -s ~/install/org-mode/new_git_clone/org-mode ~/install/org-mode/current
#+end_src

During the =make= process, I noticed quite a few warnings.  An example is
below (for a complete copy of =make.out=, see
http://astro.sunysb.edu/cmalone/nolink/make.out

========================================================================
org.el:19993:1:Warning: the function `parse-time-string' might not be
defined
    at
runtime.
org.el:19993:1:Warning: the following functions are not known to be
defined:
    table--at-cell-p, org-clock-update-mode-line,
org-default-export-plist,
    org-infile-export-plist,
org-inlinetask-at-task-p,

org-inlinetask-toggle-visibility,

org-clock-save-markers-for-cut-and-paste,
    org-agenda-save-markers-for-cut-and-paste,
org-id-get-create,
    dired-get-filename, org-id-store-link,
iswitchb-read-buffer,
    org-agenda-copy-local-variable,
org-attach-reveal,
    org-inlinetask-remove-END-maybe, org-agenda-skip,
org-format-agenda-item,
    org-agenda-new-marker,
org-agenda-change-all-lines,
    org-columns-number-to-string,
org-columns-get-format-and-top-level,
    org-columns-compute,
calendar-absolute-from-iso,
    calendar-iso-from-absolute, org-id-locations-save,
org-id-locations-load,
    cdlatex-tab, org-export-latex-fix-inputenc,
orgtbl-send-table,
    org-inlinetask-in-task-p,
org-inlinetask-goto-beginning,
    org-inlinetask-goto-end,
org-inlinetask-outline-regexp,
    fill-forward-paragraph,
beginning-of-visual-line,
    org-agenda-set-restriction-lock,
speedbar-line-directory,

org-agenda-maybe-redo
Wrote /home/cmalone/install/org-mode/new_git_clone/org-mode/lisp/org.elc
========================================================================

Are such warnings normal?

* Make sure my =.emacs= file is pointing to the correct location
Here is a copy of the =org-mode=-relevant sections of my =.emacs= file:

========================================================================
;;

;; org-mode
stuff
;;

(add-to-list 'load-path
"/home/cmalone/install/org-mode/current/lisp")
(require
'org-install)
(add-to-list 'auto-mode-alist '("\\.org\\'" .
org-mode))
(global-set-key "\C-cl"
'org-store-link)
(global-set-key "\C-ca"
'org-agenda)
(global-set-key "\C-cb"
'org-iswitchb)
(setq org-log-done t)

;; using the prop_just
class
(require
'org-latex)
(add-to-list
'org-export-latex-classes

'("prop_just"

"\\documentclass{prop_just}

[NO-DEFAULT-PACKAGES]

[PACKAGES]

[EXTRA]"
               ("\\section{%s}" .
"\\section*{%s}")
               ("\\subsection{%s}" .
"\\subsection*{%s}")
               ("\\subsubsection{%s}" .
"\\subsubsection*{%s}")
               ("\\paragraph{%s}" .
"\\paragraph*{%s}")
               ("\\subparagraph{%s}" .
"\\subparagraph*{%s}")))
(add-to-list
'org-export-latex-classes

'("letter"

"\\documentclass{letter}

[DEFAULT-PACKAGES]

[PACKAGES]
               [EXTRA]"))

; org-babel
stuff
(org-babel-do-load-languages

 'org-babel-load-languages

 '((org .
t)
   (emacs-lisp .
t)
   (python .
t)
   (latex .
t)
   (perl .
t)
   (sh .
t)
   (C .
t)
   (ditaa .
t)))
(setq org-confirm-babel-evaluate nil)

;;

;; for
YASnippet
;;

(add-to-list 'load-path
"~/.emacs.d/plugins/yasnippet-0.6.1c")
(require
'yasnippet)
(yas/initialize)

(yas/load-directory "~/.emacs.d/plugins/yasnippet-0.6.1c/snippets")

;; define backtab (essentially Shift-Tab) for
org-mode
(global-set-key (kbd "<backtab>") 'org-shifttab)

;; Make TAB the yas trigger key in the org-mode-hook and enable flyspell
mode a\
nd
autofill

(add-hook
'org-mode-hook
          (lambda
()
            ;;
yasnippet
            (make-variable-buffer-local
'yas/trigger-key)
            (org-set-local 'yas/trigger-key
[tab])
            (define-key yas/keymap [tab]
'yas/next-field-group)
            ;; flyspell mode for spell checking
everywhere
            (flyspell-mode
1)
            ;; auto-fill mode
on
            (auto-fill-mode 1)))
========================================================================

* Attempt an export of the =org-mode= file found here:
http://astro.sunysb.edu/cmalone/nolink/python_class_lstings.org

Exporting this to PDF, HTML, or ASCII (I didn't try other forms) results in
the following error in the *Messages* buffer: 'Invalid read syntax: "#"'.  I
turned on =debu-on-error= and the *Messages* and *Backtrace* buffers can be
found here:
http://astro.sunysb.edu/cmalone/nolink/messages.txt
http://astro.sunysb.edu/cmalone/nolink/backtrace.txt


PS: I had already written most of this before I just saw your email -
hopefully this helps...

Chris



On Tue, Feb 22, 2011 at 10:06 AM, Chris Malone <chris.m.malone@gmail.com>wrote:

> Hi Eric,
>
> I removed all the compiled elisp files, and the problem still persists.
> Next step will be a completely fresh install from git; my current version is
> up to date, but maybe there was some conflict that git didn't complain
> about...
>
> Chris
>
>
> On Mon, Feb 21, 2011 at 2:48 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>
>> Chris Malone <chris.m.malone@gmail.com> writes:
>> [...]
>> >
>> > 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.
>> >
>>
>> Hmm, it may be worth cleaning out all compiled .elc files from within
>> Org-mode, the calling org-reload, and see if the problem persists.
>>
>> Best -- Eric
>>
>> >
>> > Chris
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 11292 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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Eric Schulte]

Chris Malone <chris.m.malone@gmail.com> writes:

> Ok, this is still perplexing me, as I have a new version from git and I
> still get the error.  The following is complete list (sorry for the long
> email!) of what I have done:
>
> * Get a fresh copy of =org-mode= from git and byte-compile:
>
> #+begin_src: sh
>   cd ~/install/org-mode
>   mkdir new_git_clone
>   cd new_git_clone
>   git clone git://orgmode.org/org-mode.git
>   cd org-mode; make &> make.out
>   ln -s ~/install/org-mode/new_git_clone/org-mode ~/install/org-mode/current
> #+end_src
>

if you are worried that you don't have the correct version of Org-mode
installed you can check the output of the `org-version' function.  Mine
reads

"Org-mode version 7.4 (release_7.4.510.g1e35)"

>
> During the =make= process, I noticed quite a few warnings.  An example is
> below (for a complete copy of =make.out=, see
> http://astro.sunysb.edu/cmalone/nolink/make.out
[...]
> Are such warnings normal?
>

yes, these are normal compiler warnings which are generally cleaned up
before releases but shouldn't have any negative impact on the behavior
of Org-mode

>
> * Make sure my =.emacs= file is pointing to the correct location
> Here is a copy of the =org-mode=-relevant sections of my =.emacs= file:
>
[...]
>
> * Attempt an export of the =org-mode= file found here:
> http://astro.sunysb.edu/cmalone/nolink/python_class_lstings.org
>

One thing to note here, is that for your emacs-lisp block to work on
export, you need to change this

#+begin_src emacs-lisp :exports both
  (buffer-file-name)
#+end_src

to this

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

because only header arguments are guaranteed to be evaluated in the
original org-mode buffer during export.

That said I was able to export your example file (without the change
above) to html.  When exporting to latex I ran into an issue, the
problem here is that the LaTeX exporter *requires* at least one
headline.  It explicitly export the pre-first-headline and
post-first-headline portions of the Org-mode buffer separately.  When
there is no headline, and the buffer contains code blocks, then they are
exported *twice*, which causes the error you mentioned, because after
the first pass of the code-block export, the results in the file are not
valid for another pass of the exporter.

If you place a "* " before the "Let's start this..." line, then the
errors should disappear.

Hope this helps.

Best -- Eric

Re: Re: Two questions about using a =#+begin_src emacs-lisp= block

[chris.m.malone]

[-- Attachment #1.1: Type: text/plain, Size: 3193 bytes --]

On Feb 22, 2011 1:06pm, Eric Schulte <schulte.eric@gmail.com> wrote:
> Chris Malone chris.m.malone@gmail.com> writes:



> > Ok, this is still perplexing me, as I have a new version from git and I

> > still get the error. The following is complete list (sorry for the long

> > email!) of what I have done:

> >

> > * Get a fresh copy of =org-mode= from git and byte-compile:

> >

> > #+begin_src: sh

> > cd ~/install/org-mode

> > mkdir new_git_clone

> > cd new_git_clone

> > git clone git://orgmode.org/org-mode.git

> > cd org-mode; make &> make.out

> > ln -s ~/install/org-mode/new_git_clone/org-mode  
> ~/install/org-mode/current

> > #+end_src

> >



> if you are worried that you don't have the correct version of Org-mode

> installed you can check the output of the `org-version' function. Mine

> reads



> "Org-mode version 7.4 (release_7.4.510.g1e35)"



RIght - I was worried that I had possibly changed a lisp file that could be  
causing the error, so I wanted a fresh copy.

> >

> > During the =make= process, I noticed quite a few warnings. An example is

> > below (for a complete copy of =make.out=, see

> > http://astro.sunysb.edu/cmalone/nolink/make.out

> [...]

> > Are such warnings normal?

> >



> yes, these are normal compiler warnings which are generally cleaned up

> before releases but shouldn't have any negative impact on the behavior

> of Org-mode



Ok, good to know.


> >

> > * Make sure my =.emacs= file is pointing to the correct location

> > Here is a copy of the =org-mode=-relevant sections of my =.emacs= file:

> >

> [...]

> >

> > * Attempt an export of the =org-mode= file found here:

> > http://astro.sunysb.edu/cmalone/nolink/python_class_lstings.org

> >



> One thing to note here, is that for your emacs-lisp block to work on

> export, you need to change this



> #+begin_src emacs-lisp :exports both

> (buffer-file-name)

> #+end_src



> to this



> #+begin_src emacs-lisp :var file-name=(buffer-file-name) :exports both

> file-name

> #+end_src



> because only header arguments are guaranteed to be evaluated in the

> original org-mode buffer during export.



Again, thanks for pointing this out earlier. I hadn't changed it for the  
example, because the error was not associated with whether or not the  
actual =emacs-lisp= code returned anything meaningful.



> That said I was able to export your example file (without the change

> above) to html. When exporting to latex I ran into an issue, the

> problem here is that the LaTeX exporter *requires* at least one

> headline. It explicitly export the pre-first-headline and

> post-first-headline portions of the Org-mode buffer separately. When

> there is no headline, and the buffer contains code blocks, then they are

> exported *twice*, which causes the error you mentioned, because after

> the first pass of the code-block export, the results in the file are not

> valid for another pass of the exporter.



> If you place a "* " before the "Let's start this..." line, then the

> errors should disappear.



> Hope this helps.



> Best -- Eric

That fixed it! Sorry for the trouble for something that seems so minor!  
Thanks again.

Chris

[-- Attachment #1.2: Type: text/html, Size: 4848 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

Re: Two questions about using a =#+begin_src emacs-lisp= block

[Achim Gratz]

"Eric Schulte" <schulte.eric@gmail.com> writes:
> if you are worried that you don't have the correct version of Org-mode
> installed you can check the output of the `org-version' function.  Mine
> reads
>
> "Org-mode version 7.4 (release_7.4.510.g1e35)"

Note: the SHA1 for the git commit is only shown if Orgmode is installed into a
subdirectory of the git working tree.  I remember that this puzzled me
at the beginning...  After a few tries I've now set up as follows:

 - I'm tracking two branches local-maint->origin/maint (latest release)
   local->origin/master (developer version) with rebase and just add a
   single commit on top with customizations to the Makefile to get the
   install for each branch to the correct location
 
 - the latest release version is installed into .../site-lisp/orgmode/
   and is the version that gets used when I "just" start emacs

 - in the git working tree I'm installing the latest developer snapshot
   into a subdirectory dev-lisp; always compile via

   make clean install && make clean

   otherwise emacs might pick up byte-compiled files even though you've
   changed the sources (by checking out another branch or doing a git
   pull or just editing something)

 - keep a file handy with:

--8<---------------cut here---------------start------------->8---
;; -*- lisp-interaction -*-
(setq load-path (cons (expand-file-name "~/org-mode/lisp") load-path))
(setq load-path (cons (expand-file-name "~/org-mode/dev-lisp") load-path))

(setq load-path (cdr load-path))
--8<---------------cut here---------------end--------------->8---

   load this into emacs and do C-j on one of the first two lines to
   switch to using either the compiled or uncompiled developer version.
   The last lines strips the load-path of the first element, which
   switches back to the "standard" load-path provided you didn't do any
   other additions to load-path inbetween.

This is obviously customizable in several respects, but it works for me
and lets me track several stages of orgmode development with minimal
effort.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada