Re: Re: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
On Feb 22, 2011 1:06pm, Eric Schulte 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 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: [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 "") '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 wrote:
> Hi Eric,
>
> I r
Re: [Orgmode] Two questions about using a =#+begin_src emacs-lisp= block
Chris Malone 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 wrote: > >> Chris Malone 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
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 wrote: > Chris Malone 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 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
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
___
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 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
