* Two questions about using a =#+begin_src emacs-lisp= block
@ 2011-02-20 22:08 Chris Malone
2011-02-21 17:17 ` Eric Schulte
0 siblings, 1 reply; 12+ messages in thread
From: Chris Malone @ 2011-02-20 22:08 UTC (permalink / raw)
To: emacs-orgmode
[-- 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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Two questions about using a =#+begin_src emacs-lisp= block 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 2011-02-21 22:19 ` Dan Davison 0 siblings, 2 replies; 12+ messages in thread From: Eric Schulte @ 2011-02-21 17:17 UTC (permalink / raw) To: Chris Malone; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-21 17:17 ` Eric Schulte @ 2011-02-21 18:31 ` Chris Malone 2011-02-21 19:48 ` Eric Schulte 2011-02-21 22:19 ` Dan Davison 1 sibling, 1 reply; 12+ messages in thread From: Chris Malone @ 2011-02-21 18:31 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-21 18:31 ` Chris Malone @ 2011-02-21 19:48 ` Eric Schulte 2011-02-22 15:06 ` Chris Malone 0 siblings, 1 reply; 12+ messages in thread From: Eric Schulte @ 2011-02-21 19:48 UTC (permalink / raw) To: Chris Malone; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 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 0 siblings, 2 replies; 12+ messages in thread From: Chris Malone @ 2011-02-22 15:06 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-22 15:06 ` Chris Malone @ 2011-02-22 16:54 ` Eric Schulte 2011-02-22 16:57 ` Chris Malone 1 sibling, 0 replies; 12+ messages in thread From: Eric Schulte @ 2011-02-22 16:54 UTC (permalink / raw) To: Chris Malone; +Cc: emacs-orgmode 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 >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 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 1 sibling, 1 reply; 12+ messages in thread From: Chris Malone @ 2011-02-22 16:57 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 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 0 siblings, 2 replies; 12+ messages in thread From: Eric Schulte @ 2011-02-22 18:06 UTC (permalink / raw) To: Chris Malone; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-22 18:06 ` Eric Schulte @ 2011-02-22 18:23 ` chris.m.malone 2011-02-22 18:45 ` Achim Gratz 1 sibling, 0 replies; 12+ messages in thread From: chris.m.malone @ 2011-02-22 18:23 UTC (permalink / raw) To: Eric Schulte, Chris Malone; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-22 18:06 ` Eric Schulte 2011-02-22 18:23 ` chris.m.malone @ 2011-02-22 18:45 ` Achim Gratz 1 sibling, 0 replies; 12+ messages in thread From: Achim Gratz @ 2011-02-22 18:45 UTC (permalink / raw) To: emacs-orgmode "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-21 17:17 ` Eric Schulte 2011-02-21 18:31 ` Chris Malone @ 2011-02-21 22:19 ` Dan Davison 2011-02-21 22:34 ` Eric Schulte 1 sibling, 1 reply; 12+ messages in thread From: Dan Davison @ 2011-02-21 22:19 UTC (permalink / raw) To: Eric Schulte; +Cc: Chris Malone, emacs-orgmode "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Two questions about using a =#+begin_src emacs-lisp= block 2011-02-21 22:19 ` Dan Davison @ 2011-02-21 22:34 ` Eric Schulte 0 siblings, 0 replies; 12+ messages in thread From: Eric Schulte @ 2011-02-21 22:34 UTC (permalink / raw) To: Dan Davison; +Cc: Chris Malone, emacs-orgmode [...] >> >> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-02-22 18:45 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).