Re: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
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.e...@gmail.comwrote: Chris Malone chris.m.mal...@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 ___ 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: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
Chris Malone chris.m.mal...@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.e...@gmail.comwrote: Chris Malone chris.m.mal...@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 ___ 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: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
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.mal...@gmail.comwrote:
Hi Eric,
I removed all the
Re: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
Chris Malone chris.m.mal...@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 ___ 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: Re: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
On Feb 22, 2011 1:06pm, Eric Schulte schulte.e...@gmail.com wrote: Chris Malone chris.m.mal...@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 ___ 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: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
Chris Malone chris.m.mal...@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
___
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: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
On Mon, Feb 21, 2011 at 12:17 PM, Eric Schulte schulte.e...@gmail.comwrote:
Chris Malone chris.m.mal...@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
___
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: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
Chris Malone chris.m.mal...@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 ___ 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
[Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
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
___
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
