Re: [O] [PATCH] new babel latex feature :imagemagick
FSF papers are signed and the process is completed - so the revert can be reverted now (the patch should still apply). Sorry for the long delay...
[O] [babel] speed of continued source blocks
Hi all, there is a significant performance drop connected to (the quite old) commit 8c37281cb63a0b5cb0d84d22960e3a33d7680d40 ob-tangle: continued code blocks now implemented with the :noweb-ref header arg which introduces the continued code blocks. On the test file ([fn:1] for the old syntax, [fn:2] for the new syntax) do org-babel-expand-src-block (C-c C-v v) on the first source code block to see the effect. Just before this commit I get instantaneous reaction (elp: [fn:3]), with the commit I have to wait about 20 seconds (elp: [fn:4]) Recently things improved a bit, but still it takes about 10 seconds to expand the source block (elp: [fn:5]). Since working interactively with the (R-)code in the org-file is impossible this way, here comes my question: Is it possible to either (a) speed up the continued source blocks or (b) make the continued code blocks an optional feature in order to improve the performance to the previous state again? I'd be happy with solution (b), but unfortunately, it is beyond my elisp to do so. Any help highly appreciated, Andreas [fn:1] test file with old syntax: http://pastebin.com/aL9axJMJ [fn:2] test file with new syntax: http://pastebin.com/c42jS1Be [fn:3] elp result last good commit: org-babel-expand-src-block1 0.853276 0.853276 org-edit-src-code 1 0.58143 0.58143 org-entry-get 2220 0.469903 0.0002116684 org-babel-edit-prep:R 1 0.46897 0.46897 org-babel-R-initiate-session 1 0.468958 0.468958 org-babel-expand-noweb-references 5 0.340635 0.068127 org-babel-get-src-block-info 7 0.32633 0.0466185714 org-babel-parse-src-block-match 7 0.325632 0.046518 org-babel-params-from-properties 7 0.311787 0.044541 org-entry-get-with-inheritance518 0.308870 0.0005962760 org-up-heading-safe 1702 0.088341 5.190...e-05 org-get-property-block1702 0.084672 4.974...e-05 org-back-to-heading 3404 0.062372 1.832...e-05 org-edit-src-find-region-and-lang 1 0.052575 0.052575 org-before-first-heading-p2220 0.026047 1.173...e-05 org-babel-params-from-buffer 7 0.011711 0.001673 org-outline-level 2886 0.004712 1.632...e-06 org-babel-find-named-block4 0.003625 0.00090625 org-babel-merge-params29 0.001489 5.137...e-05 org-babel-parse-header-arguments 28 0.00076 2.714...e-05 org-babel-where-is-src-block-head 7 0.000354 5.057...e-05 org-do-remove-indentation 8 0.000321 4.024...e-05 org-not-nil 518 0.000262 5.077...e-07 org-babel-read30 0.000171 5.700...e-06 org-uniquify 96 0.000161 1.687...e-06 org-src-switch-to-buffer 1 0.000161 0.000161 org-switch-to-buffer-other-window 1 0.000153 0.000153 org-edit-src-find-buffer 1 0.00014 0.00014 org-mode-flyspell-verify 1 0.000123 0.000123 org-babel-trim4 8.999...e-05 2.249...e-05 org-make-options-regexp 28 7.900...e-05 2.821...e-06 org-babel-chomp 38 6.899...e-05 1.815...e-06 org-babel-strip-protective-commas 7 6.000...e-05 8.571...e-06 org-edit-src-get-indentation 1 5.4e-05 5.4e-05 org-babel-number-p30 5.000...e-05 1.666...e-06 org-get-indentation 1 4.6e-05 4.6e-05 org-babel-process-params
Re: [O] [babel] speed of continued source blocks
Hi Eric, thanks for looking into this providing a patch already! I've just pushed up a patch which should speed up the collection of continued source blocks. Please let me know if the performance increase is sufficient for your example, if not we can look at more dramatic methods of optimization or possibly at making the collection of such blocks conditional. The speed looks very good already! But now org-babel-expand-src-block (as well es the source block evaluation) seems not to expand the noweb references at all and more. Is that a problem only on my side? One option to avoid this overhead could be to add the following #+PROPERTY: noweb no to the top of your Org-mode file. Since I heavily rely on the noweb references, this is not an option for me. Cheers, Andreas
Re: [O] [babel] speed of continued source blocks
Hi Eric, Eric Schulte eric.schu...@gmx.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, thanks for looking into this providing a patch already! I've just pushed up a patch which should speed up the collection of continued source blocks. Please let me know if the performance increase is sufficient for your example, if not we can look at more dramatic methods of optimization or possibly at making the collection of such blocks conditional. The speed looks very good already! Great, unless I hear back I'll assume this issue is resolved. Thanks for the stress testing. But now org-babel-expand-src-block (as well es the source block evaluation) seems not to expand the noweb references at all and more. Is that a problem only on my side? Thanks for catching this, I was only testing :noweb-ref references, not named code block references. I've just fixed this issue and added an exercising test case so this won't happen in the future. Please let me know if any problems remain. Cheers, One option to avoid this overhead could be to add the following #+PROPERTY: noweb no to the top of your Org-mode file. Since I heavily rely on the noweb references, this is not an option for me. Cheers, Andreas thanks a lot! Works great now. Cheers, Andreas
Re: [O] Problem with noweb-ref property
Tomas Grigera tgrig...@gmail.com writes: Hi Eric, Thanks a lot for your quick reply and fix. Getting the git repo version scares me a bit, but I guess I'll just have to take the plunge! Here we go :) Thanks again, Tomas On Thu, Dec 29, 2011 at 16:51, Eric Schulte eric.schu...@gmx.com wrote: Tomas Grigera tgrig...@gmail.com writes: Hi list, This is my first post, so just let me say first that I have been using org-mode for 10 months or so and I love it. It's an exceptional package, and before I ask my question I would just like to thank Carsten, Bastien, and the community for the great work and for sharing. Now my question: I am trying to extract code from a .org file by tangling with noweb-style references. As I understand from the manual, if I write foo in a code block, the line will be expanded with the code block named foo. This name I can set with #+NAME: or with the :noweb-ref header argument. Both ways work for me, except that I cannont set the :noweb-ref argument through a property. The following example is almost verbatim from the manual: #+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh fullest-disk #+END_SRC * the mount point of the fullest disk ** query all mounted disks #+HEADER: :noweb-ref fullest-disk #+BEGIN_SRC sh df \ #+END_SRC ** strip the header row :PROPERTIES: :noweb-ref: fullest-disk :END: #+BEGIN_SRC sh :noweb yes |sed '1d' \ #+END_SRC If I understand correctly, tangling should produce a file which is a concatenation of the two code blocks. However, when I do org-babel-tangle, only the first block is inserted. Am I doing something wrong? I'm with emacs 23.2.1 and org-mode 7.8.02 Thanks in advance, Tomas Hi Tomas, You are correct the behavior described above is a bug introduced by a fairly recent commit of mine which switched to using regular expressions when resolving noweb references in an attempt to decrease the time required to tangle code blocks (which can be significant in large code blocks). However correct performance is more important than fast performance. I've just pushed up a patch which fixes the bug you've described, and hopefully doesn't slow down the tangling process too significantly. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte/ Hi Eric, unfortunately, for me it does result in a considerably slow down. (Well, I did not bisect this time but still suspect the commit you mention in this thread.) As a test case you can still use http://pastebin.com/c42jS1Be from my last post on this matter and expand the first source block. Sorry to ask again: Would it be possible to speed things up again or to make the :noweb-ref feature optional? Regards, Andreas
Re: [O] Problem with noweb-ref property
Eric Schulte eric.schu...@gmx.com writes: However correct performance is more important than fast performance. I've just pushed up a patch which fixes the bug you've described, and hopefully doesn't slow down the tangling process too significantly. Hi Eric, unfortunately, for me it does result in a considerably slow down. (Well, I did not bisect this time but still suspect the commit you mention in this thread.) As a test case you can still use http://pastebin.com/c42jS1Be from my last post on this matter and expand the first source block. Sorry to ask again: Would it be possible to speed things up again or to make the :noweb-ref feature optional? Hi Andreas, I've just pushed up a new variable to the git repository. To enable the faster regexp-based method of noweb expansion (which is not able to resolve noweb-ref header arguments inherited from sub-tree or file-wide properties) put the following in your config. (setq *org-babel-use-quick-and-dirty-noweb-expansion* t) Best, Hi Eric, thanks for this quick-and-dirty fix ;-) Works great! Cheers, Andreas
Re: [O] :noweb header argument
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: [...] I think it might be good to have a parameter that expands noweb references on evaluation and tangling, but leaves them alone during export. This way the code block would be fully functional, but wouldn't duplicate code during export (when the noweb references are to other code blocks in the same document). I'd find that interesting as well, but then the names of the code blocks must be visible again (in HTML and PDF exports), something that has disappeared over time. +1 for both 1) the :noweb no-export or similar 2) and the possibility to include source block names in export - Andreas
[O] S-tab in source blocks
Hi all, is it possible to make S-tab call the global org-cycle when the point is in a source block? Best, Andreas
Re: [O] S-tab in source blocks
Bernt Hansen be...@norang.ca writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: is it possible to make S-tab call the global org-cycle when the point is in a source block? Yes, (setq org-src-tab-acts-natively nil) Regards, Bernt Hi Bernt, thanks. But that disables tab as well. So to clarify: I am looking for native tab and S-tab calling the globel org-cycle. Cheers, Andreas
Re: [O] inline src_R also in latex src block
Michael Bach pha...@gmail.com writes:
Eric Schulte eric.schu...@gmx.com writes:
I don't know of a way to evaluate inline code blocks which are already
inside of regular code blocks.
Thanks for your thoughts on this, Eric. This would be *really*
convenient for me. Too bad the christmas wishlist was processed
already.
You could try direct begin_latex code blocks, but in-buffer font lock
support may simply not be possible in this situation.
Sadly, direct begin_latex code blocks get fontified with `org-block' and
also export the inline `src_R' snippets literally.
What I was looking for is latex code fontified as AUCTeX and inline
`src_R' snippets evaluated prior to exporting. The only working
combination I got right now is inline `src_R' evaluation and no AUCTeX
font-lock. This is only a minor itch and not too bad considering what
org-mode already does for me.
Best Regards,
Michael
Hi Michael,
would this noweb-based approach work for you:
#+name: inner_test
#+begin_src R
4 + 4
#+end_src
#+name: test
#+begin_src latex :noweb yes
\begin{equation}
inner_test()
\end{equation}
#+end_src
Cheers,
Andreas
Re: [O] inline src_R also in latex src block
Michael Bach pha...@gmail.com writes:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
would this noweb-based approach work for you:
#+name: inner_test
#+begin_src R
4 + 4
#+end_src
#+name: test
#+begin_src latex :noweb yes
\begin{equation}
inner_test()
\end{equation}
#+end_src
Yes, that works. Thanks for your thoughts on this, Andreas.
I am just thinking of another benefit: Is it correct that I can use
caching with this approach? So that the call to inner_test() does
not evaluate the `inner_test' block but instead takes its results
directly from the cached `#+results[6099...]: inner_test' block? This
would be speedier than src_R usage...
yes, that should work. Try to export the following several times. The
first number should not change.
(note: maybe you'd have to execute the inner_test_cached once on your
system)
#+name: inner_test_cached
#+begin_src R :cache yes :exports none
rnorm(1)
#+end_src
#+results[dbeb7280be41fdc949815808cf601a6d01a400bb]: inner_test_cached
: 1.12399967834262
#+name: inner_test_not_cached
#+begin_src R :exports none
rnorm(1)
#+end_src
#+results: inner_test_not_cached
: -0.562660468468834
#+name: test
#+begin_src latex :noweb yes
\begin{equation}
inner_test_cached()
!=
inner_test_not_cached()
\end{equation}
#+end_src
Cheers,
Andreas
[O] capture inside org-edit-src-code buffer
Hi all, I'd like to be able to call capture such that the captured item is stored under '* Notes' in the current org-file *from inside an org-edit-src-code buffer*. Preferably, I'd like a single capture template, that works (1) on the current org file normally (2) on the parent org file after doing C-' on a source block A possible capture template for (1) looks like this: (w currentfile entry (file+headline (buffer-file-name) Notes) ) How would I extend this to (2)? Optimally, this template would record the #+name tag of the source block under the point (if the point is in a source block) in (1) or the source block being edited in (2), if such #name tag exists. Thanks for hints, Andreas
Re: [O] Org-edit-special and C-x C-s strange behavior
Eric S Fraga e.fr...@ucl.ac.uk writes: Leo Alekseyev dnqu...@gmail.com writes: I often edit my org-babel code blocks via org-edit-special (C-'), in part because I find the tabbing behavior within the code blocks to be somewhat flaky. Inevitably, when editing the code block I will press C-x C-s (muscle memory). This causes all sorts of annoying consequences: the buffer with the code block gets buried, window [...] What version of org are you using? I ask because I used to experience the annoyance you describe a while back; more recently (since at least a few months ago), hitting C-x C-s no longer has any negative impact: it saves the file, or at least appears to. You still have to C-c ' to get back to the full buffer, mind you, but that's better, IMO, than changing the behaviour of such a fundamental key binding as C-x C-s. I am not sure, I understand this. I do also experience the same behaviour as the OP since some time (weeks, I guess). Hitting C-x C-s in the org-edit-special buffer still saves the org file, but the org-edit-special buffer gets buried. Cheers, Andreas
Re: [O] Org-edit-special and C-x C-s strange behavior
Eric S Fraga e.fr...@ucl.ac.uk writes: Leo Alekseyev dnqu...@gmail.com writes: Eric S Fraga e.fr...@ucl.ac.uk writes: What version of org are you using? I ask because I used to experience the annoyance you describe a while back; more recently (since at least a few months ago), hitting C-x C-s no longer has any negative impact: it saves the file, or at least appears to. You still have to C-c ' to get back to the full buffer, mind you, but that's better, IMO, than changing the behaviour of such a fundamental key binding as C-x C-s. It appears that this bug is Emacs-version dependent: it functions as you describe with 23.2, but the buffer gets buried (with an error message basic-save-buffer: Wrong type argument: stringp, nil) in 24.0.92. Org mode is the current git HEAD. I tried to step through basic-save-buffer in edebug, but I couldn't catch the error (I'm not very experienced with edebug). Can someone test this on Emacs 24 and confirm what I'm seeing? I am using 24.0.92 and I have no problems at all (just tried right now). One difference, however, could be the window configurations we use. Specifically, I have (setq org-src-window-setup (quote current-window)) in my configuration: the special editing window replaces the current window entirely. When I hit C-x C-s, the buffer is saved but nothing changes (nothing is buried, etc.). Maybe you have the default configuration which is to reorganize-frame and maybe that is where the problem is? Thanks for this Eric! I can confirm, that the problem does not occur with this setting here, too (emacs 24.0.92 as well).
[O] [babel] org mode tables and tangling
Hi all, What is the suggested way to use org mode tables in connection with tangling? Example: If I tangle this org mode file /org-file=\ | * org-tables and reproducibility | | #+name: params | | | number | param | | | |+---| | | | 0 | 1 | | | | 1 | 1 | | | | | #+begin_src R :var params=params :tangle test.R | | apply(params, 1, print) | | #+end_src | \/org-file/ the tangled file looks like /test.R===\ | params - read.table(/tmp/babel-19196cip/R-import-19196ILE, | |header=TRUE, row.names=NULL, sep=\t, as.is=TRUE) | | attach(params)| | apply(params, 1, print) | \/test.R==/ which depends on a temporary file. I could distribute that along with the tangled file, of course. But I'd like a distributable, ideally self-contained version, that my co-workers can work with. Something like this, maybe: /sample.R===\ | # generated with R dput()...| | babel_tmp_1238h098 - structure(list(means = 0:1, sds = c(1L, 1L)), | | .Names = c(means, sds), | | class = data.frame, | | row.names = c(NA, -2L)) | | params - dget(textConnection(babel_tmp_1238h098, r)) | \/sample.R==/ Is such a mode of tangling already available for R? Best, Andreas
[O] latex export of #+header: lines
Hi all,
I am experiencing a problem with the latex exporter: #+header: lines
are visible in the exported file.
Example:
/==\
* test header tag
#+caption: foo
#+label: fig:fig1
#+name: foo
#+header: :file foo.png
#+header: :width 3600 :height 3600 :res 600
#+begin_src R :exports results :results graphics
plot(1:10, 1:10)
#+end_src
\==/
Results (LaTeX):
/=\
\section{test header tag}
\label{sec-1}
\#+header: :file foo.png
\#+header: :width 3600 :height 3600 :res 600
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{foo.png}
\caption{\label{fig:fig1}foo}
\end{figure}
\=/
The header arguments seem to take their effect, though.
Regards,
Andreas
Re: [O] latex export of #+header: lines
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb Hi Seb, thanks for the reply! But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. Best, Andreas
Re: [O] latex export of #+header: lines
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb Hi Seb, thanks for the reply! But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. Best, Andreas Just tried, and the odt export has them as well. Maybe a problem on my test file? Or is the #+header(s): tag somehow deprecated? - Andreas
[O] [ODT] image scaling overridden by long caption
Hi all, I experience unexpected behaviour with the excellent odt exporter in case of included images. When I add a #+caption the text width of that caption overrides the specified image width (#ATTR_ODT: :witdh X), which I use to downscale the image in the odt. Especially if that caption will span across multiple lines, that effect is visible. Here is the example: --- * odt image test #+caption: foo #+ATTR_ODT: :width 8 #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src #+caption: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo #+ATTR_ODT: :width 8 #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src - I'd expect the image scaling to take place in either case. Maybe even the caption should wrap at the specified width. On a related note: Could I place two (correctly scaled) images side-by-side? Regards, Andreas
Re: [O] latex export of #+header: lines
Jambunathan K kjambunat...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb Hi Seb, thanks for the reply! But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. Best, Andreas Just tried, and the odt export has them as well. Maybe a problem on my test file? Or is the #+header(s): tag somehow deprecated? If you remove the indentation of #+header: line (and thereby force it to start at column 0) you will see that (atleast) the ODT export doesn't have the header lines. I think the problem is not with the latex or odt backends as such but in the export pre-processor. Hi Jambunathan, thanks for this work-around with the removal of the indentation. Works for #+ATTR_ODT: in the LaTeX export as well. Cheers, Andreas
Re: [O] [ODT] image scaling overridden by long caption
Jambunathan K kjambunat...@gmail.com writes: Hello Andreas Hi all, I experience unexpected behaviour with the excellent odt exporter in case of included images. When I add a #+caption the text width of that caption overrides the specified image width (#ATTR_ODT: :witdh X), which I use to downscale the image in the odt. Especially if that caption will span across multiple lines, that effect is visible. Here is the example: --- * odt image test #+caption: foo #+ATTR_ODT: :width 8 #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src #+caption: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo #+ATTR_ODT: :width 8 #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src - I'd expect the image scaling to take place in either case. Maybe even the caption should wrap at the specified width. I have pushed a fix for this. Hope the new behaviour is according to your expectation. Thanks a lot, this works fine now! But I experienced another issue with respect to images scaling in the odt export: This subtree: test.org == * Test image scaling in odt #+caption: bar #+label: fig:bar #+name: bar #+attr_odt: :width 8 #+header: :file bar.png #+header: :width 7200 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src #+caption: baz #+label: fig:baz #+name: baz #+attr_odt: :scale 0.5 #+header: :file baz.png #+header: :width 7200 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src == exports to this: http://i.imgur.com/sUHQi.png on my system. On a related note: Could I place two (correctly scaled) images side-by-side? For the sake of record, your request is much similar to what is discussed here http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html - save for (dynamically-generated) images taking the place of src blocks. Try something like this: #+begin_list-table - [[./foo1.png]] - [[./foo2.png]] #+end_list-table Make sure that the images are small images. If you replace the image links above with R srcblocks or attach caption/attr_odt to the above above images, the results are less than satisfactory. So the answer to your question is a soft no. Thanks for this. For two reasons that does not work for me: (1) I want to use captions on my images (2) it is odt-export specific Notes to self: There are multiple ways to achieve side-by-side effect. - use tables (aka list tables) - use 2-Column sections - 2-column frames (what is this?) side-by-side has surfaced in the list for the second time, I think it deserves to be supported out of the box. +1. And ideally generic enough, s.t. also the LaTeX supports it. Beamer has the concept of columns, which is nicely supported in org mode. Maybe that could be a general concept supported by all (or, most) exporters? - Andreas Jambunathan K.
[O] \ref{} in #+caption
Hi all,
is it possible to get \ref{} to work in #+caption lines generally? As
it seems, the #+caption is not processed. So the \ref{} statements in
#+captions work only in LaTeX export, where \ref{} is valid. In the
#other exports, the \ref{} is exported literally.
Example:
=== test.org =
* Test ref in caption
#+caption: bar referencing \ref{fig:baz}
#+label: fig:bar
#+name: bar
#+attr_odt: :width 8
#+header: :file bar.png
#+header: :width 7200 :height 3600 :res 600
#+begin_src R :exports results :results graphics
plot(1:10, 1:10)
#+end_src
#+caption: baz
#+label: fig:baz
#+name: baz
#+attr_odt: :scale 0.5
#+header: :file baz.png
#+header: :width 7200 :height 3600 :res 600
#+begin_src R :exports results :results graphics
plot(1:10, 1:10)
#+end_src
==
Best,
Andreas
[O] Inconsistency in odt export to other exporters
Hi all,
there is an inconsistency of the odt exporter compared to the LaTeX and
the html export.
The following snippet exports correctly to LaTeX and to html, but
produces the text Figure Figure in odt.
Could the behaviour be synchronized?
=== example.org ==
* Test ref
#+caption: bar
#+label: fig:bar
#+name: bar
#+attr_odt: :width 8
#+header: :file bar.png
#+header: :width 7200 :height 3600 :res 600
#+begin_src R :exports results :results graphics
plot(1:10, 1:10)
#+end_src
Here is a reference to Figure \ref{fig:bar}
==
Best,
Andreas
Re: [O] Inconsistency in odt export to other exporters
Jambunathan K kjambunat...@gmail.com writes: The following snippet exports correctly to LaTeX and to html, but produces the text Figure Figure in odt. Fixed. Works great for me, thanks! And thanks for all these fast responses! Best, Andreas
Re: [O] [bug] Tables in lists not exported to ODT
Jambunathan K kjambunat...@gmail.com writes: Jambunathan K kjambunat...@gmail.com writes: Btw, I was trying to make the tables cute-looking Just pushed a fix whereby one can control the width of the tables. , commit f9d242 | Customize table width using :rel-width option. For example, to create a | table of width 60% use: | | #+attr_odt: :rel-width 60 | | | A | B | | |---+---| | | | | ` Thanks for this very useful feature. Works nicely for me. - Andreas
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
[...]
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
Sorry for hijacking this thread. But this side note is only valid for
the new exporter, correct? As it does not yield the expected result in
the current LaTeX and odt exporter (the only ones I tried).
== test.org ===
* Test name
#+caption: Test name
#+name: testname
#+begin_src R :exports results :results graphics :file foo.png
plot(1)
#+end_src
As can be seen in Figure \ref{testname}...
As can be seen in Figure [[testname]]
#+caption: Test name 2
#+label: testnametwo
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnametwo}...
As can be seen in Figure [[testnametwo]]
#+caption: Test name 3
#+label: testnamethree
#+name: testnamethree
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnamethree}...
As can be seen in Figure [[testnamethree]]
===
Best,
Andreas
Re: [O] [BUG] Inconsistency in src block hiding
Eric Schulte eric.schu...@gmx.com writes: [...] To my mind a better path moving forward would be to change the behavior of the :RESULTS: drawer so that it is exported but *not* to change the default drawer export behavior. This way with a :wrap header argument the code block results could be hidden with tab but would still be exported. PRO: allows hiding code block results with tab, makes it clear where results begin and end, uses drawers for hiding which is what they are designed for, avoids the potential for hiding anything with a name CON: more syntactic weight around results, changes the existing default behavior, makes the RESULTS drawer a special type of drawer There is likely a better option but this is the best that comes to mind. Personally I am also content with the current behavior in which anything under a #+name: may be hidden. Coming late to this thread, I just want to say, that I am on the PRO side for special results drawers. The fact that org mode uses drawers for wrapping results is an internal/technical choice that - I think - the user should not need to know. In the current state, in case the user switches result wrapping on, the results block disappears from the export, until the user has figured out, that exporting drawers has to be enabled now (with all drawers being exported...). So, I think, there *is* a difference between drawers as used in other places and drawers used for results, which are imposed onto the user by org mode. Thus, the CON just reflects this difference and is no real CON. Just my two cents. - Andreas
[O] [babel] BUG in inline source blocks
Hi all,
I experience unexpected behaviour when an inline source block is not
preceded by whitespace.
Example:
===
* Test inline
This is a functional inline src_R{print(source block)}.
This (src_R{print(here)}) is not.
===
Regards,
Andreas
[O] org mode in press
Hi all, this just came into my inbox: http://www.jstatsoft.org/v46/i03 Great work! Big thanks to the authors. - Andreas
Re: [O] [babel][patch] BUG in inline source blocks
Martyn Jago martyn.j...@btinternet.com writes:
Martyn Jago martyn.j...@btinternet.com writes:
Hi,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi all,
I experience unexpected behaviour when an inline source block is not
preceded by whitespace.
Example:
===
* Test inline
This is a functional inline src_R{print(source block)}.
This (src_R{print(here)}) is not.
===
Regards,
Andreas
I can confirm this behaviour and provide a patch to allow for inline
source blocks to be preceded by punctuation, or, for instance, enclosed
in parenthesis, as in Andreas' example. Patch is attached for
consideration.
Best, Martyn
This is an updated version of the previous patch, with debug noise
removed, and a couple of extra tests.
Best, Martyn
Hi Martyn,
thanks for this patch! It does half the job for me. Now export (or
evaluation) already work. But in the export I get a space inserted.
I my example, I'd expect (here) to appear in the export, but I get ( here).
Best,
Andreas
Re: [O] [ODT] image scaling overridden by long caption
Jambunathan K kjambunat...@gmail.com writes: Hi Jambunathan, thanks for looking into this. Answer to your questions below Hello Andreas Andreas Leha andreas.l...@med.uni-goettingen.de writes: But I experienced another issue with respect to images scaling in the odt export: This subtree: test.org == * Test image scaling in odt #+caption: bar #+label: fig:bar #+name: bar #+attr_odt: :width 8 #+header: :file bar.png #+header: :width 7200 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src #+caption: baz #+label: fig:baz #+name: baz #+attr_odt: :scale 0.5 #+header: :file baz.png #+header: :width 7200 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src == exports to this: http://i.imgur.com/sUHQi.png on my system. I am on a Netbook and I am unable to create big images. This is the following error I get when export the above snippet. , *Org-Babel Error Output* | Error in png(filename = baz.png, height = 3600, res = 600, width = 7200) : | unable to start device | Calls: Anonymous - Anonymous - png - .External | In addition: Warning messages: | 1: In png(filename = baz.png, height = 3600, res = 600, width = 7200) : | Unable to allocate bitmap | 2: In png(filename = baz.png, height = 3600, res = 600, width = 7200) : | opening device failed | Execution halted ` If I reduce the dimensions of the above images, I see that the ODT output is along expected lines. I imagine that for some reasons, the ODT exporter has trouble figuring out the image dimensions of the second image. Btw, can you post the outputs of the following forms: #+begin_src emacs-lisp (list (* max-image-size (frame-pixel-width)) (* max-image-size (frame-pixel-height))) #+end_src #+results: | 3648.0 | 4320.0 | #+begin_src emacs-lisp (message %S (ignore-errors (image-size (create-image bar.png) 'pixels))) (message %S (ignore-errors (image-size (create-image baz.png) 'pixels))) #+end_src #+results: : (30 . 30) If you can also post the output of the XML created in your machines, I would be able to infer what could be happening. You can access the XML with: open odt file in archive-mode: C-x b test.odt or C-x C-f test.odt open content.xml : ENTER on content.xml search for .png : C-s .png Post the snippets for both 001.png and 002.png #+begin_html text:p text:style-name=Text_20_body draw:frame draw:style-name=OrgImageCaptionFrame svg:width=8.00cm text:anchor-type=paragraphdraw:text-box fo:min-height=8.00cmtext:p text:style-name=Illustrationdraw:frame draw:style-name=OrgCaptionedImage svg:width=8.00cm svg:height=8.00cm style:rel-width=100% style:rel-height=scale text:anchor-type=paragraphdraw:image xlink:href=Images/0001.png xlink:type=simple xlink:show=embed xlink:actuate=onLoad//draw:frameFigure text:sequence text:ref-name=fig:bar text:name=Figure text:formula=ooow:Figure+1 style:num-format=11/text:sequence: bar/text:p/draw:text-box/draw:frame /text:p text:p text:style-name=Text_20_body draw:frame draw:style-name=OrgImageCaptionFrame svg:width=0.53cm text:anchor-type=paragraphdraw:text-box fo:min-height=0.53cmtext:p text:style-name=Illustrationdraw:frame draw:style-name=OrgCaptionedImage svg:width=0.53cm svg:height=0.53cm style:rel-width=100% style:rel-height=scale text:anchor-type=paragraphdraw:image xlink:href=Images/0002.png xlink:type=simple xlink:show=embed xlink:actuate=onLoad//draw:frameFigure text:sequence text:ref-name=fig:baz text:name=Figure text:formula=ooow:Figure+1 style:num-format=12/text:sequence: baz/text:p/draw:text-box/draw:frame /text:p #+end_html Best, Andreas
Re: [O] [babel][patch] BUG in inline source blocks
Eric Schulte eric.schu...@gmx.com writes:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Martyn Jago martyn.j...@btinternet.com writes:
Martyn Jago martyn.j...@btinternet.com writes:
Hi,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi all,
I experience unexpected behaviour when an inline source block is not
preceded by whitespace.
Example:
===
* Test inline
This is a functional inline src_R{print(source block)}.
This (src_R{print(here)}) is not.
===
Regards,
Andreas
I can confirm this behaviour and provide a patch to allow for inline
source blocks to be preceded by punctuation, or, for instance, enclosed
in parenthesis, as in Andreas' example. Patch is attached for
consideration.
Best, Martyn
This is an updated version of the previous patch, with debug noise
removed, and a couple of extra tests.
Best, Martyn
Thanks for this patch Martyn, I just pushed up your [:punct:] change.
Hi Martyn,
thanks for this patch! It does half the job for me. Now export (or
evaluation) already work. But in the export I get a space inserted.
I my example, I'd expect (here) to appear in the export, but I get
( here).
This should now be fixed.
Thanks, Martyn and Eric! Indeed both issues are fixed now.
Regards,
Andreas
Re: [O] [babel] #+call-line removes hlines and headings ?
Marc-Oliver Ihm marc-oliver@online.de writes: Hello ! Generally enjoying babel very much, I have stumbled across a behaviour, that I do not quite understand: As it seems, a #+call in babel removes hlines from the results. Here is an example: #+call: foo() | 3 | 4 | #+name: foo #+begin_src emacs-lisp '((1 2) hline (3 4)) #+end_src #+results: foo | 1 | 2 | |---+---| | 3 | 4 | The #+begin_src-line does what I would expect; however, when it is called through a #+call-line the hline and the heading are removed. Is this the intended behaviour, a bug or am I missing something obvious ? Thanx a lot for any help ! with kind regards, Marc-Oliver Ihm Hi Marc-Oliver, it works with #+call: foo() :colnames yes The more surprising part for me is, that it works on the block itself without. Best, Andreas
[Orgmode] silent evaluation during export
Hi all, I have several code blocks that must be evaluated during export, but silently, i.e. I do not want code/output/anything to appear in the export. How do I achieve this? The obvious :export none also disables evaluation. Regards, Andreas smime.p7s Description: S/MIME Cryptographic Signature ___ 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] Re: inline code block results
Hi all,
just found out: the inline block works when I explicitly state :results
replace.
So both questions from the previous email collapse to: why is that
necessary?
Regards,
Andreas
Am 04.02.2011 17:13, schrieb Andreas Leha:
Hi all,
I have two questions:
(1) How do I get resuts from code block evaluation (e.g. a single
number) inline into text during (LaTeX-)export? Something like: We use
a level of #+call: getLevel()
(2) Why do these two subheadings produce different output during
(LaTeX-)export?
* Test
** Normal source code block
The number is
#+srcname: success_parameter_one
#+begin_src R :session :results value :exports results
tmp - rnorm(1)
#+end_src
** Inline source code block
The number is src_R[:session :results value :exports results]{tmp -
rnorm(1)}
Thanks in advance!
Andreas
--
Andreas Leha
Universitätsmedizin Göttingen
Abteilung Medizinische Statistik
Humboldtallee 32
37073 Göttingen
Tel: +49 (0)551 39-10710
Fax: +49 (0)551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha.html
University Medical Center Göttingen
Department for Medical Statistics
Humboldtallee 32
37073 Göttingen
Germany
Phone: +49 (0) 551 39-10710
Fax: +49 (0) 551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] inline code block results
Hi all,
I have two questions:
(1) How do I get resuts from code block evaluation (e.g. a single
number) inline into text during (LaTeX-)export? Something like: We use
a level of #+call: getLevel()
(2) Why do these two subheadings produce different output during
(LaTeX-)export?
* Test
** Normal source code block
The number is
#+srcname: success_parameter_one
#+begin_src R :session :results value :exports results
tmp - rnorm(1)
#+end_src
** Inline source code block
The number is src_R[:session :results value :exports results]{tmp -
rnorm(1)}
Thanks in advance!
Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Re: silent evaluation during export
Hi Dan, thanks. That's what I was looking for. Works perfectly. Cheers, Andreas Am 04.02.2011 17:25, schrieb Dan Davison: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I have several code blocks that must be evaluated during export, but silently, i.e. I do not want code/output/anything to appear in the export. How do I achieve this? The obvious :export none also disables evaluation. Hi Andreas, :exports results :results silent Dan Regards, Andreas ___ 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 smime.p7s Description: S/MIME Cryptographic Signature ___ 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] Re: inline code block results
Hi Dan,
Thanks for looking into this and for providing a patch that fast!
Andreas
Am 04.02.2011 18:11, schrieb Dan Davison:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi all,
just found out: the inline block works when I explicitly state :results
replace.
So both questions from the previous email collapse to: why is that
necessary?
Regards,
Andreas
Am 04.02.2011 17:13, schrieb Andreas Leha:
Hi all,
I have two questions:
(1) How do I get resuts from code block evaluation (e.g. a single
number) inline into text during (LaTeX-)export? Something like: We use
a level of #+call: getLevel()
(2) Why do these two subheadings produce different output during
(LaTeX-)export?
* Test
** Normal source code block
The number is
#+srcname: success_parameter_one
#+begin_src R :session :results value :exports results
tmp - rnorm(1)
#+end_src
** Inline source code block
The number is src_R[:session :results value :exports results]{tmp -
rnorm(1)}
Hi Andreas,
This is a bug, thanks. They should both produce the number (and no code)
in the exported material.
It bisects to d0ca215105 which is a recent commit re-working export of
inline- and regular src blocks. I believe the fix may be as below but
I'll let Eric S check that.
Note that in your inline src block :results value and :exports results
are usually unnecessary, as they are the default values for inline src
blocks.
Dan
diff --git a/lisp/ob.el b/lisp/ob.el
index b899410..3fecbbd 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -297,7 +297,7 @@ specific header arguments as well.)
Default arguments to use when evaluating a source block.)
(defvar org-babel-default-inline-header-args
- '((:session . none) (:results . silent) (:exports . results))
+ '((:session . none) (:results . replace) (:exports . results))
Default arguments to use when evaluating an inline source block.)
(defvar org-babel-current-buffer-properties nil
Thanks in advance!
Andreas
--
Andreas Leha
Universitätsmedizin Göttingen
Abteilung Medizinische Statistik
Humboldtallee 32
37073 Göttingen
Tel: +49 (0)551 39-10710
Fax: +49 (0)551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha.html
University Medical Center Göttingen
Department for Medical Statistics
Humboldtallee 32
37073 Göttingen
Germany
Phone: +49 (0) 551 39-10710
Fax: +49 (0) 551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] silent evaluation during export
Hi Erik, thanks for the pointer to that discussion which also answeres my question. I should have seen this. - Andreas Am 04.02.2011 17:48, schrieb Erik Iverson: Andreas, This may help, but I'm not sure what language you're using. I was using in this discussion. http://www.mail-archive.com/emacs-orgmode@gnu.org/msg29333.html The upshot from that thread was that by including a :session argument, you guarantee that the code runs on export. --Erik Andreas Leha wrote: Hi all, I have several code blocks that must be evaluated during export, but silently, i.e. I do not want code/output/anything to appear in the export. How do I achieve this? The obvious :export none also disables evaluation. Regards, Andreas ___ 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 -- Andreas Leha Universitätsmedizin Göttingen Abteilung Medizinische Statistik Humboldtallee 32 37073 Göttingen Tel: +49 (0)551 39-10710 Fax: +49 (0)551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha.html University Medical Center Göttingen Department for Medical Statistics Humboldtallee 32 37073 Göttingen Germany Phone: +49 (0) 551 39-10710 Fax: +49 (0) 551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html smime.p7s Description: S/MIME Cryptographic Signature ___ 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] graphics in eval vs graphics in export
Hi all, I am having trouble with LaTeX export (again). In my sample code, the source block below the headline 'Plot' produces a correct pdf, when evaluated (C-c C-c), but when exported, the pdf is broken. (I am on commit 0f01b842bb2b6fada2579d0278fc53422e8ea62f since the removal of htmlp prevents me from exporting) Regards, Andreas PS: my sample code: * Test #+srcname: plot_test #+begin_src R :session :exports code :eval never :noweb tangle :var chromosome plot(x=rnorm(10), y=rnorm(10)) #+end_src * Plot Produces fine pdf, when evaluated, but *not* when exported #+srcname: plot_test_1 #+begin_src R :session :noweb tangle :file test_1.pdf :exports results :results graphics :width 8 :height 4 test - 1 plot_one_test #+end_src #+results: plot_test_1 [[file:test_1.pdf]] ** intern :noexport: #+srcname: plot_one_test #+begin_src R :session :noweb tangle :file test.pdf test - test + 1 plot_test #+end_src smime.p7s Description: S/MIME Cryptographic Signature ___ 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] latex table export not centered
Thanks for looking into this. Yes, for me this issue still persists. Org at commit 0f01b84... Small bug fix to org-ascii-level-start (again) (as later 'htmlp' removal breaks latex export for me) GNU emacs 23.2.1 (debian squeeze) Regards, Andreas Am 11.02.2011 13:45, schrieb Bastien: Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: #+BIND: org-export-latex-tables-centered nil #+TITLE: Test Centered Tables * Test | col1 | col2 | col3 | |--+--+--| |1 |2 |3 | But this does not work. The table stays centered. I just tested this: the table is left aligned here (latest Org, GNU Emacs 24.0.50.1). Are you still having this issue? What version of Org/Emacs? attachment: andreas_leha.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ 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] [BUG] htmlp and latexp
Hi all, to make this explicit: I can not export to latex any more, but instead I get Exporting to LaTeX... when: Symbol's value as variable is void: htmlp Org HEAD GNU emacs 23.2.1 (debian squeeze) This is my failing org-file: * Test test - Andreas Am 16.02.2011 11:03, schrieb Bastien: Hi Dan, Dan Davison dandavis...@gmail.com writes: Commit ed6d6760268 removed variables htmlp and latexp from `org-export-preprocess-string'. Nothing wrong with that, but I think it has broken export for those using org-special-blocks, which contains #+begin_src emacs-lisp (defvar htmlp) (defvar latexp) (defun org-special-blocks-make-special-cookies () Adds special cookies when #+begin_foo and #+end_foo tokens are seen. This is run after a few special cases are taken care of. (when (or htmlp latexp) (goto-char (point-min)) ... #+end_src Fixed thanks. IIuc htmlp and latexp occur occasionally in org code as somewhat unofficial ways to test am I in the middle of export?. Now there is a uniform and official (!) way of getting the backend the user is currently exporting to: (eq backend 'html) ... They also occur in org-exp-blocks, but in deprecated code, so not a priority to fix. I fixed them there too. Thanks for reporting this! attachment: andreas_leha.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ 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] shell sessions hang
Hi all, this topic has been here before and seems to be a TODO: http://eschulte.github.com/babel-dev/TODO-shell-sessions-hang-in-many-cases.html This still seems to be an issue My questions: (1) Has there been progress? (2) Is there a better workaround than wrapping the shell commands in another language? Regards, Andreas smime.p7s Description: S/MIME Cryptographic Signature ___ 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] org-mode is slow :(
Hi Piter, First guess: functionality outside org-mode is slowing things down. First candidate: line numbers turned on? If yes, try disabling. Then there were discussions about speed here before, e.g. http://www.mail-archive.com/emacs-orgmode@gnu.org/msg27951.html Maybe you find sth there. HTH, Andreas Am 17.02.2011 13:29, schrieb Piter_: Hi all. I use org-mode to organize and process my experimental data. By now my org file has 5000 lines with a lot of python and matlab code. I started to fill that org-mode becomes slower. I have to wait for characters to appear while typing and so on. Can anybody reccomend a way to speed it up? Thanks. Petro P.S. I have installed the org mode from GIT: make make doc make install I guess it is bytecompiled already. ___ 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 smime.p7s Description: S/MIME Cryptographic Signature ___ 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] question about R graphics and latex export
Hi all,
I usually produce tikz graphics in R which produce great results in
latex export (and I am able to handle them).
Now I have some plots too big to handle with tikz, so I go for pdf.
I have a question (example below):
There is one piece of code to produce several plots according to some
(only one in the example) parameters. Now with pdf I have to produce a
different pdf file for each parameter (combination).
My question is: Can I use Org variable and #+call: constructs to do that?
Thanks in advance!
- Andreas
PS: This is my sample:
=
#+TITLE:Test Plots
* Test
** The plotting code
This code takes the parameter =sd=
#+srcname: plot_code
#+begin_src R :session :exports code :eval never :var sd
plot(x=rnorm(100, sd=sd),
y=rnorm(100, sd=sd))
#+end_src
** Set the parameter in =R= (working)
When setting the parameter in =R= I need an indirect code block:
#+srcname: plot_sd_1
#+begin_src R :session :noweb tangle :file plotone.pdf :exports
results :results graphics silent :width 8 :height 4
sd - 1
plot_code
#+end_src
Now I can include this nicely in latex: See figure \ref{fig:test}
#+begin_src latex :noweb yes
\begin{figure}[htb!]
\centering
\includegraphics[width=5in]{plot_sd_1()}
\caption[Test]{Test 1}
\label{fig:test}
\end{figure}
#+end_src
** Set the parameter in Org (How to do)
The following does not work. Is this somehow possible? Would be
much nicer than setting the parameters in R.
# #+call: plot_code(sd=1) :session :file plotthree.pdf :exports results
:results graphics :width 8 :height 4
=
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Re: Suppressing src block evaluationon publish?
Hi all, sorry to reopen this thread, but this does not work for me (GNU Emacs 23.2.1, Org almost HEAD c7700d7bbee4f7596feb199b1ec1bc7750d4fb48) For me the image in the attached example is always created during (LaTeX)export. Even if I do the manual evaluation once (and the hash is created). The manual re-evaluation respects the :cache yes and does not evaluate again. What am I missing? - Andreas * Test Some text. #+srcname: some_code #+begin_src R :session :exports code :eval never mean - 0 #+end_src Some text. #+srcname: plot_code #+begin_src R :session :exports code :eval never plot(x=rnorm(100, mean=mean, sd=sd), y=rnorm(100, mean=mean, sd=sd)) #+end_src * Plots #+LABEL: fig:test #+ATTR_LaTeX: height=.29\textheight #+srcname: plot_1 #+begin_src R :session :noweb yes :file test.pdf :exports results :results graphics :width 8 :height 4 :cache yes sd - 4 some_code plot_code #+end_src #+results[17681e8e450f1f4e1d8f55fa57f9be1b24dae4db]: plot_1 [[file:test.pdf]] Am 03.02.2011 15:34, schrieb Eric Schulte: Dan Davison dandavis...@gmail.com writes: Loris Bennett loris.benn...@fu-berlin.de writes: Erik Iverson er...@ccbr.umn.edu writes: Loris Bennett wrote: Hi, I have an org file containing several src blocks which generate images using ditaa. When I publish to PDF via LaTeX, the images are all generated every time, which makes publishing rather slow. Is there some way to toggle the evaluation of the src blocks on and off when the file is published? You could try the :cache header argument, http://orgmode.org/org.html#cache Ah, thanks. There is a slight gotcha here, though. I added :cache yes to the source headers and exported again, but nothing changed; all the images were generated again. Also, no SHA1 hash was added to the +results header. After some fruitless fiddling I was about to write to the list again and moan, when I did a slightly random C-c C-c in the begin_src line and, hey presto, the hash was added to the results header. I then did this for all the images and found that the image were no longer regenerated on export, as advertised. Hi Loris, Yes. It does seem that it would be nice if in this situation, the first export added the SHA1s, and subsequent exports recognized that evaluation wasn't required. I think the reason this does not happen is that behind-the-scenes Org makes a copy of the buffer for export preprocessing (including src block evaluation). But Eric S is the expert -- he may have more to say here. Yes, this is exactly the case. Org-mode is very careful that the process of exporting does not make any permanent changes to the original org-mode file. I agree this should be mentioned in the :cache documentation. 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 smime.p7s Description: S/MIME Cryptographic Signature ___ 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] Re: [BUG] htmlp and latexp
Hi all, I did not send to the list, so I resend my last email below. But for me I found the issue: org-exp-bibtex.el is the problem. Regards, Andreas PS: Here my last email: Thanks for looking into this. But just pulled before asking. I am pulling from git://repo.or.cz/org-mode.git The latest commit there is commit c7700d7bbee4f7596feb199b1ec1bc7750d4fb48 Author: Bastien Guerry b...@altern.org Date: Wed Feb 16 11:53:28 2011 +0100 * org-html.el (org-export-as-html): expand the HTML title. This fix is a modified version of a patch submitted by Pierre Téchoueyres. The problem is still there. M-x org-version : 7.4 The backtrace (after M-x toggle-debug-on-error) is: Debugger entered--Lisp error: (void-variable htmlp) (if htmlp (progn (org-exp-bibtex-docites ...) (org-exp-bibtex-docites ...))) (when htmlp (org-exp-bibtex-docites (lambda nil ...)) (org-exp-bibtex-docites (lambda nil ...))) (save-window-excursion (setq oebp-cite-plist (quote nil)) (goto-char (point-min)) (while (re-search-forward ^#\\+BIBLIOGRAPHY:[ ]+\\(\\S-+\\)[ ]+\\(\\S-+\\)\\([^^M\n]*\\) nil t) (let ... ...)) (when htmlp (org-exp-bibtex-docites ...) (org-exp-bibtex-docites ...))) org-export-bibtex-preprocess() run-hooks(org-export-preprocess-hook) org-export-preprocess-string(#(\n\n 0 1 (fontified nil) 1 2 (fontified nil)) :for-backend latex :emph-multiline t :add-text nil :comments nil :skip-before-1st-heading nil :LaTeX-fragments nil :timestamps t :footnotes t) org-export-latex-first-lines((:latex-image-options width=10em :exclude-tags (noexport) :select-tags (export) :email andreas@habakuk :author andreas :html-postamble nil :html-preamble nil :publishing-directory nil :timestamp nil :expand-quoted-html t :html-table-tag table border=\2\ cellspacing=\0\ cellpadding=\6\ rules=\groups\ frame=\hsides\ :xml-declaration ((html . ?xml version=\1.0\ encoding=\%s\?) (php . ?php echo \?xml version=\\\1.0\\\ encoding=\\\%s\\\ ?\; ?)) :html-extension html :inline-images maybe :convert-org-links t :agenda-style :style-extra :style :style-include-scripts t :style-include-default t :table-auto-headline t :tables t :time-stamp-file t :creator-info t :email-info nil ...) nil nil) org-export-as-latex(nil) call-interactively(org-export-as-latex) org-export(nil) call-interactively(org-export nil nil) Am 17.02.2011 11:50, schrieb Jambunathan K: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, to make this explicit: I can not export to latex any more, but instead I get Exporting to LaTeX... when: Symbol's value as variable is void: htmlp Org HEAD GNU emacs 23.2.1 (debian squeeze) This is my failing org-file: * Test test Have you tried recent head? Enable stacktrace: M-x toggle-debug-on-error Also include M-x org-version? Jambunathan K. - Andreas Am 16.02.2011 11:03, schrieb Bastien: Hi Dan, Dan Davison dandavis...@gmail.com writes: Commit ed6d6760268 removed variables htmlp and latexp from `org-export-preprocess-string'. Nothing wrong with that, but I think it has broken export for those using org-special-blocks, which contains #+begin_src emacs-lisp (defvar htmlp) (defvar latexp) (defun org-special-blocks-make-special-cookies () Adds special cookies when #+begin_foo and #+end_foo tokens are seen. This is run after a few special cases are taken care of. (when (or htmlp latexp) (goto-char (point-min)) ... #+end_src Fixed thanks. IIuc htmlp and latexp occur occasionally in org code as somewhat unofficial ways to test am I in the middle of export?. Now there is a uniform and official (!) way of getting the backend the user is currently exporting to: (eq backend 'html) ... They also occur in org-exp-blocks, but in deprecated code, so not a priority to fix. I fixed them there too. Thanks for reporting this! ___ 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 ___ 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 -- Universitätsmedizin Göttingen Abteilung Medizinische Statistik Humboldtallee 32 37073 Göttingen Tel: +49 (0)551 39-10710 Fax: +49 (0)551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha.html University Medical Center Göttingen Department for Medical Statistics Humboldtallee 32 37073 Göttingen Germany Phone: +49 (0) 551 39-10710 Fax: +49 (0) 551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html attachment: andreas_leha.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ Emacs
[Orgmode] source code and parameters
Hi all experts, When working with source code in org mode I like to keep the parameters in org-tables. Especially since I have code in different languages that should share the same set of parameters. Problem is: When I tangle my source code blocks the tangled files loose the parameters. How do I deel best with parameters and source code blocks? Regards, Andreas attachment: andreas_leha.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ 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] [babel] Including TikZ diagrams as figures in export
Hi Jeffrey,
the attached sample file works for me.
The html is only sub-optimal, though, as it just includes a link to a
pdf file.
Cheers,
Andreas
Am 21.02.2011 02:56, schrieb Erik Iverson:
Jeffrey,
Now, I'd like to integrate them into an org document. I'd like:
1) To use babel to handle the TikZ source
This is possible.
2) To wrap the resulting drawing in a figure environment for
automatic numbering and centering
See
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html
and search for tikz for an example. I think you do need to use the
:file argument
for this to have org-mode take care of it automatically.
Alternatively, you could just include *all* the latex you want, including
constructing your own figure environment and caption and refs, in the
latex
code block.
3) To be able to refer to the figure elsewhere in the document
Should be possible with either approach above.
4) (optional) To be able to seamlessly export to both LaTeX and HTML
So should the HTML exporter generate a PNG file then, as opposed to PDF?
This is possible, but requires some 'conditional' elisp code in your
:file
source block argument. I think I can help if that's indeed what you
want.
And somewhat unrelated, is :results now deprecated in favor of
:exports? What about :file? I'm sufficiently new to babel that
these all seem like they could be taken care of with a single header
argument with many options...
Not deprecated at all according to my understanding:
:results determines how the results are collected from a process. So,
in R, we
might want the standard output ':results output' or we might just want
the last
value returned by the code block, ':results value'. This determines
what is
inserted into the org-mode buffer or the export stream when the code
block
is evaluated.
:exports determines if the code and/or the results will be inserted upon
exporting. *If* the results are inserted, then :results will determine
how.
:file is useful for code blocks that generate graphical output, such
as tikz.
This will divert the output into the named file, and exporting will
insert
that file. In the org-mode buffer, a link will be inserted. If a png
file is
generated, it can even be displayed inline in the org-mode buffer if
you turn
on that functionality.
___
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
#+LATEX_HEADER: \usepackage{tikz}
* Tikz Sample
In figure \ref{fig:tikz_sample} you can see something.
#+srcname: tikz_sample
#+begin_src latex :exports (if (eq backend 'latex) none results) :file
tikz_sample.pdf :headers '(\\usepackage{tikz})
\usetikzlibrary{arrows}
\tikzstyle{int}=[draw, fill=blue!20, minimum size=2em]
\tikzstyle{init} = [pin edge={to-,thin,black}]
\begin{tikzpicture}[node distance=2.5cm,auto,=latex']
\node [int, pin={[init]above:$v_0$}] (a) {$\frac{1}{s}$};
\node (b) [left of=a,node distance=2cm, coordinate] {a};
\node [int, pin={[init]above:$p_0$}] (c) [right of=a] {$\frac{1}{s}$};
\node [coordinate] (end) [right of=c, node distance=2cm]{};
\path[-] (b) edge node {$a$} (a);
\path[-] (a) edge node {$v$} (c);
\draw[-] (c) edge node {$p$} (end) ;
\end{tikzpicture}
#+end_src
#+begin_src latex :noweb yes
\begin{figure}
\centering
tikz_sample
\caption[Tikz]{Tikz}\label{fig:tikz_sample}
\end{figure}
#+end_src
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Re: source code and parameters
Can not reproduce this anymore. My variables are exported nicely now. Sorry for the noise. - Andreas Am 21.02.2011 10:06, schrieb Sébastien Vauban: Hi Andreas, Andreas Leha wrote: When working with source code in org mode I like to keep the parameters in org-tables. Especially since I have code in different languages that should share the same set of parameters. Problem is: When I tangle my source code blocks the tangled files loose the parameters. How do I deel best with parameters and source code blocks? Could you show us a small example explaining what the problem is? Best regards, Seb smime.p7s Description: S/MIME Cryptographic Signature ___ 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][babel] How to add results to text inline?
Hi Torsten,
Have a look at the 'src_language{body}' construct as described here:
http://orgmode.org/org.html#Structure-of-code-blocks
Hth,
Andreas
Am 23.02.2011 06:55, schrieb Torsten Wagner:
Hi,
guess this is a FAQ or at least a stupid question.
However, I read along worg and wasn't able to find a solution.
I would like to add the result of a source code block in some text
paragraph.
---start--mini-example
#+source:my_formula(my_parameter='1')
#+begin_src python :results value :exports code
y = 2
f = my_parameter * y
return f
#+end_src
In my long long paragraph after that I want to say that
my result is #+call: my_formula(my_parameter='5') for x=5 but it is
#+call: my_formula() for x=1
---end--mini-example
Well I would replace the calls by the result of the source code block
I read about no-web but this seems to work only within code blocks. I
read about inline source code blocks, however, more complex functions
would make it difficult to read.
Thanks for pointing me to obvious solutions ;)
Torsten
CC. How about some C-like format string for number results like
#+call: my_formula(my_parameter='5') :exports results :format %i5
results in integer 5 digits
00010
and #+call: my_formula(my_parameter='5') :exports results :format %s.3
could result in scientific notation with 3 digits after the comma
1.000*10^1
This would allow to format the result to the needs just in place.
___
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
smime.p7s
Description: S/MIME Cryptographic Signature
___
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][babel] How to add results to text inline?
Sorry. I should have read your message properly.
How about:
In my long long paragraph after that I want to say that
my result is src_python[:noweb yes :results value raw replace :exports
results]{return my_formula(my_parameter='5')} for x=5.
Regards,
Andreas
Am 23.02.2011 09:14, schrieb Torsten Wagner:
Hi Andreas,
thanks for pointing to that. I guess it is the same like on worg.
As far as I understood this would help me to add the python code
inside my paragraph which is indeed nice for small code-snippet.
However, I would like to replace the result of a function call via
#+call aka #+lob aka #+function.
I will try he src_python{print f} and use a session...
However, I thought there might be a 'easier' way ;)
Thanks
Torsten
On 02/23/2011 04:53 PM, Andreas Leha wrote:
Hi Torsten,
Have a look at the 'src_language{body}' construct as described here:
http://orgmode.org/org.html#Structure-of-code-blocks
Hth,
Andreas
Am 23.02.2011 06:55, schrieb Torsten Wagner:
Hi,
guess this is a FAQ or at least a stupid question.
However, I read along worg and wasn't able to find a solution.
I would like to add the result of a source code block in some text
paragraph.
---start--mini-example
#+source:my_formula(my_parameter='1')
#+begin_src python :results value :exports code
y = 2
f = my_parameter * y
return f
#+end_src
In my long long paragraph after that I want to say that
my result is #+call: my_formula(my_parameter='5') for x=5 but it is
#+call: my_formula() for x=1
---end--mini-example
Well I would replace the calls by the result of the source code block
I read about no-web but this seems to work only within code blocks. I
read about inline source code blocks, however, more complex functions
would make it difficult to read.
Thanks for pointing me to obvious solutions ;)
Torsten
CC. How about some C-like format string for number results like
#+call: my_formula(my_parameter='5') :exports results :format %i5
results in integer 5 digits
00010
and #+call: my_formula(my_parameter='5') :exports results :format %s.3
could result in scientific notation with 3 digits after the comma
1.000*10^1
This would allow to format the result to the needs just in place.
___
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
___
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
___
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
--
Andreas Leha
Universitätsmedizin Göttingen
Abteilung Medizinische Statistik
Humboldtallee 32
37073 Göttingen
Tel: +49 (0)551 39-10710
Fax: +49 (0)551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha.html
University Medical Center Göttingen
Department for Medical Statistics
Humboldtallee 32
37073 Göttingen
Germany
Phone: +49 (0) 551 39-10710
Fax: +49 (0) 551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [PATCH] new babel latex feature :imagemagick
Hi all,
Just a small patch that might make life easier for
LaTeX (and esp. tikz) users. It enables the output of graphics in a
lot of formats using imagemagick. See below for an example.
This is my first patch, I have never programmed emacs lisp before, and
my common lisp experiences have been short and a while ago. So please
excuse a (possibly) bad patch.
Details:
LaTeX source blocks now have three new options:
- :imagemagick
When not nil the source block is processed to pdf and the pdf is
converted with imagemagick to whatever is given as :file
Thus, the format is not limited to png.
- :iminoptions
This is passed to imagemagick before the pdf file
- :imoutoptions
This is passed to imagemagick before the output file
Small Example:
#+begin_src latex ... :file test.jpg :imagemagick yes :iminoptions
-density 300 :imoutoptions -geometry 400 ...
will use this command for conversion:
convert -density 300 tmp-pdf -geometry 400 test.jpg
Full example:
Export this to pdf and to html to see the effect.
===
* Test
#+begin_src R :session :exports both :results silent
library(tikzDevice)
#+end_src
#+srcname: test_plot
#+begin_src R :session :exports code :results output latex
tikz(console=TRUE, width=4, height=4)
plot(rnorm(100), rnorm(100))
dummy - dev.off()
#+end_src
#+srcname: test_plot_png
#+begin_src latex :exports (if (and (boundp 'backend) (eq backend
'latex)) none results) :file test.png :imagemagick yes :iminoptions
-density 600 :imoutoptions -geometry 400 :fit yes :noweb yes :headers
'(\\usepackage{tikz})
test_plot()
#+end_src
#+srcname: test_plot_tikz
#+begin_src latex :noweb yes
test_plot()
#+end_src
* Latex Options :noexport:
#+LATEX_HEADER: \usepackage{tikz}
===
Regards,
Andreas
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index 8943ded..6152ad3 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -72,6 +72,10 @@ This function is called by `org-babel-execute-src-block'.
(let* ((out-file (cdr (assoc :file params)))
(tex-file (org-babel-temp-file latex- .tex))
(border (cdr (assoc :border params)))
+ (imagemagick (cdr (assoc :imagemagick params)))
+ (im-in-options (cdr (assoc :iminoptions params)))
+ (im-out-options (cdr (assoc :imoutoptions params)))
+ (pdfpng (cdr (assoc :pdfpng params)))
(fit (or (cdr (assoc :fit params)) border))
(height (and fit (cdr (assoc :pdfheight params
(width (and fit (cdr (assoc :pdfwidth params
@@ -81,10 +85,10 @@ This function is called by `org-babel-execute-src-block'.
(append (cdr (assoc :packages params))
org-export-latex-packages-alist)))
(cond
- ((string-match \\.png$ out-file)
+ ((and (string-match \\.png$ out-file) (not imagemagick))
(org-create-formula-image
body out-file org-format-latex-options in-buffer))
- ((string-match \\.pdf$ out-file)
+ ((or (string-match \\.pdf$ out-file) imagemagick)
(require 'org-latex)
(with-temp-file tex-file
(insert
@@ -118,13 +122,26 @@ This function is called by `org-babel-execute-src-block'.
(concat \n\\begin{document}\n body \n\\end{document}\n)))
(org-export-latex-fix-inputenc))
(when (file-exists-p out-file) (delete-file out-file))
- (rename-file (org-babel-latex-tex-to-pdf tex-file) out-file))
+ (let* ((transient-pdf-file (org-babel-latex-tex-to-pdf tex-file)))
+ (cond
+ ((string-match \\.pdf$ out-file)
+ (rename-file transient-pdf-file out-file))
+ (imagemagick
+ (convert-pdf transient-pdf-file out-file im-in-options im-out-options)
+ (when (file-exists-p transient-pdf-file) (delete-file transient-pdf-file))
((string-match \\.\\([^\\.]+\\)$ out-file)
- (error can not create %s files, please specify a .png or .pdf file
+ (error can not create %s files, please specify a .png or .pdf file or try the :imagemagick header arguement
(match-string 1 out-file
nil) ;; signal that output has already been written to file
body))
+
+(defun convert-pdf (pdffile out-file im-in-options im-out-options)
+ Generate a file from a pdf file using imagemagick.
+ (let* ((cmd (concat convert im-in-options pdffile im-out-options out-file)))
+(message (concat Converting pdffile file cmd ...))
+(shell-command cmd)))
+
(defun org-babel-latex-tex-to-pdf (file)
Generate a pdf file according to the contents FILE.
Extracted from `org-export-as-pdf' in org-latex.el.
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [babel] Bug? :cache yes ignored when :noweb yes
Hi all, When ':noweb yes' is in the header, ':cache yes' is ignored during export. (At least when I export the sample file below.) To me this seems to be a bug. Or am I missing something? Regards, Andreas PS: Example: * Test #+srcname: test_sleep #+begin_src R :session :exports code Sys.sleep(time=5) 1:10 #+end_src #+srcname: test_sleep #+begin_src R :session :exports results :noweb yes :cache yes test_sleep #+end_src #+results[e2c9e6c2f84563b590a765502057d92463e50182]: test_sleep | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | | 9 | | 10 | == smime.p7s Description: S/MIME Cryptographic Signature ___ 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] [PATCH] new babel latex feature :imagemagick
It's on the way.
Am 26.02.2011 01:13, schrieb Eric Schulte:
Hi Andreas,
This patch looks like a great idea and a clean implementation. Thanks
for sharing. Would you be willing to sign the FSF copyright assignment
papers? If not I probably can not apply your patch as it changes over
10 lines -- which I'm pretty sure is the copyright assignment cutoff.
For more information on contributing to Org-mode see the following
http://orgmode.org/worg/org-contribute.html
Thanks! -- Eric
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi all,
Just a small patch that might make life easier for
LaTeX (and esp. tikz) users. It enables the output of graphics in a
lot of formats using imagemagick. See below for an example.
This is my first patch, I have never programmed emacs lisp before, and
my common lisp experiences have been short and a while ago. So please
excuse a (possibly) bad patch.
Details:
LaTeX source blocks now have three new options:
- :imagemagick
When not nil the source block is processed to pdf and the pdf is
converted with imagemagick to whatever is given as :file
Thus, the format is not limited to png.
- :iminoptions
This is passed to imagemagick before the pdf file
- :imoutoptions
This is passed to imagemagick before the output file
Small Example:
#+begin_src latex ... :file test.jpg :imagemagick yes :iminoptions
-density 300 :imoutoptions -geometry 400 ...
will use this command for conversion:
convert -density 300 tmp-pdf -geometry 400 test.jpg
Full example:
Export this to pdf and to html to see the effect.
===
* Test
#+begin_src R :session :exports both :results silent
library(tikzDevice)
#+end_src
#+srcname: test_plot
#+begin_src R :session :exports code :results output latex
tikz(console=TRUE, width=4, height=4)
plot(rnorm(100), rnorm(100))
dummy - dev.off()
#+end_src
#+srcname: test_plot_png
#+begin_src latex :exports (if (and (boundp 'backend) (eq backend
'latex)) none results) :file test.png :imagemagick yes :iminoptions
-density 600 :imoutoptions -geometry 400 :fit yes :noweb yes :headers
'(\\usepackage{tikz})
test_plot()
#+end_src
#+srcname: test_plot_tikz
#+begin_src latex :noweb yes
test_plot()
#+end_src
* Latex Options :noexport:
#+LATEX_HEADER: \usepackage{tikz}
===
Regards,
Andreas
___
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
___
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
--
Universitätsmedizin Göttingen
Abteilung Medizinische Statistik
Humboldtallee 32
37073 Göttingen
Tel: +49 (0)551 39-10710
Fax: +49 (0)551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha.html
University Medical Center Göttingen
Department for Medical Statistics
Humboldtallee 32
37073 Göttingen
Germany
Phone: +49 (0) 551 39-10710
Fax: +49 (0) 551 39-4995
http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html
attachment: andreas_leha.vcf
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [babel] Bug? :cache yes ignored when :noweb yes
Hi Eric, thanks for testing this. It works for me when executing as well. But not when exporting. Does that work for you? I have tested this on two computers with the latest git version. Cheers, Andreas Am 26.02.2011 01:29, schrieb Eric Schulte: Hi Andreas, This exact example worked for me -- that is the results were returned without executing the sleep 5 code. Maybe you are using an old version of Org, or you have non-standard default header argument values? Best -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, When ':noweb yes' is in the header, ':cache yes' is ignored during export. (At least when I export the sample file below.) To me this seems to be a bug. Or am I missing something? Regards, Andreas PS: Example: * Test #+srcname: test_sleep #+begin_src R :session :exports code Sys.sleep(time=5) 1:10 #+end_src #+srcname: test_sleep #+begin_src R :session :exports results :noweb yes :cache yes test_sleep #+end_src #+results[e2c9e6c2f84563b590a765502057d92463e50182]: test_sleep | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | | 9 | | 10 | == ___ 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 ___ 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 attachment: andreas_leha.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ 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
[O] [babel] Bug? export with 'hidden' tables
Hi all, I used to have parameters in org tables, which were in secions marked with 'noexport'. Since this weekend, this does not work for me anymore. Is this a bug or am I doing sth wrong here? Regards, Andreas PS: the example (try to export) * Parameters :noexport: #+CAPTION: Directories #+LABEL: tbl:directories #+tblname: tbl_directories | directory | path | |+| | data directory | /home/ | | plot directory | /home/ | | code directory | /home/ | #+CAPTION: Data Files #+LABEL: tbl:data_files #+tblname: tbl_data_files | file| path | |-+| | original data | data | | original data (csv) | data_m | * Test #+begin_src R :session :exports results :results silent :var data_dir=tbl_directories[2,1] library(tikzDevice) #+end_src smime.p7s Description: S/MIME Cryptographic Signature ___ 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: [O] [babel] Bug? export with 'hidden' tables
Hi Eric, thanks a lot for this quick answer. I indeed was not aware of the COMMENT keyword. Unfortunately it does not solve the problem. When I try to export the sample file below I still get: 'if: reference 'tbl_directories' not found in this buffer' Cheers, Andreas PS: the sample (try to export it) == * COMMENT Parameters #+CAPTION: Directories #+LABEL: tbl:directories #+tblname: tbl_directories | directory | path | |+| | data directory | /home/ | | plot directory | /home/ | | code directory | /home/ | #+CAPTION: Data Files #+LABEL: tbl:data_files #+tblname: tbl_data_files | file| path | |-+| | original data | data | | original data (csv) | data_m | * Test #+begin_src R :session :exports results :results silent :var data_dir=tbl_directories[2,1] library(tikzDevice) #+end_src == Am 28.02.2011 19:56, schrieb Eric Schulte: Hi Andreas, I don't know about :noexport:, but to keep a subtree from exporting, I use the COMMENT keyword in the title, which can be done with the `org-toggle-comment' command bound to C-c ;. Hope this helps -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I used to have parameters in org tables, which were in secions marked with 'noexport'. Since this weekend, this does not work for me anymore. Is this a bug or am I doing sth wrong here? Regards, Andreas PS: the example (try to export) * Parameters :noexport: #+CAPTION: Directories #+LABEL: tbl:directories #+tblname: tbl_directories | directory | path | |+| | data directory | /home/ | | plot directory | /home/ | | code directory | /home/ | #+CAPTION: Data Files #+LABEL: tbl:data_files #+tblname: tbl_data_files | file| path | |-+| | original data | data | | original data (csv) | data_m | * Test #+begin_src R :session :exports results :results silent :var data_dir=tbl_directories[2,1] library(tikzDevice) #+end_src ___ 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 ___ 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 -- Andreas Leha Universitätsmedizin Göttingen Abteilung Medizinische Statistik Humboldtallee 32 37073 Göttingen Tel: +49 (0)551 39-10710 Fax: +49 (0)551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha.html University Medical Center Göttingen Department for Medical Statistics Humboldtallee 32 37073 Göttingen Germany Phone: +49 (0) 551 39-10710 Fax: +49 (0) 551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html smime.p7s Description: S/MIME Cryptographic Signature ___ 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: [O] [babel] Bug? export with 'hidden' tables
Thanks for the quick fix! Works nicely again! Am 28.02.2011 20:32, schrieb Eric Schulte: Ah, This is a bug I introduced in one of my weekend commits. I've just pushed up a fix. Thanks for catching this -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, thanks a lot for this quick answer. I indeed was not aware of the COMMENT keyword. Unfortunately it does not solve the problem. When I try to export the sample file below I still get: 'if: reference 'tbl_directories' not found in this buffer' Cheers, Andreas PS: the sample (try to export it) == * COMMENT Parameters #+CAPTION: Directories #+LABEL: tbl:directories #+tblname: tbl_directories | directory | path | |+| | data directory | /home/ | | plot directory | /home/ | | code directory | /home/ | #+CAPTION: Data Files #+LABEL: tbl:data_files #+tblname: tbl_data_files | file| path | |-+| | original data | data | | original data (csv) | data_m | * Test #+begin_src R :session :exports results :results silent :var data_dir=tbl_directories[2,1] library(tikzDevice) #+end_src == Am 28.02.2011 19:56, schrieb Eric Schulte: Hi Andreas, I don't know about :noexport:, but to keep a subtree from exporting, I use the COMMENT keyword in the title, which can be done with the `org-toggle-comment' command bound to C-c ;. Hope this helps -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I used to have parameters in org tables, which were in secions marked with 'noexport'. Since this weekend, this does not work for me anymore. Is this a bug or am I doing sth wrong here? Regards, Andreas PS: the example (try to export) * Parameters :noexport: #+CAPTION: Directories #+LABEL: tbl:directories #+tblname: tbl_directories | directory | path | |+| | data directory | /home/ | | plot directory | /home/ | | code directory | /home/ | #+CAPTION: Data Files #+LABEL: tbl:data_files #+tblname: tbl_data_files | file| path | |-+| | original data | data | | original data (csv) | data_m | * Test #+begin_src R :session :exports results :results silent :var data_dir=tbl_directories[2,1] library(tikzDevice) #+end_src ___ 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 ___ 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 ___ 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 -- Andreas Leha Universitätsmedizin Göttingen Abteilung Medizinische Statistik Humboldtallee 32 37073 Göttingen Tel: +49 (0)551 39-10710 Fax: +49 (0)551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha.html University Medical Center Göttingen Department for Medical Statistics Humboldtallee 32 37073 Göttingen Germany Phone: +49 (0) 551 39-10710 Fax: +49 (0) 551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html smime.p7s Description: S/MIME Cryptographic Signature ___ 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
[O] [Babel][Bug] results silent ignored in #+call
Hi everyone, Just pulled the latest HEAD and found that there is a regression in babel. When a source block is evaluated via #+call the :results silent header arguement is ignored during export =test file * Test1 #+srcname: test #+begin_src R :session :exports results :results silent 1:10 #+end_src Test1. * Test2 #+call: test() :session :exports results :results silent Test2. == Regards, Andreas smime.p7s Description: S/MIME Cryptographic Signature
[O] [babel] C-' not robust
Hi, there are two rather new add-ons to ess that -- when activated -- break the connection between the org document and a R-src-buffer: auto-complete-mode for R: http://www.emacswiki.org/emacs/AutoCompleteSources#toc2 yasnippet for R: http://www.svenhartenstein.de/Software/R-autoyas As especially the latter seems really useful, I want to ask, whether somebody has an idea of how to get them work in org-mode. Regards, Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: [O] [Babel][Bug] results silent ignored in #+call
Hi Eric, thanks for your answer. Just for me to understand: What is your suggestion then, if I still want the source code block to be evaluated during export? I asked a while ago on this list how to do that and got the answer :exports results :results silent which to my understanding now makes perfectly sense: http://www.mail-archive.com/emacs-orgmode@gnu.org/msg36910.html I tried to omit the :exports results header argument and got weirder results, as now the #+call: is not evaluated at all, but appears in the output. ===example to export=== * Test1 #+srcname: test #+begin_src R :session :results silent 1:10 #+end_src Test1. * Test2 #+call: test() :session :results silent Test2. == Best wishes, Andreas Am 14.03.2011 21:59, schrieb Eric Schulte: Hi Andreas, The :exports results header argument is overriding the :results silent header argument, which IMO is desired behavior. Thanks to your example I see this is not the case for regular code blocks. I would think that the behavior should be changed for regular code blocks, s.t. both of the tests in your example below export results. Best -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi everyone, Just pulled the latest HEAD and found that there is a regression in babel. When a source block is evaluated via #+call the :results silent header arguement is ignored during export =test file * Test1 #+srcname: test #+begin_src R :session :exports results :results silent 1:10 #+end_src Test1. * Test2 #+call: test() :session :exports results :results silent Test2. == Regards, Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: [O] [Babel][Bug] results silent ignored in #+call
Hi Eric, thanks a lot! Seems to be fixed for me. Cheers, Andreas Am 15.03.2011 14:13, schrieb Eric Schulte: Hi Andreas, If the call line has a :session header argument, then it should be evaluated on export; regardless of the value of the :export header argument. Adding a :exports none header argument, should inhibit the insertion of any results into the exported document. In your example below, the reason that the #+call: header argument is not exported is because your :session header argument has no value, the following call line would be exported. #+call: test() :session *R* :exports none I just pushed up a fix which removes this requirement for named sessions, so you example below should now work. Best -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, thanks for your answer. Just for me to understand: What is your suggestion then, if I still want the source code block to be evaluated during export? I asked a while ago on this list how to do that and got the answer :exports results :results silent which to my understanding now makes perfectly sense: http://www.mail-archive.com/emacs-orgmode@gnu.org/msg36910.html I tried to omit the :exports results header argument and got weirder results, as now the #+call: is not evaluated at all, but appears in the output. ===example to export=== * Test1 #+srcname: test #+begin_src R :session :results silent 1:10 #+end_src Test1. * Test2 #+call: test() :session :results silent Test2. == Best wishes, Andreas Am 14.03.2011 21:59, schrieb Eric Schulte: Hi Andreas, The :exports results header argument is overriding the :results silent header argument, which IMO is desired behavior. Thanks to your example I see this is not the case for regular code blocks. I would think that the behavior should be changed for regular code blocks, s.t. both of the tests in your example below export results. Best -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi everyone, Just pulled the latest HEAD and found that there is a regression in babel. When a source block is evaluated via #+call the :results silent header arguement is ignored during export =test file * Test1 #+srcname: test #+begin_src R :session :exports results :results silent 1:10 #+end_src Test1. * Test2 #+call: test() :session :exports results :results silent Test2. == Regards, Andreas -- Andreas Leha Universitätsmedizin Göttingen Abteilung Medizinische Statistik Humboldtallee 32 37073 Göttingen Tel: +49 (0)551 39-10710 Fax: +49 (0)551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha.html University Medical Center Göttingen Department for Medical Statistics Humboldtallee 32 37073 Göttingen Germany Phone: +49 (0) 551 39-10710 Fax: +49 (0) 551 39-4995 http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html smime.p7s Description: S/MIME Cryptographic Signature
[O] [babel] feature request: automatically connect source code block to its session
Hi all, I have a feature request (if what I want is not already possible, that is). Could a source code block, which has the :session header argument, be associated with its session as soon as C-' is pressed? The background to this question is, that all ess support functionality for R (r-autoyas, autocomplete-R, and ess-eldoc) need an associated R session. They start to function only as soon as the first line of the code block is evaluated, which associates the source buffer with its session. The autocomplete-R even fails to load without an associated R session (byte-code: Language mode `R-mode' fails with: Symbol nil may not be buffer-local) and this way cuts the connection to org, such that C-' becomes undefined. Regards, Andreas attachment: andreas_leha.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [O] [babel] feature request: automatically connect source code block to its session
Hi Eric, thanks for looking into this! Unfortunately, I do not know the setup here. But I asked on the ess mailing list and got an answer from Stephen Eglen: I think you want to set ess-local-process-name given by the :session argument in the .org buffer when the temp buffer is opened by C-c '. I hope that is the information you need. Regards, Andreas Am 23.03.2011 04:00, schrieb Eric Schulte: This seems reasonable, Do you know how ESS associates a code buffer with a session (i.e. is there some buffer-local variable which holds the session name)? With this information in hand it shouldn't be difficult to expand the C-' behavior for R s.t. it automatically associates the resulting Org-Src buffer with the proper R session. Good idea. Best -- Eric Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, I have a feature request (if what I want is not already possible, that is). Could a source code block, which has the :session header argument, be associated with its session as soon as C-' is pressed? The background to this question is, that all ess support functionality for R (r-autoyas, autocomplete-R, and ess-eldoc) need an associated R session. They start to function only as soon as the first line of the code block is evaluated, which associates the source buffer with its session. The autocomplete-R even fails to load without an associated R session (byte-code: Language mode `R-mode' fails with: Symbol nil may not be buffer-local) and this way cuts the connection to org, such that C-' becomes undefined. Regards, Andreas smime.p7s Description: S/MIME Cryptographic Signature
[O] tangle call lines
Hi all, how do I go about to tangle a subtree full of call lines into a specific file? Of course, tangling is not execution and call lines are meant for execution, but in a scripting language (this is all about R code) the two are not too different. Basically, I would love to see the code, that gets executed by 'org-babel-execute-subtree' to be saved to a given file. Simply setting an tangle-file for the subtree does not work [fn:1]. (Which is not surprising...) But I guess I could use some pre-exec-hook together with some fine lisp code to append the expanded call line code to a given file could do the trick. I'd be grateful for any help here. Regards, Andreas Footnotes: [fn:1] A simple example: --8---cut here---start-8--- #+PROPERTY: tangle test.R I'd like to 'tangle' the 'Do all' subtree calls. * Do all :PROPERTIES: :tangle: do_all.R :END: #+call: src_b() #+call: src_a() #+call: src_c() * Source #+name: src_a #+begin_src R a - 10 #+end_src #+name: src_b #+begin_src R b - 100 #+end_src #+name: scr_c #+begin_src R plot(a, b) #+end_src --8---cut here---end---8---
Re: [O] Insert #+BEAMER_HEADER_EXTRA before \begin{document}?
Eric S Fraga e.fr...@ucl.ac.uk writes: On Thursday, 8 May 2014 at 15:38, Sebastien Vauban wrote: [...] The above things are currently (almost, for some) impossible. Changing where the #+BEAMER_HEADER placeholder gets inserted makes them possible and easy. but unfortunately would make other things more difficult. For instance, I often redefine the date command (and sometimes title and author) to do something different. If the header entries were placed after the use of theses, things would break for me. Couldn't you use #+LATEX_HEADER for that sort of thing, then? I think the creation of an ...EXTRA directive would be better but I've argued for this before and have lost that argument. I agree here. Why not make that more transparent and have #+LATEX_HEADER and #+LATEX_HEADER_END as well as #+BEAMER_HEADER and #+BEAMER_HEADER_END ? You can achieve what you want by redefining \title, I would suggest. Not pretty but it works. (Isn't that true for your use case of redefining date, too?) And last but not least: I think the particular use case of adding a short title to a beamer presentation is common enough to deserve proper org mode support. Regards, Andreas
Re: [O] Tangling with variables in R
Hi Rainer, Rainer M Krug rai...@krugs.de writes: Hi I just realized (again) that tangling with variables in R contains many particularities. 1) it only works with non-tables, i.e. single values. When defining the following variables: #+NAME: YEARS | | year | |---+---| | 1 | 1990 | | 2 | 2000 | #+PROPERTY: var+ YEARS=YEARS #+PROPERTY: var+ PRESENT=2008 I get the following code in the tangled .R file: , | YEARS - read.table(/var/folders/50/wcr5bjwn75q595n6x82gxj28gn/T/babel-97151aBD/R-import-97151vpn, | header=TRUE, | row.names=1, | sep=\t, | as.is=TRUE) | PRESENT - 2008 ` Variable transfer from tables does not work, as it is based on a temporary file, which is not easy to distribute together with the tangled.R file and requires manual work as the path will be different. I consider this as a bug which should be fixed. Me too, see http://thread.gmane.org/gmane.emacs.orgmode/51067 2) With regards to variables which are defined non-file wide, (i.e. in properties in a subtree and variables defined per code block and function call), these are set when they occur in the tangled code, but they are not unset *for the next code block* or *for R code in the next subtree* (I hope you know what I mean). They are therefore similar to the use of a session header argument instead of non-session evaluation of the code. This is a (conceptually) a more complex issue, and requires some initial thought on how this should be dealt with and how the tangled code should relate to the executed code. - Should the tangled .R file result in the same output as the execution in the org file, i.e. an accompanying .R file to a exported pdf, so that the .R file can be used to reproduce the graphs and analysis in the .pdf exported from the .org? or - Is tangling a completely thing to execution, and the resulting R code in the .R file is not expected to reproduce the results in the org file? - Finally, does tangling with variables makes sense? My opinions are a) *All* variables should be transferred to the .R file. This can be already disabled via the :no-expand header argument. Unfortunately, this is combined with noweb expansion, and it might be useful to split these two, i.e. to be able to only disable variable expansion but to keep noweb (I don't use noweb so far, so it is not a problem to me as it is now). b) The variable assignments should be per code block / function call. So a tangled block should look as follow: #+NAME: YEARS | | year | |---+---| | 1 | 1990 | | 2 | 2000 | #+PROPERTY: var+ YEARS=YEARS #+PROPERTY: var+ PRESENT=2008 #+begin_src R x - 4 cat(x^2) #+end_src should result in something like the following: , | ## # Set the variables | YEARS - TRANSFER_TABLE() | PRESENT - TRANSFER_VALUE() | ## Here begins the real code | x - 4 | cat(x^2) | ## # Unset all variables previously set ` but I prefer the following approach, as the result would be very similar, only that the variables are still present afterwards which would make debugging easier: , | ## # Unset all variables previously set | ## # Set the variables | YEARS - TRANSFER_TABLE() | PRESENT - TRANSFER_VALUE() | ## Here begins the real code | x - 4 | cat(x^2) ` This is effectively already implemented by using R environments. See [1] and particularly [2] and [3] for how it is implemented. This does not yet address the concern about the transfer of tables, but I will look at this. These are good thoughts! For the general question on whether tangling should directly reflect weaving, there was a long (and fruitless) discussion or R-devel lately. See http://thread.gmane.org/gmane.comp.lang.r.devel/36031 and maybe http://thread.gmane.org/gmane.comp.lang.r.devel/36031/focus=36075 where Yihui states that it is very hard to tangle code that produces the same result as weaving. This might actually be easier in org than in Sweave/knitr, but still the org setup will have a big impact, that would be hard to replicate in the tangled R code. Setting aside the general question: In my opinion, it should definitely be possible to tangle with variables. I think the approach of the environments to address (2) is a good one. Apologies for a long post, but I would like to know which direction of the tangling / variable transfer from org to R should take - I don't want to spend a lot of time solving a problem which does not really exist. So - any comments? Suggestions? See above. And thanks for your work on ob-R! Keep it up! Thanks, Rainer Footnotes: [1] https://github.com/rkrug/orgmode-dev [2] https://github.com/rkrug/orgmode-dev/blob/R-env/lisp/ob-R.el [3] https://github.com/rkrug/orgmode-dev/blob/R-env/etc/R/org_functions.R Best, Andreas
Re: [O] Discussion request: 15m tangle time, details follow
Hi Grant, Grant Rettke g...@wisdomandwonder.com writes: Good evening, Over the past few months I've been working on the same literate document. It has been a learning experience for me, trial and error has abounded. The key tenet that I've adhered too though is to truly embrace literate programming, and the more I learn the more it makes sense. The document has grown quite organically and it has been and continues to be a wonderful experience. What I need help, feedback, discussion, and more on is the build time. The average build takes 15m. It didn't start this way; it was about 3 minutes way back when. The last time it got kind of big was 9m and I didn't think too much of it. After literally a day of additions, it shot up to 15m. I tried upgrading to the latest org release with no change. I also removed all of the non-tangleable text with no change there, either.To give a fair picture, I did publish the system here: https://github.com/grettke/home My specific request: I need help with pointers on where I should start looking to speed things up. My goal is to have a full powered literate programming system in org mode that is blazing fast. This is from a user perspective, I use it every chance I get now and have barely scratched the surface. Right now though I'm sort of hobbled by the build time. That is actually understating it, I can't really be productive anymore at all. Little changes take 15m each and if I test it the right way, 30m. Usually I would make little changes and every so often make sure that it can rebuild itself; usually it may :). This build is documented in the github project; it only loads the absolute minimum required to do the build. Ideas: Separate the documents. Hack on org directly. Non-ideas: Faster hardware. More ram. Newer software. Details: Emacs 24.3.1. Org 8.2.6 OSX 10.9 (software updated) Darwin orion 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64 8core 2.x GHz, 16GB ram Anti-virus turned off (compliance) Please let me know any comments, questions, or concerns; looking forward to all and every thought and idea. I do not have the time to look into this, but fortunately, other have done so already ;-) Just one quick idea: Have you tried [fn:1] (setq org-babel-use-quick-and-dirty-noweb-expansion t) This can lead to dramatic speedups in my experience. Best, Andreas Where I may contribute is with time, effort, patience, cheerfulness, and experience. Kind regards, Grant Rettke | ACM, ASA, FSF, IEEE, SIAM g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson Footnotes: [fn:1] (see article.gmane.org/gmane.emacs.orgmode/50625/match=problem+noweb+ref+property)
Re: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Sebastien Vauban writes: Michael Albinus wrote: Sebastien Vauban writes: That's what I'm speaking about. And if you have a local DocView installation, it works for either remote or local files (Tramp provides a local copy of the remote file). But DocView won't display a PDF file as an image inside a buffer of text, will it? No, it uses an own buffer. OK, so we do agree that trying to open a PDF file in the context of *inline images*[1] does not make much sense, right? Are you trying to say that the org code for inline images should figure out that such a link should *not* be inlined because it would open a non-image file? I'm not sure I use the right wording, but I'm trying to say that Org (when set to open inline images) should never try to open PDF files, as they can't be opened inline in a buffer anyway. I produce most of my plots as pdfs. Removing the possibility to display them with inline image would be a loss for me. [...] - Andreas
Re: [O] [bug?] Tramp tries to open remote file links
Sebastien Vauban sva-n...@mygooglest.com writes: Andreas Leha wrote: Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Sebastien Vauban writes: Michael Albinus wrote: Sebastien Vauban writes: That's what I'm speaking about. And if you have a local DocView installation, it works for either remote or local files (Tramp provides a local copy of the remote file). But DocView won't display a PDF file as an image inside a buffer of text, will it? No, it uses an own buffer. OK, so we do agree that trying to open a PDF file in the context of *inline images*[1] does not make much sense, right? Are you trying to say that the org code for inline images should figure out that such a link should *not* be inlined because it would open a non-image file? I'm not sure I use the right wording, but I'm trying to say that Org (when set to open inline images) should never try to open PDF files, as they can't be opened inline in a buffer anyway. I produce most of my plots as pdfs. Removing the possibility to display them with inline image would be a loss for me. You mean you see your PDF images inside your Org buffer, along with the text? How did you do that? I never got any PDF displayed inside a text buffer. Neither do I. Please disregard my previous message. Clearly not enough coffee yesterday ;-) Andreas
Re: [O] BUG variable expansion with table
Hi Rainer, Rainer M Krug rai...@krugs.de writes: Hi there seems to be a bug in the table transfer. The org file below evaluates as shown, i.e. the TABLE_BLOCK contains one column less then it should as the first column is discarded and the second one used as the row names. This only occurs when there is a second variable defined. When the second variable is not passed, the code works (see second example below). I did not get far when debugging, only that in the function org-babel-R-assign-elisp when assigning TABLE_FILE the rownames are missing in the =value=. Rainer First example: #+PROPERTY: rownames yes #+PROPERTY: colnames yes #+NAME: TABLE | | name | description| |--+--+| | annee| year | Year of simulation | | id | ipoints_Qdiv | Point Number | | iespece | species | species number | | scenario | scenario | Type of forest | #+PROPERTY: var TABLE_FILE=TABLE #+PROPERTY: var+ float=123.45 * Data Assessment Results #+HEADERS: :var TABLE_BLOCK=TABLE #+HEADERS: :rownames yes #+HEADERS: :colnames yes #+begin_src R :results output wrap TABLE_FILE TABLE_BLOCK #+end_src #+RESULTS: :RESULTS: namedescription anneeyear Year of simulation id ipoints_Qdiv Point Number iespece species species number scenario scenario Type of forest Year.of.simulation ipoints_Qdiv Point Number species species number scenario Type of forest :END: Second example: #+PROPERTY: rownames yes #+PROPERTY: colnames yes #+NAME: TABLE | | name | description| |--+--+| | annee| year | Year of simulation | | id | ipoints_Qdiv | Point Number | | iespece | species | species number | | scenario | scenario | Type of forest | #+PROPERTY: var TABLE_FILE=TABLE #+ PROPERTY: var+ float=123.45 * Data Assessment Results #+HEADERS: :var TABLE_BLOCK=TABLE #+HEADERS: :rownames yes #+HEADERS: :colnames yes #+begin_src R :results output wrap TABLE_FILE TABLE_BLOCK #+end_src #+RESULTS: :RESULTS: namedescription anneeyear Year of simulation id ipoints_Qdiv Point Number iespece species species number scenario scenario Type of forest namedescription anneeyear Year of simulation id ipoints_Qdiv Point Number iespece species species number scenario scenario Type of forest :END: FWIW, I think that bug was reported some while back [fn:1] -- unfortunately without a fix ;-) - Andreas Footnotes: [fn:1] http://article.gmane.org/gmane.emacs.orgmode/82295/match=
Re: [O] org-weather for openweathermap.org
Hi Rüdiger, Rüdiger Sonderfeld ruedi...@c-plusplus.de writes: Hi, On Saturday 14 June 2014 15:11:21 Chris Raschl wrote: recently I wanted to add a weather forecast to my org-agenda. I found org-google-weather, but this package is obsolete since 2012, because the API is not available any more. So I wrote my own version which is backed by the openweathermap.org API. I've written the `weather-metno-el' package. Which uses the weather data from met.no (CC licensed). It supports showing weather data in the org-agenda as well. https://github.com/ruediger/weather-metno-el Regards, Rüdiger just trying this package. Also really nice! Thanks for sharing. I have a few questions/comments/feature requests, though: 1. Documentation of available targets. I wanted to include the wind speed. Looking at the schema [fn:1] I tried 'windspeed' which did not work. It took some time until I found the 'weather-metno--data' variable, which revealed that it is 'windSpeed' instead. Some table with all the available measurements would be handy. | parameter | representation | unit | example | |---+++---| | windSpeed | name | string | Svak vind | 2. How can I get a textual representation of the symbol? I would like to get (additionally to the symbol) get a textual description (like 'partly cloudy'). I did not see an obvious way how to get that. 3. Two or three entries per day How can I have two (night/day) or better three (night/morning/afternoon) entries for each day? I would like these to sum user-defined times. E.g. night: 20-08, morning: 08-13 and afternoon 13:20. Is that (easily) possible? 4. The org agenda entry does not point to anything. It would be cool (I think) if the org agenda entry pointed to a *Weather* buffer with detailed information from weather-metno-forecast 5. The Readme for the manual installation could remind the user to put (require 'weather-metno) (require 'org-weather-metno) in the .emacs 6. The documentation of 'org-weather-metno-format' points to 'weather-query-format' which should probably be 'weather-metno-query-format' Regards, Andreas Footnotes: [fn:1] http://api.met.no/weatherapi/locationforecast/1.9/schema
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: Hi List, evaluating this 3 times does not work as expected: , | * A | | #+header: :results raw replace | #+begin_src emacs-lisp | (+ 2 2) | #+end_src | | #+results: | 4 | 4 | 4 ` Independent from argument order, 'replace' (which should be default anyway) is ignored. Try adding the :wrap, which works for me: , | * A | | #+header: :results raw replace :wrap | #+begin_src emacs-lisp | (+ 2 2) | #+end_src | | #+results: | #+BEGIN_RESULTS | 4 | #+END_RESULTS ` Regards, Andreas
Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: Hi List, evaluating this 3 times does not work as expected: , | * A | | #+header: :results raw replace | #+begin_src emacs-lisp | (+ 2 2) | #+end_src | | #+results: | 4 | 4 | 4 ` Independent from argument order, 'replace' (which should be default anyway) is ignored. Try adding the :wrap, which works for me: , | * A | | #+header: :results raw replace :wrap | #+begin_src emacs-lisp | (+ 2 2) | #+end_src | | #+results: | #+BEGIN_RESULTS | 4 | #+END_RESULTS ` This actually works here too, thanks. But is this wrapping results block 'neutral', i.e. is its content treated just like raw Org syntax in all situations? E.g. when I create a dblock from elisp, would #+results: #+BEGIN_RESULTS #+begin my-dblock (foo) #+end #+END_RESULTS be equivalent to #+results: #+begin my-dblock (foo) #+end in all cases? However, the combo ':results raw replace' seems like the natural fit when programmatically creating content in an Org file with a src_block that might eventually be evaluated more than once. That it does not work 'as-is' seems too much of a surprise to not call it a bug (at least when the manual does not mention it as special case). My use-case is actually this, and it won't work with wrapped results: , | ** Utility Function :ARCHIVE: | | #+name: create-subtree-with-dblock | #+header: :var name=foo | #+header: :var prms=:bar loo | #+header: :results replace raw | #+begin_src emacs-lisp | (format |(concat \n\n** Overview :READONLY:\n\n | #+begin: %s %s\n\n#+end:\n) | name prms) | #+end_src | | #+results: dblock | | | ** Overview :READONLY: | | #+begin: foo :bar loo | | #+end: ` I am not in the position to answer this. But the combo raw replace is problematic, I think, in that it is hard to say how much there is to be replaced. So I think some delimiters (as produced by :wrap) are necesarry in the general case. If I understand correctly, you want to nest blocks: A source block nested in a results block. I think, that is not possible. So, for that use case, I guess, another construct (other than results block) would be necessary. But other people might have the proper answer here... Regards, Andreas
Re: [O] proposal to make C-c C-c not remove latex overlays
Hi all, John Kitchin jkitc...@andrew.cmu.edu writes: I am using org-mode files with equations and code blocks in lectures, and it is problematic that C-c C-c removes the equation overlays when running a code block. First, you have to press C-c C-c twice to run the block, since the first one gets rid of the equations, but then you have run C-c C-x C-l to get the equations back! and the cycle repeats throughout a lecture. I would prefer that the equations stay untouched, and that the code blocks run without modifying them. I think the best behavior would be for C-c C-x C-l to toggle the equations, and to remove the C-c C-c behavior for latex overlays completely. Since this thread focusses on work arounds and local customizations so far, let me just say, that I completely agree here. What is the reasoning behind the current key binding? Is there any benefit over using the same key binding to toggle the state? [...] Regards, Andreas
Re: [O] turn off monospace in src result
Hi regcl,
regcl re...@channing.harvard.edu writes:
With this line in my .org file ...
This is src_R{foo-FOO; paste(foo)}.
... when I publish to html or pdf, I get ...
This is FOO.
... which is wonderful, except that FOO is monospace.
Can I turn off monospace for all results of inline source?
I do not know, how to do that for all inline source blocks. But you can
turn it off
1. per code block as in src_R[:results raw]{foo-FOO; paste(foo)}
2. globally for all block as in '#+PROPERTY: results raw'
(then you would override this setting per non-inline code block)
HTH,
Andreas
Re: [O] turn off monospace in src result
Hi Nick,
Nick Dokos ndo...@gmail.com writes:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi regcl,
regcl re...@channing.harvard.edu writes:
With this line in my .org file ...
This is src_R{foo-FOO; paste(foo)}.
... when I publish to html or pdf, I get ...
This is FOO.
... which is wonderful, except that FOO is monospace.
Can I turn off monospace for all results of inline source?
I do not know, how to do that for all inline source blocks. But you can
turn it off
1. per code block as in src_R[:results raw]{foo-FOO; paste(foo)}
Looks like
This is src_R[:results raw]{foo-FOO; paste(foo)}.
produces a newline after the evaluated code block in the HTML file,
which is rendered as a space between the word FOO and the period. Bug?
I tend to agree. There was some discussion on this last year [fn:1] that went
dead after a while. I still think that modifying raw results (as in
adding newline) should be avoided -- at least in inline source blocks.
Regards,
Andreas
Footnotes:
[fn:1] http://article.gmane.org/gmane.emacs.orgmode/71385
Re: [O] Evaluating inline source blocks on export issue
Nick Dokos ndo...@gmail.com writes: Grant Rettke g...@wisdomandwonder.com writes: Thanks for looking Thomas and Nick. When I set this and export , | (setq org-export-babel-evaluate t) ` I get the expected result of , | Here is a `16', stuck in the middle of some prose. ` But when I do this and export , | (setq org-export-babel-evaluate 'inline-only) ` I get this output which is not what I expected , | Here is a , stuck in the middle of some prose. ` I thought that I was enabling inline code block execution correctly and making the inline call correctly. How does it look should it be doing what I had wanted? I don't think you can: the `type' (see below) of the inline code is not `inline' as one might think at first, but `lob', presumably because call_foo is defined in the library-of-babel. The relevant code is in ob-exp.el:org-babel-exp-results: , | ... | (when (and (or (eq org-export-babel-evaluate t) | (and (eq type 'inline) | (eq org-export-babel-evaluate 'inline-only))) | (not (and hash (equal hash (org-babel-current-result-hash) | ... ` Then I would like to turn this into a feature request: Enable inline-block-specific settings. This does not only hold for the evaluation, but also for default header arguments. Different settings for inline code are quite useful. I do have to specify [:results raw] on the block-to-block basis quite a lot and would benefit a lot from global inline-specific settings. As always, point me to the way to do it, if (quite likely) this is possible already. Regards, Andreas
Re: [O] Possible to use src block to generate org headlines for export?
Hi all, Nick Dokos ndo...@gmail.com writes: Charles Berry ccbe...@ucsd.edu writes: Matt Lundin mdl at imapmail.org writes: [deleted] Footnotes: [fn:1] If one really needs to see the headlines in the original org buffer, a hook can be used to remove the :RESULTS: drawer. --8---cut here---start-8--- (defun my-remove-stray-results-drawer (backend) (when (eq backend 'html) (while (re-search-forward ^\\s-*:RESULTS:\\s-*\n nil t) (replace-match (add-hook 'org-export-before-parsing-hook 'my-remove-results-drawer) --8---cut here---end---8--- Or wrap the results in a drawer when you type C-c C-c, but render them as raw on export (which removes the drawer and replaces with raw results). Like so: #+header: :results (if (boundp 'backend) raw drawer) #+BEGIN_SRC emacs-lisp :exports both (format * headline\n1\n2\n5\n) #+END_SRC That's a very nice tip - one small weakness is that it'll do the wrong thing if you just happen to have a binding for backend outside of the export mechanism. Is that a valid feature request: Allow the combination of :results raw and :results replace -- regardless of the produced content? IIUC the parser does not allow this right now. But (without any knowledge on the parser) I can imagine 'special' results drawers that do not have any function/effect other than delimiting babel results (plus possibly folding). If these existed, I would even enable them by default no matter of 'raw' or not. Something like this: --8---cut here---start-8--- #+name: some_code #+begin_src sh echo hello world #+end_src #+begin_results some_code : hello world #+end_results --8---cut here---end---8--- Regards, Andreas
Re: [O] Possible to use src block to generate org headlines for export?
Hi Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: Is that a valid feature request: Allow the combination of :results raw and :results replace -- regardless of the produced content? IIUC the parser does not allow this right now. But (without any knowledge on the parser) I can imagine 'special' results drawers that do not have any function/effect other than delimiting babel results (plus possibly folding). If these existed, I would even enable them by default no matter of 'raw' or not. No matter how special the results drawer is, it cannot (and shouldn't) contain headlines. You are the master of the parser... There are a few options to mark raw output even with headlines: 1. Use text properties to mark the part of the buffer generated by a given source block. The main drawback is that Org is not just plain text anymore (some information is hidden and cannot be found just looking at the text). 2. Use comment cookies around the area: # Raw Babel Output : src-name (begin) * Some headline # Raw Babel Output : src-name (end) This is not very pretty. Also, it may be difficult to handle overlapping changes around the same region. OTOH, headlines are the only limitation to raw+replace behaviour. Some decent workarounds to this problem were offered in this thread. We can also live with it. IIUC, you are saying that raw+replace is possible right now for any content in the results (other than headlines), if the results are in a drawer? Then, my follow-up question is simply, why are drawers not the default for results, then? Is there any drawback (apart from an additional line)? Regards, Andreas
Re: [O] Possible to use src block to generate org headlines for export?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: No matter how special the results drawer is, it cannot (and shouldn't) contain headlines. You are the master of the parser... That's why I carefully avoid shooting myself in the foot. There is (at least) a good reason why only headlines can contain headlines, which is speed, as a consequence of CFG. IIUC, you are saying that raw+replace is possible right now for any content in the results (other than headlines), if the results are in a drawer? If the results are in a drawer, this is not raw anymore, but drawer. Anyway you can put anything in your drawer besides a headline and another drawer. But then, I do not understand your statement 'headlines are the only limitation to raw+replace behaviour'. This code block does not seem to respect 'raw+replace' for me: #+name: dtrn #+BEGIN_SRC R :results raw replace nwords - 500 nletters - sapply(1:nwords, function(i) sample(1:10, 1)) words - sapply(nletters, function(i) paste(sample(letters, i), collapse=)) words[sample(nwords, 100)] - \n paste(words, collapse= ) #+END_SRC Then, my follow-up question is simply, why are drawers not the default for results, then? Is there any drawback (apart from an additional line)? The block may insert a headline, or another drawer, within the results drawer, thus breaking the document. I understand that. Will update my local 'defaults' then to drawer. Regards, Andreas
Re: [O] Possible to use src block to generate org headlines for export?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: But then, I do not understand your statement 'headlines are the only limitation to raw+replace behaviour'. This code block does not seem to respect 'raw+replace' for me: #+name: dtrn #+BEGIN_SRC R :results raw replace nwords - 500 nletters - sapply(1:nwords, function(i) sample(1:10, 1)) words - sapply(nletters, function(i) paste(sample(letters, i), collapse=)) words[sample(nwords, 100)] - \n paste(words, collapse= ) #+END_SRC That was not clear, indeed. raw behaviour is only useful (i.e., mandatory) when you want to insert a headline (or a drawer) as a result of a code block evaluation. But then, you lose the ability to replace results. That's the limitation I'm talking about. In any other case, drawer+replace is the superior choice. Thanks for this clarification. But in that case let me return to and refine my proposal: Why not have drawer as the default unless raw is given? One could argue, that the extent of the results is implicitly given when the results are not raw, but being explicit here would allow for some additional features (such as different background for results -- is anyone doing this? I'd be interested). One could also argue, that the users are free to put their results in drawers if they wish. But on the other hand what would be lost by defaulting to drawers? main part ends here Having said all that, I want to add, that I do not particularly like the visual appearance of drawers for results blocks; I think they - add one more line than necessary and they - differ too much from the appearance of source blocks This is the state in org This is what I'd prefer... --8--start8--- --8--start8--- #+PROPERTY: results drawer #+PROPERTY: results drawer * Test * Test #+name: dtrn #+name: dtrn #+begin_src R :exports both#+begin_src R :exports both hellohello #+end_src #+end_src #+results: dtrn :RESULTS: #+begin_results dtrn hello hello :END: #+end_results --8---end-8--- --8---end-8--- But do not take this too seriously. I am more than happy to live with the standard appearance of drawers here. Regards, Andreas
Re: [O] Possible to use src block to generate org headlines for export?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: But in that case let me return to and refine my proposal: Why not have drawer as the default unless raw is given? Probably because raw never breaks your document, and is less verbose in the simplest cases (e.g., a single list, value, table...), which may be common enough. Anyway, it should be simple enough to switch to drawer as a default in your setup. True. One could argue, that the extent of the results is implicitly given when the results are not raw, but being explicit here would allow for some additional features (such as different background for results -- is anyone doing this? I'd be interested). raw doesn't prevent to add a different background, if needed. I'd be very interested in that. This is the state in org This is what I'd prefer... --8--start8--- --8--start8--- #+PROPERTY: results drawer #+PROPERTY: results drawer * Test * Test #+name: dtrn #+name: dtrn #+begin_src R :exports both#+begin_src R :exports both hellohello #+end_src #+end_src #+results: dtrn :RESULTS: #+begin_results dtrn hello hello :END: #+end_results --8---end-8--- --8---end-8--- What you prefer is a special block, which is not neutral during export process. Of course, a result block type could be added to Org syntax, but that would be redundant with drawers. Thanks for your comment on this. Yes, a special block is indeed what I'd prefer visually. And a result block type could be non-redundant with drawers if it was allowed to contain headlines and drawers ;-) But let's leave it there. As I said: I am quite fine with the drawers. Regards, Andreas
Re: [O] meaningfull names for org-src buffers
Hi, Grant Rettke g...@wisdomandwonder.com writes: On Thu, Sep 11, 2014 at 5:05 PM, Adriaan Sticker adriaan.stic...@gmail.com wrote: I was wondering if it's somehow possible to give named org src buffer the name they were give in their #+NAME tag? Now there are just called something like: *Org Src test.org[ R ]* But if you have multiple org-src buffers opened at the same time, its hard to find the correct one back. Excellent idea. I've got so many small source blocks that it is too difficult to make sense of keeping multiple source block edit buffers open and limit them to one at a time eg , | (setq org-src-window-setup 'current-window) ` How have you come upon your workflow of keeping multiple open and what are some of the pros and cons that you've found with it? I'd be interested in this as well. Regards, Andreas
Re: [O] meaningfull names for org-src buffers
Hi Adriaan, Adriaan Sticker adriaan.stic...@gmail.com writes: Well, I ussually just try to live with this limitation. :) I try to C-c ' in and out src block whenever possible so my my list with buffer names doesnt get to cluttered. Im also thinking about investigating the usefullness of polymode (https://github.com/vitoshka/polymode) So I dont have to go to a different buffer all the time. Do you have any experience with this? I have finally looked into this some weeks back. And got emacs lock up. To quote from the author [fn:1]: , | The work on polymode got stuck a bit as Emacs folks strongly discourage | inderect buffer usage. So I will have to remove indirect buffers from | the picture. This will solve all the font-locking problems as the one | you have described. ` I am looking forward to testing any next version, though. Regards, Andreas Footnotes: [fn:1] http://article.gmane.org/gmane.emacs.ess.general/8342/match=polymode
Re: [O] autosave in org-src buffer only works ones
Hi Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Adriaan Sticker adriaan.stic...@gmail.com writes: I've the following in my init.el (setq org-edit-src-auto-save-idle-delay 5) If I open in my org file a R code block with C-c ', edit into the opened org-src buffer with the ESS major mode activated and wait for 5s, I can see autosave kicking in and my org buffer gets updated with my new code. But when I keep editing it doesn't save anymore. So it only save ones after the first 5s when the org-src got openend and then it stops. This should now be fixed. Thank you for reporting it. Just a second 'thanks'! Andreas
Re: [O] [ANN] org-bandbook - Professional Band Management for Computer Literate Musicians
Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: Hi List, see the attached ASCII version of org-bandbook.el's comment section for more info: ___ ORG-BANDBOOK Thorsten Jolitz tjol...@gmail.com ___ Ups, forgot to mention the core command ;) , | M-x org-bandbook-make-bandbook ` to produce the PDF. This sounds interesting (pun intended). I might be interested. Would you be able to provide an example to play with? Regards, Andreas
Re: [O] meaningfull names for org-src buffers
Hi Charles, Charles Berry ccbe...@ucsd.edu writes: Andreas Leha andreas.leha at med.uni-goettingen.de writes: Hi, Grant Rettke gcr at wisdomandwonder.com writes: On Thu, Sep 11, 2014 at 5:05 PM, Adriaan Sticker adriaan.sticker at gmail.com wrote: I was wondering if it's somehow possible to give named org src buffer the name they were give in their #+NAME tag? Now there are just called something like: *Org Src test.org[ R ]* But if you have multiple org-src buffers opened at the same time, its hard to find the correct one back. Excellent idea. I've got so many small source blocks that it is too difficult to make sense of keeping multiple source block edit buffers open and limit them to one at a time eg , | (setq org-src-window-setup 'current-window) ` How have you come upon your workflow of keeping multiple open and what are some of the pros and cons that you've found with it? I'd be interested in this as well. Regards, Andreas Maybe I am answering the wrong question, but org-edit-src-code allows you to specify the buffer name: You are answering my exact question. ,[ C-h f org-edit-src-code RET ] | org-edit-src-code is an interactive compiled Lisp function in | `org-src.el'. | | (org-edit-src-code optional CONTEXT CODE EDIT-BUFFER-NAME) | | ... ` So you can do something like this: #+BEGIN_SRC emacs-lisp (defun org-edit-src-code-plus-name () (interactive) (let* ((eop (org-element-at-point)) (name (or (org-element-property :name (org-element-context eop)) unnamed)) (lang (org-element-property :language eop)) (buff-name (concat *Org Src name [ lang ] *))) (org-edit-src-code nil nil buff-name))) #+END_SRC which leads to a buffer named like *Org Src My-block[ R ] *, where 'My-block' is the name of the src block. Thanks! On my first quick tests that works great! It is in my initialization and I'll use that regularly. Is there any drawback to this? Otherwise I'd advocate for org-edit-src-code doing that by default. HTH, It sure does. Thanks, Andreas
Re: [O] Set org-todo-keywords as file-local variables
Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: Hi List, I set 'org-todo-keywords' as file-local variables in a file, and 'C-h v org-todo-keywords' in that file's buffer suggests I was successfull: , | org-todo-keywords is a variable defined in `org.el'. | Its value is shown below. | | This variable's value is file-local. | | Documentation: [...] | Value: | ((sequence | E(e) X(x) C(c) R(r) M(m))) | | Original value was | ((sequence TODO DONE)) | | Local in buffer foo-test.org; global value is | ((sequence TODO(t) NEXT(n) | DONE(d!/!)) | (sequence WAITING(w@/!) HOLD(h@/!) | CANCELLED(c@/!) PHONE)) | | [back] ` but when doing C-c C-t in that buffer, 'org-todo' still offers me the usual selection menu based on the variable's global value. Am I missing something here? I have some files with locally set todo keywords. I use a different interface through: --8---cut here---start-8--- #+TODO: TODO(t) WAITING(w!) | DONE(d!) CANCELED(c@/!) --8---cut here---end---8--- Does that help? Andreas
Re: [O] Make * bold or use colour for export to html and LaTeX
Hi Rainer, Rainer M Krug rai...@krugs.de writes: Hi I want to highlight the cells in the table below with *** by using color red for the font, **' by using green for the font, ... or, if not possible, bold. Is any of this possible? The table is generated in R, so the ascii package might help (just thinking about it while typing)? Thanks, Rainer || slope | intercept | p | pm |pb | |++---+---+--+---| | quercus_robur.single | -1.358 | 4.76 | | | | | quercus_robur.95 | -1.957 | 5.71 | 3.96e-21 *** | 7.47e-07 *** | 7.60e-09 *** | | quercus_robur.90 | -1.752 | 5.42 | 3.43e-02 *| 7.18e-02 . |4.79e-02 * | | quercus_robur.85 | -1.773 | 5.41 | 4.11e-01 | 8.33e-01 | 9.38e- I am not sure to understand your question correctly, but if the table is R generated anyway, why not use R to provide the formatting for org? Like -- as a start -- this function, that does the simplest of those and replaces *** with bold: --8---cut here---start-8--- boldpattern - \\*\\*\\*$ tbl - apply(tbl, 2, function(x) ifelse(grepl(boldpattern, x), paste0(*, gsub(boldpattern, , x), *), x)) --8---cut here---end---8--- Here as full example in action: --8---cut here---start-8--- ## -- ## ## create a table ## ## -- ## ## from ?lm ctl - c(4.17,5.58,5.18,6.11,4.50,4.61,5.17,4.53,5.33,5.14) trt - c(4.81,4.17,4.41,3.59,5.87,3.83,6.03,4.89,4.32,4.69) group - gl(2, 10, 20, labels = c(Ctl,Trt)) weight - c(ctl, trt) lm.D9 - lm(weight ~ group) lm.D90 - lm(weight ~ group - 1) # omitting intercept ## extract the coefficients tbl - summary(lm.D90)$coefficients ## add the signif codes tbl[,4] - paste(tbl[,4], symnum(tbl[,4], corr = FALSE, na = FALSE, cutpoints = c(0, 0.001, 0.01, 0.05, 0.1, 1), symbols = c(***, **, *, ., ))) tbl ## -- ## ## make them 'org-bold' ## ## -- ## boldpattern - \\*\\*\\*$ tbl - apply(tbl, 2, function(x) ifelse(grepl(boldpattern, x), paste0(*, gsub(boldpattern, , x), *), x)) tbl --8---cut here---end---8--- HTH, Andreas PS: The usual don't use the signif.codes applies.
Re: [O] Make * bold?
Hi Rainer,
Rainer M Krug rai...@krugs.de writes:
Andrea Rossetti andrea.rosse...@gmail.com writes:
Rainer M Krug Rainer at krugs.de writes:
I would like to make three stars bold - is this possible? I have the
following table and at the moment, I get what is in the latex
column. But I would like to have what is in the last column.
| org | latex| what I would like |
| *3.96e-21 *** * | \textbf{3.96e-21 **} * | \textbf{3.96e-21 ***} |
...
Any suggestions?
Hi! using the pretty entity \ast{} works for me in HTML and PDF:
| *3.96e-21 \ast{}\ast{}\ast{}* |
Does it work for you too? Regards, Andrea
Thanks - it does, indeed. Strange that it works for both export
backends.
But there are a few formating issues with this:
1) in tex, the spacing between two is different to the spacing between
three
2) in html, the asterix are at the bottom and
3) it is not very readable in org.
To help with 3) have a look at http://orgmode.org/manual/Special-symbols.html
(esp. C-c C-x \)
Best,
Andreas
[O] [ob-R] table variable passing broken
Hi all, There seems to be a bug in table passing as variables now using the tangle-friendly version of passing variables. Here is an example (I get an error also with emacs -Q): --8---cut here---start-8--- * test #+name: testtab | variable | display | unit | |---+---+---| | num_cells | Number of Cells in Well | | | cell_area | Cell Area | μm² | | nucleus_area | Nucleus Area | μm² | | roundness | Cell Roundness| | | ratio_w2l | Cell Width to Length Ratio| | | inten_nuc_dapi_median | Intensity Nucleus DAPI Median | | | dapi_median | Intensity Nucleus DAPI Median | | | edu_median| Intensity edu Median | | | oct4_median | Intensity oct4 Median | | | clump_size| Clump Size| cells | | short_name| Cell Line | | | p_col | Column| | | batch | Batch | | | concentration | Fibronectin Concentration | ugml | | Residual | Residual | | | evaluation_guid | Plate | | | donor | Genotype | | #+BEGIN_SRC R :session *test* :var test=testtab test #+END_SRC #+RESULTS: --8---cut here---end---8--- I see this in my R session: --8---cut here---start-8--- Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, (from testorg.org!917613Wp#22) : line 17 did not have 3 elements --8---cut here---end---8--- This is on - GNU Emacs 24.4.50.1 (x86_64-apple-darwin13.3.0, NS appkit-1265.21 Version 10.9.4 (Build 13E28)) of 2014-09-02 on mib106584i.local - Org-mode version 8.3beta (release_8.3beta-470-g087f8e) - ess-version: 14.05 [git: 4283f1304a54502c42707b6a4ba347703f0992dd] Best, Andreas
Re: [O] [RFC] Change property drawer syntax
Hi Nicolas, My only 'concern' is that it looks awkward or at least unfamiliar when the property drawer is closed (which it is always in my documents). I guess than it would change from *** Call XXX :PROPERTIES:... 2014-10-16 Thu 13:00-14:00 to *** Call XXX 2014-10-16 Thu 13:00-14:00 :PROPERTIES:... which has a folded item 'in the middle of text' rather than right below the heading. I'll get used to that, I guess. Regards, Andreas Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, As discussed previously, I would like to modify property drawers syntax. The change is simple: they must be located right after a headline and its planning line, if any. Therefore the following cases are valid * Headline :PROPERTIES: :KEY: value :END: * Headline SCHEDULED: 2014-10-14 mar. :PROPERTIES: :KEY: value :END: but, in the following case, the scheduled keyword will not be recognized * Headline :PROPERTIES: :KEY: value :END: SCHEDULED: 2014-10-14 mar. When not empty, they also have to contain only node properties. Moreover, node properties' keys can only contain non-whitespace characters and cannot end with a plus sign (which is used for accumulation). Value can contain anything but a newline character. Thus, the following property drawer is invalid * Headline :PROPERTIES: :KEY: value Some text. :END: Any invalid property drawer becomes de facto a regular drawer, with PROPERTIES as its name. Besides defining exactly the syntax of property drawers, it should also make the property API faster in some cases. Indeed, there's no need to search through entire (possibly huge) sections in order to find properties attached to a headline. However, it will break some Org documents. In particular, TODO-states changes are usually logged before any drawer, including properties drawers. The following function repairs them. (defun org-repair-property-drawers () Fix properties drawers in current buffer. Ignore non Org buffers. (when (eq major-mode 'org-mode) (org-with-wide-buffer (goto-char (point-min)) (let ((case-fold-search t) (inline-re (and (featurep 'org-inlinetask) (concat (org-inlinetask-outline-regexp) END[ \t]*$ (org-map-entries (lambda () (unless (and inline-re (org-looking-at-p inline-re)) (save-excursion (let ((end (save-excursion (outline-next-heading) (point (forward-line) (when (org-looking-at-p org-planning-line-re) (forward-line)) (when (and ( (point) end) (not (org-looking-at-p org-property-drawer-re)) (save-excursion (re-search-forward org-property-drawer-re end t))) (insert (delete-and-extract-region (match-beginning 0) (min (1+ (match-end 0)) end))) (unless (bolp) (insert \n Internally, changes are somewhat invasive, as they include a rewrite of almost all the property API. They also alter clocking, tags, todo keywords, logging, initialization, hopefully in an invisible manner. I pushed a new branch, top-properties in the repository for code review and testing. It includes unit tests, documentation and an ORG-NEWS entry. Feedback welcome. Regards,
Re: [O] [ob-R] table variable passing broken
Charles Berry ccbe...@ucsd.edu writes: Andreas Leha andreas.leha at med.uni-goettingen.de writes: Hi all, There seems to be a bug in table passing as variables now using the tangle-friendly version of passing variables. Here is an example (I get an error also with emacs -Q): --8---cut here---start-8--- * test #+name: testtab | variable | display | unit | |---+---+---| | num_cells | Number of Cells in Well | | | cell_area | Cell Area | μm² | | nucleus_area | Nucleus Area | μm² | | roundness | Cell Roundness| | | ratio_w2l | Cell Width to Length Ratio| | | inten_nuc_dapi_median | Intensity Nucleus DAPI Median | | | dapi_median | Intensity Nucleus DAPI Median | | | edu_median| Intensity edu Median | | | oct4_median | Intensity oct4 Median | | | clump_size| Clump Size| cells | | short_name| Cell Line | | | p_col | Column| | | batch | Batch | | | concentration | Fibronectin Concentration | ugml | | Residual | Residual | | | evaluation_guid | Plate | | | donor | Genotype | | #+BEGIN_SRC R :session *test* :var test=testtab test #+END_SRC #+RESULTS: --8---cut here---end---8--- I see this in my R session: --8---cut here---start-8--- Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, (from testorg.org!917613Wp#22) : line 17 did not have 3 elements --8---cut here---end---8--- I think this is the wrong diagnosis. I agree. Saving the table as tsv (via org-table-export) results in a file that cannot be read from R either. Did you actually revert to the earlier version of ob-R.el to confirm that this would have run correctly? I did not revert. But that org file used to work. I won't be able to bisect any time soon. The reason I ask is that I just tried this with org-babel-R-assign-elisp from org-mode-a5686d87786b1d6514ec85959a2188f703346a06/lisp/ob-R.el and got the same error. Note this: #+name: testtab2 | variable | display | unit | |--+--+--| | donor| Genotype | | #+BEGIN_SRC emacs-lisp :var test=testtab2 (orgtbl-to-tsv test '(:fmt org-babel-R-quote-tsv-field)) #+END_SRC #+RESULTS: : donor Genotype exactly. That also causes the org-table-export to fail. #+BEGIN_SRC emacs-lisp :var value=testtab2 ;; from org-babel-R-assign-elisp (mapcar 'length (org-remove-if-not 'sequencep value)) #+END_SRC #+RESULTS: | 3 | In particular, the empty table cells are omitted even though `value' or `test' has all lengths as 3. This results in calling read.table ( ..., fill=FALSE) implicitly. Not sure if the fix is to retool org-babel-R-assign-elisp or something in org-table.el. I am the wrong person to answer that. But it looks to me to be an issue for org-table.el. Thanks for your better analysis. Regards, Andreas
Re: [O] [ob-R] table variable passing broken
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Charles Berry ccbe...@ucsd.edu writes: Andreas Leha andreas.leha at med.uni-goettingen.de writes: Hi all, There seems to be a bug in table passing as variables now using the tangle-friendly version of passing variables. Here is an example (I get an error also with emacs -Q): --8---cut here---start-8--- * test #+name: testtab | variable | display | unit | |---+---+---| | num_cells | Number of Cells in Well | | | cell_area | Cell Area | μm² | | nucleus_area | Nucleus Area | μm² | | roundness | Cell Roundness| | | ratio_w2l | Cell Width to Length Ratio| | | inten_nuc_dapi_median | Intensity Nucleus DAPI Median | | | dapi_median | Intensity Nucleus DAPI Median | | | edu_median| Intensity edu Median | | | oct4_median | Intensity oct4 Median | | | clump_size| Clump Size| cells | | short_name| Cell Line | | | p_col | Column| | | batch | Batch | | | concentration | Fibronectin Concentration | ugml | | Residual | Residual | | | evaluation_guid | Plate | | | donor | Genotype | | #+BEGIN_SRC R :session *test* :var test=testtab test #+END_SRC #+RESULTS: --8---cut here---end---8--- I see this in my R session: --8---cut here---start-8--- Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings, (from testorg.org!917613Wp#22) : line 17 did not have 3 elements --8---cut here---end---8--- I think this is the wrong diagnosis. I agree. Saving the table as tsv (via org-table-export) results in a file that cannot be read from R either. Did you actually revert to the earlier version of ob-R.el to confirm that this would have run correctly? I did not revert. But that org file used to work. I won't be able to bisect any time soon. The reason I ask is that I just tried this with org-babel-R-assign-elisp from org-mode-a5686d87786b1d6514ec85959a2188f703346a06/lisp/ob-R.el and got the same error. Note this: #+name: testtab2 | variable | display | unit | |--+--+--| | donor| Genotype | | #+BEGIN_SRC emacs-lisp :var test=testtab2 (orgtbl-to-tsv test '(:fmt org-babel-R-quote-tsv-field)) #+END_SRC #+RESULTS: : donorGenotype exactly. That also causes the org-table-export to fail. #+BEGIN_SRC emacs-lisp :var value=testtab2 ;; from org-babel-R-assign-elisp (mapcar 'length (org-remove-if-not 'sequencep value)) #+END_SRC #+RESULTS: | 3 | In particular, the empty table cells are omitted even though `value' or `test' has all lengths as 3. This results in calling read.table ( ..., fill=FALSE) implicitly. Not sure if the fix is to retool org-babel-R-assign-elisp or something in org-table.el. I am the wrong person to answer that. But it looks to me to be an issue for org-table.el. Thanks for your better analysis. Regards, Andreas To keep this issue going, here a quick thought: Since orgtbl-to-csv seems to work, a temporary fix on ob-R's side would be to use that for passing of tables. Andreas
Re: [O] Using sessions.
Hi Thierry, abonnements abonneme...@thierry-pelle.eu writes: Hi, I would like to know if it is possible to desactivate a previously open session. Example : * Test :PROPERTIES: :HEAGER-ARGS: :session SESS-TEST :END: some code in session mode #+begin_src python ... some code for which I dont what to use the session. #+end_src Is there something like :session NONE or :session DISABLE? There is: :session none Best, Andreas
[O] math in parentheses
Hi,
I encounter a problem using $..$ expressions when they are enclosed
in parentheses.
This sample
--8---cut here---start-8---
#+TITLE: Test Math
* Some math
This $T$ works, but ($T$) this does not.
--8---cut here---end---8---
exports to (relevant part)
--8---cut here---start-8---
\section{Some math}
\label{sec-1}
This \(T\) works, but (\$T\$) this does not.
--8---cut here---end---8---
Is that expected behaviour?
(Note that \(...\) expressions work.)
I am on
- OS X 10.9.4
- GNU Emacs 24.4.50.1
- Org-mode version 8.3beta
Regards,
Andreas
[O] BUG: preview latex with split environment
Hi all,
I encounter a BUG with org-toggle-latex-fragment on an equation that
uses amsmath's split environment.
(Exporting of the document works fine.)
The problem is that the \begin{equation},\end{equation} get stripped of
the temporary tex file.
Here is some test doc
--8---cut here---start-8---
#+TITLE: Test amsmath's split
* Some equation
with some split expression, e.g.
\begin{equation}
\begin{split}
w \cdot x + b = 1, \text{ and}\\
w \cdot x + b = -1
\end{split}
\end{equation}
To reproduce try to org-toggle-latex-fragment (C-c C-x C-l) on that
latex expression.
Export of this works fine.
--8---cut here---end---8---
which results in this /tmp/foobar.tex document (relevant parts shown):
--8---cut here---start-8---
\begin{document}
\definecolor{fg}{rgb}{0.996109,0.996109,0.996109}
\definecolor{bg}{rgb}{0.197269,0.197269,0.197269}
\pagecolor{bg}
{\color{fg}
\begin{split}
w \cdot x + b = 1, \text{ and}\\
w \cdot x + b = -1
\end{split}
}
\end{document}
--8---cut here---end---8---
The compilation of that results in
,
| ERROR: Package amsmath Error: \begin{split} won't work here.
| ...
| \Did you forget a preceding \begin{equation}?
`
Regards,
Andreas
Re: [O] math in parentheses
Hi Richard, Richard Lawrence richard.lawre...@berkeley.edu writes: Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: I encounter a problem using $..$ expressions when they are enclosed in parentheses. This $T$ works, but ($T$) this does not. Is that expected behaviour? (Note that \(...\) expressions work.) Yes, that is the expected behavior. Org is much pickier about when $ can be a math delimiter than \( ... \). The reason is that $ can also be used as a regular symbol in Org documents; when it is, it should be *not* be exported as a math delimiter to LaTeX, and distinguishing non-math-delimiting from math-delimiting uses of $ is not a trivial matter. Thus, when in doubt, use \( ... \). Thanks for following that up. I do use \(...\) when I encounter problems with $...$ (which is a lot nicer to type and read). I am happy with using the fall-back \(...\) every now and then. Just for me to understand: Is the problem the missing whitespace around the $...$ expression? Thanks, Andreas
