Re: [O] New Exporter html - latex - beamer
Robert Eckl eck...@gmx.de writes:
Eric S Fraga e.fr...@ucl.ac.uk writes:
Robert Eckl eck...@gmx.de writes:
I have to provide weekly newsletters in the format pdf and html. Up to
now i did this with exporting to scrartcl, known as koma-script.
Including images is a bit booring because i handle two formats, for example
I am not sure what your latex bits are trying to accomplish so it's
difficult to advise on how to achieve what you want. Maybe wrapfigure,
which org export supports (float option, I believe, but I am not sure),
is what you need instead of window?
The latex bits are doing what they should. |-|
I don't want the image floating, because | |
the text regularly is small. The image | |
will be placed how you can see here. |-|
Here the text goes over the complete line - If I'm using a list i have
to put it in a parbox. The environment window is provided by package
picinpar, seems that it not works within beamer.
Perhaps for this yasnippet as recommended from Marcin would be usefull.
OTOH i would like to use beamer in future, Beamer_Col does a similar
job, except of surrounding the image with text. Does Beamer provide
something like this?
But, if i write the text for Beamer-Output, i have to handle html-output
extra. The LaTeX-package comment isn't provided by beamer, I don't
know neither how to comment out the HTML-Code for LaTeX-Beamer-fragments
nor how to comment out Beamer-Fragments für HTML-Export.
Seems, Beamer+html is much more complicate than Beamer+scrartcl/article.
You might be able to do what you want with filter functions.
Suppose you start with this:
(Note: long lines might have been wrapped.)
,
| #+ATTR_HTML: alt=my altname title=my full title align=right width=30%
padding=0em padding-top=0em
|[[http://my.com][my place.jpg:windowenv:]]
| More stuff
| - item 1
| - item 1.1
| - item 1.2
| #+LATEX: } \end(window}
`
and want to get this from latex export:
,
|
\begin{window}[0,r,\href{http://my.com}{\includegraphics[width=0.28\textwidth]{my
place}},{}]
| \parbox{0.7\textwidth}{
| More stuff
| \begin{itemize}
| \item item 1
| \begin{itemize}
| \item item 1.1
| \item item 1.2
| \end{itemize}
| \end{itemize}
| } \end(window}
`
and this from html
,
| p
| a href=http://my.com; alt=my altname title=my full title align=right
width=30% padding=0em padding-top=0emmy place.jpg/a
| More stuff
| /p
| ul class=org-ul
| liitem 1
| ul class=org-ul
| liitem 1.1
| /li
| liitem 1.2
| /li
| /ul
| /li
| /ul
`
You can do that with this filter:
,
| #+BEGIN_SRC emacs-lisp
| (defun filter-links-windowized (link backend info)
| Rid :windowenv: from LINK desc and format per BACKEND. Ignore INFO.
| (let ((clean-string (replace-regexp-in-string :windowenv: link)))
| (if (eq backend 'latex)
| (let ((wprefix \\begin{window}[0,r,)
| (wpostfix}},{}]\n\\parbox{0.7\\textwidth}{)
| (repstrng
| \\1{includegraphics[width=0.28textwidth]\\2}))
| (concat wprefix
| (file-name-sans-extension
| (replace-regexp-in-string
| \\([^}]*}\\)\\({.*}\\)
| repstrng
| clean-string))
| wpostfix))
| clean-string)))
| #+end_src
`
which you install with this line:
,
| #+begin_src emacs-lisp :eval never
| (add-to-list 'org-export-filter-link-functions
'filter-links-windowized)
| #+END_SRC
`
Then run the new exporter.
What you want yas to provide is something like
,
| #+ATTR_HTML: alt= title= align= ...
|
| #+LATEX: } \end(window}
`
if you like to use C-c C-l to enter the link - just remember to add the
:windowenv: after the link description.
or
,
| #+ATTR_HTML: alt=my altname title=my full title align= ...
| [[ ][ :windowenv:]]
|
| #+LATEX: } \end(window}
`
if you don't use C-c C-l.
HTH,
Chuck
[O] org-html-link problem
M-x org-export-dispatch RET h H terminates with an error , | | * https link | | | Here is the | [[https://github.com/downloads/yihui/knitr/knitr-minimal.html][link]] | ` The problem seems to be here: lisp/ox-html.el around line 2172: (unless (and desc (string-match (regexp-quote (car att)) desc)) att is nil maybe (unless (and att desc (string-match (regexp-quote (car att)) desc))?? Chuck
[O] org-md fixed-width filter problems
The :translate-alist for the md backend has no entry for fixed-width, so it defaults to the parent org-e-html-fixed-width which uses (format pre class=\example\\n%s/pre ... So elements , | : like | : this ` get the html style markup. Some of the markdown processors I use don't like this. pandoc ignores the element entirely. The github blob generator copies it as verbatim. I have been using (fixed-width . org-md-verbatim) instead, but I think this is still not quite right. (IIUC, proper markdown uses four spaces at bol for such elements while org-md-verbatim uses surrounding backtics.) ? Chuck
Re: [O] org-md fixed-width filter problems
cbe...@tajo.ucsd.edu writes: The :translate-alist for the md backend has no entry for fixed-width, so it defaults to the parent org-e-html-fixed-width which uses (format pre class=\example\\n%s/pre ... So elements , | : like | : this ` get the html style markup. Some of the markdown processors I use don't like this. pandoc ignores the element entirely. The github blob generator copies it as verbatim. I have been using (fixed-width . org-md-verbatim) instead, but I think this is still not quite right. (IIUC, proper markdown uses four spaces at bol for such elements while org-md-verbatim uses surrounding backtics.) ? I see now that org-md-example-block formats with the leading spaces. So I guess my question should have been 'should (fixed-width . org-md-example-block) be used?' Chuck --
Re: [O] new exporter, conditional options according to backend
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Ezequiel Birman stormwa...@espiga4.com.ar writes: Is it possible to write something like this with the new exporter? #+OPTIONS: (if (and (boundp 'org-export-current-backend) (eq org-export-current-backend 'e-beamer)) H:1 H:3) There is no `org-export-current-backend' in the new exporter. Besides, what you want is the default behaviour (see `org-e-beamer-frame-level' variable). 'backend' is in the scope of transcoding functions like inline-src-block. I am currently taking advantage of this, but it is a shortcut rather than a necessity. Is your advice Don't do that ? Chuck From what I read in org-export.el the backend is stored in a plist, not sure how to get it's value when exporting. Or, maybe I need to write a filter function to be run from org-export-before-process-hook? Filters are different from hook. A function in a hook operates on an Org buffer. A filter function operates either on a string in output syntax or on the parse tree. If, for some reason, you want to modify export options on the fly, you could create a filter function for parse tree, and modify options plist from it: #+begin_src emacs-lisp (defun my-options-change-fun (tree backend info) (when (org-export-derived-backend-p backend 'e-beamer) (plist-put info :with-author nil)) ;; Don't forget to return tree. tree) (add-to-list 'org-export-filter-parse-tree-functions 'my-options-change-fun) #+end_src Regards,
Re: [O] [BUG] org-export-with-current-buffer-copy drops local variable WAS:Re: new exporter - noweb substitution issues
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, cbe...@tajo.ucsd.edu writes: Thank you for all the debugging. org-export-with-current-buffer-copy calls org-clone-local-variables which uses a regexp to detect buffer-local variables, but *org-babel-use-quick-and-dirty-noweb-expansion* is not detected, so it gets dropped. Solution add \\*org-babel-use-.*dirty.*\\*\\| or something like that to the regexp. Before doing that, I'd like to know if there's a particular reason for this variable to not belong to the regular namespace. I think this is confusing and error-prone. Thus, I'd rather have the variable renamed instead. Fair enough. Eric, is that ok with you? No reply so far, I think. Anything more I can do to help with this? Chuck
[O] [BUG] org-export-with-current-buffer-copy drops local variable WAS:Re: new exporter - noweb substitution issues
cbe...@tajo.ucsd.edu writes: cbe...@tajo.ucsd.edu writes: When I tried to export a large subtree, it took over *5 minutes* to export with release_7.9.2-597-gd4b739. Using the contrib/lisp/*.el files from org-mode-7.8.11 it took *5 seconds*. [...] Both cases use: # Local variables: # *org-babel-use-quick-and-dirty-noweb-expansion*:t [...] Could it be that the buffer local version of *org-babel-use-quick-and-dirty-noweb-expansion* got lost?? The answer is YES. org-export-with-current-buffer-copy calls org-clone-local-variables which uses a regexp to detect buffer-local variables, but *org-babel-use-quick-and-dirty-noweb-expansion* is not detected, so it gets dropped. Solution add \\*org-babel-use-.*dirty.*\\*\\| or something like that to the regexp. Chuck
[O] new exporter - noweb substitution issues
When I tried to export a large subtree, it took over *5 minutes* to export with release_7.9.2-597-gd4b739. Using the contrib/lisp/*.el files from org-mode-7.8.11 it took *5 seconds*. The subtree has a couple dozen '...'s in src blocks with ':noweb yes' and the file itself is 9600 lines long. If I change all to 'noweb no', then release_7.9.2-597-gd4b739 runs in about 5 seconds. Both cases use: # Local variables: # *org-babel-use-quick-and-dirty-noweb-expansion*:t I like to work interactively. Changing a little piece and then re-exporting to see how it looks is really helpful for me. Having to wait for 5 minutes to see how some small change affects the results just won't work for me. --- I also noticed on a toy test case (that does a lot of noweb lookups) that the value of *org-babel-use-quick-and-dirty-noweb-expansion* seems to have no effect on the reported difference between (get-internal-run-time) eval'ed at the start and again at end of the buffer exported using release_7.9.2-597-gd4b739. FWIW, this toy case runs much faster even though the number of noweb lookups is comparable. It is still slower than 7.8.11 iff I have *org-babel-use-quick-and-dirty-noweb-expansion*:t If there is something I can do to shed more light on this please let me know. --- One other noweb issue is that the code from an *unexported* src block cannot be used in subsequent blocks, which was not true for 7.8.11 and is not true for the old exporter. If the unexported src block is before the block that tries to copy its code, nothing is copied. I believe this is because the same temp buffer is used to look up the code and to store the result that is passed to the parser and unexported code gets deleted before noweb expansions are completed. --- Thanks, Chuck
Re: [O] new exporter - noweb substitution issues
cbe...@tajo.ucsd.edu writes: When I tried to export a large subtree, it took over *5 minutes* to export with release_7.9.2-597-gd4b739. Using the contrib/lisp/*.el files from org-mode-7.8.11 it took *5 seconds*. The subtree has a couple dozen '...'s in src blocks with ':noweb yes' and the file itself is 9600 lines long. If I change all to 'noweb no', then release_7.9.2-597-gd4b739 runs in about 5 seconds. Both cases use: # Local variables: # *org-babel-use-quick-and-dirty-noweb-expansion*:t Further info: ELP timing on a toy case: | exporter | function | Calls |Total | per call | | old | org-babel-params-from-properties | 149 | 1.100289 | 0.0073844966 | | 7.8.11| org-babel-params-from-properties | 142 | 0.966981 | 0.0068097253 | | 7.9.2 | org-babel-params-from-properties | 280 | 1.784211 | 0.0063721821 | | 7.9.2-nil | org-babel-params-from-properties | 280 | 1.750548 | 0.0062519571 | The last line used (setq *org-babel-use-quick-and-dirty-noweb-expansion* nil). The only difference between '7.9.2' and '7.8.11' is I do this: #+BEGIN_SRC emacs-lisp (load /Users/cberry/elisp/org-mode-7.8.11/contrib/lisp/org-element.el) (load /Users/cberry/elisp/org-mode-7.8.11/contrib/lisp/org-export.el) (load /Users/cberry/elisp/org-mode-7.8.11/contrib/lisp/org-e-latex.el) #+END_SRC to switch over to 7.8.11. In other words, all the babel stuff should be the same, which includes org-export-preprocess-blocks. Right? Could it be that the buffer local version of *org-babel-use-quick-and-dirty-noweb-expansion* got lost?? Chuck
Re: [O] Generating captions--is there a better way?
Michael Gauland mikely...@no8wireless.co.nz writes:
I use R to plot data, and like to include information about the plot in the
caption. I do this by combining two named SRC blocks--one for the image, and
one
for the caption--and then put their #+RESULTS: together. The caption is the
tricky bit; I use R to print a string that starts with #+CAPTION:, shown in
the
exmaple below. While this works, I've wondered if there is a more elegant way
to
do this. How do others do this?
[snip]
For something simple like this, I'd use:
,
| #+PROPERTY: session *R*
| #+PROPERTY: results output
|
| #+NAME: image
| #+HEADER: :results graphics
| #+HEADER: :exports results
| #+HEADER: :file (org-babel-temp-file ./figure- .pdf)
| #+BEGIN_SRC R
| x - rnorm(100)
| caption.string -
| sprintf(The mean value is %.3f.\n,mean(x))
| hist(x)
| #+END_SRC
|
|
| #+CAPTION: src_R[:results raw]{ cat(caption.string) }
| #+RESULTS: image
`
For more complicated stuff I use ravel[1] to export as *.Rnw and then use
knitr on the result.
HTH,
Chuck
[1] see
https://github.com/chasberry/orgmode-accessories/blob/master/ravel-org.md
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
John Hendy jw.he...@gmail.com writes: I edited the subject to be more concise/clear.I let orgmode chug away on reading in some ~10-30mb csv files for nearly 30min. [rest deleted] You need an ECM. I cannot reproduce your issue. This runs in the same amount of time, whether I execute the src block or run the code from ESS: #+begin_src R :session write.csv(diag(10)[rep(1:10,10),],file=abc.csv) #+end_src #+begin_src R :session :results output system.time(read.csv(abc.csv)) #+end_src abc.csv is 25MB If the behavior you describe only happens with some files, I suggest you try to bisect them to find the issue. HTH, Chuck
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
John Hendy jw.he...@gmail.com writes: On Wed, Oct 31, 2012 at 11:41 AM, span dir=ltrmailto:cbe...@tajo.ucsd.edu/span wrote: John Hendy mailto:jw.he...@gmail.com writes: I edited the subject to be more concise/clear.I let orgmode chug away on reading in some ~10-30mb csv files for nearly 30min. [rest deleted] You need an ECM.I did my best to provide one, other than the file, which I offered to provide if others requested that I upload it somewhere. Since you have done so, so have I: - https://docs.google.com/open?id=0BzQupOSnvw08WHdabHh5VVczRGM Let me know if that doesn#39;t work. I put it on Google docs and sometimes have issues with the sharing settings... Not an ECM in my book, but ... On my 4 year old MacBook: , | | #+PROPERTY: session *R* | | #+name: bigcsv | #+begin_src R | bigcsv - Sys.glob(~/Downloads/*.csv) | #+end_src | | #+RESULTS: bigcsv | : /Users/cberry/Downloads/test-file.csv | | #+name: readbig | #+begin_src R :results output | system.time( | tmp - read.csv(bigcsv) | ) | | #+end_src | | #+RESULTS: readbig | :user system elapsed | : 5.679 0.306 6.002 | ` About the same as running from ESS. FYI, dim(tmp) [1] 964805 9 Chuck [ rest deleted ]
Re: [O] [new exporter] latex: why does {{}} become \{\{\}\} ?
Charles Berry ccbe...@ucsd.edu writes:
NEVER MIND.
I just restarted my emacs and the export went as it should without the
offending
\begin{latex}
\end{latex}
lines.
Likely someting weird in my setup caused this.
Sorry for the noise.
Chuck
Sebastien Vauban wxhgmqzgwmuf@... writes:
Hi Nicolas,
Nicolas Goaziou wrote:
Sebastien Vauban
Within a LaTeX block (#+begin_latex) or within a Babel block for LaTeX
language (#+begin_src latex)? Do you make a difference?
There's a big difference.
#+begin_latex means paste this code unmodified in the latex back-end,
and only in the latex back-end. Nothing is evaluated.
I guess I do not understand.
Using git pull today,
(org-export-to-buffer 'e-latex scratch.tex) exports this
#+begin_latex
\begin{displaymath}
\mbox{a}=\frac{b}{1 + c}
\end{displaymath}
#+end_latex
as this
\begin{latex}
\begin{displaymath}
\mbox{a}=\frac{b}{1 + c}
\end{displaymath}
\end{latex}
So how do I get rid of the enclosing lines:
\begin{latex}
\end{latex}
??
Chuck
With a #+begin_src latex block, depending on :exports parameter, you can
produce something (in this case, probably an image file) and create
a link valid in any back-end, as long as it supports the file format.
Both are possible.
I realize having taken the bad habit of only using #+begin_src latex blocks
even for code that only matters for the LaTeX back-end (such as TikZ
decorations). By carefully using the Babel options, it comes down to the same
effect/behavior, but, OK, that's NOT the Right Way To Do!
Best regards,
Seb
Re: [O] Problem orgmode, beamer and macport
Nick Dokos nicholas.do...@hp.com writes:
Nick Dokos nicholas.do...@hp.com wrote:
Steve Prud'Homme sprud...@gmail.com wrote:
! LaTeX Error: File `wrapfig.sty' not found.
Type X to quit or RETURN to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
read *
l.43 \usepackage
{soul}^^M
! == Fatal error occurred, no output PDF file produced!
Transcript written on /Users/sprudhom/Dropbox/STEVE/Projet/PROJET C2000
INFOGR
APHIE MODULE 3/Ressource/Notes de cours//C3notes.log.
What OS are you on?
NM - I see you are on a Mac. Maybe a Mac user can help
with the proper instructions here.
He is using macports I think.
so maybe
sudo port install texlive-latex-extra
will do it.
Chuck
Nick
Re: [O] [wish] also provide documentation for contrib
Thomas Koch tho...@koch.ro writes: Hi, I was about to fill a bug about debians org-mode package because it does not come with documentation for the org-mode contrib org-drill. However I believe that this issue should rather be raised to you as the upstream. ,[from contrib/README] | These contributions are not part of GNU Emacs or of the official | Org-mode package. But the git repository for Org-mode is glad to | provide useful way to distribute and develop them as long as they are | distributed under a free software license. ` Maybe http://orgmode.org/worg/org-contrib/org-drill.html is what you need? HTH, Chuck I'd like to encourage you to consider any org-mode contrib in your distribution without accompanying documentation a bug. I don't know enough about the info system or your build system so I'll refrain from any suggestion. Thank you, Thomas Koch, http://www.koch.ro
Re: [O] org-e-groff-export-to-groff produces empty output file
Eric Schulte eric.schu...@gmx.com writes: Hi, Maybe I'm missing something obvious here, but I can't get org-e-groff to generate anything but an empty output file. I've boiled this down to the following minimal example. First save the attached example.org file to /tmp/example.org. Then run the following in your shell, # -*- shell-script -*- emacs --batch --eval '(let ((org-path ~/.emacs.d/src/org-mode/)) (add-to-list (quote load-path) (expand-file-name lisp org-path)) (add-to-list (quote load-path) (expand-file-name contrib/lisp org-path)) (require (quote org)) (require (quote org-e-groff)))' /tmp/example.org -f org-e-groff-export-to-groff The above generates an empty file in /tmp/example.groff. What am I missing? Perhaps the backend is not being correctly passed on to org-export-as. I am not at a machine where I can check this right now, but (org-export-as 'e-bogus) used to merrily run to completion producing an empty output if the objects for the named backend were not bound. HTH, Chuck
Re: [O] [BABEL][BUG] lists and inline src
Bastien b...@altern.org writes: Hi Chuck, cbe...@tajo.ucsd.edu writes: My apologies if this is already reported (I recall seeing something like this, but cannot find it in the archives). A list element starting with an inline src block is improperly parsed. I cannot reproduce this with Org 7.9.1. I just did a git pull, trimmed my .emacs down to (setq load-path (cons ~/elisp/org-mode/lisp load-path)) (setq load-path (cons ~/elisp/org-mode/contrib/lisp load-path)) renamed customizations.el, started Aquamacs, loaded org-e-latex.el and reran (org-export-to-buffer 'e-latex *Test e-LaTeX* nil nil t) I am still getting the same result. What else can I do to get to the bottom of this?? Chuck
[O] [BABEL][BUG] lists and inline src
My apologies if this is already reported (I recall seeing something like
this, but cannot find it in the archives).
A list element starting with an inline src block is improperly
parsed. for example
- src_emacs-lisp{(org-version)}
is not executed by babel. An ECM:
,
| * virgin version
|
| The version is src_emacs-lisp{(org-version)}
|
| * list versions
|
| - The version is
| - src_emacs-lisp{(org-version)}
| - The version is
| - now src_emacs-lisp{(org-version)}
`
yields
,
| ...
| \section{virgin version}
| \label{sec-1}
|
|
| The version is \verb=7.9.1=
| \section{list versions}
| \label{sec-2}
|
|
| \begin{itemize}
| \item The version is
| \item src$_{\mathrm{emacs}}$-lisp\{(org-version)\}
| \item The version is
| \item now \verb=7.9.1=
| \end{itemize}
| ...
`
Chuck
Re: [O] new exporter now drops labels
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, cbe...@tajo.ucsd.edu writes: Using a pull from earlier today (8ab1d76..343b648) and this file: , | *** first headline | #+COMMENT: (org-export-to-buffer 'e-latex my buffer nil nil t) | | | #+name: version-label | #+BEGIN_SRC emacs-lisp :exports both :results value raw | (org-version) | #+END_SRC ` and doing C-x C-e after the comment line, the label before for src block is lost: It should be fixed. Thanks for reporting this. Pulled 343b648..0b13ec8 a few minutes ago. Still no version-label label for the src block. Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] new exporter now drops labels
Nicolas Goaziou n.goaz...@gmail.com writes: cbe...@tajo.ucsd.edu writes: Pulled 343b648..0b13ec8 a few minutes ago. Still no version-label label for the src block. Indeed, it was a completely different problem. It should be fixed, this time. Thanks. Looks good, now. Thank you! Chuck
[O] new exporter now drops labels
Using a pull from earlier today (8ab1d76..343b648) and this file:
,
| *** first headline
| #+COMMENT: (org-export-to-buffer 'e-latex my buffer nil nil t)
|
|
| #+name: version-label
| #+BEGIN_SRC emacs-lisp :exports both :results value raw
| (org-version)
| #+END_SRC
`
and doing C-x C-e after the comment line, the label before for src block
is lost:
,
| \section{first headline}
| \label{sec-1}
| \begin{verbatim}
| (org-version)
| \end{verbatim}
|
| 7.9.1
`
while with an older version, I get the label
,
| section{first headline}
| \label{sec-1}
| \label{version-label}
| \begin{verbatim}
| (org-version)
| \end{verbatim}
|
| Org-mode version 7.8.11
`
Chuck
--
Charles C. BerryDept of Family/Preventive Medicine
cberry at ucsd edu UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] conditional export based on babel result
Andreas Leha andreas.l...@med.uni-goettingen.de writes: I am a bit late to the thread, but two possibilities come to mind: 1) write a brew template as #+name: brewtemp #+begin_src latex ... #end_src block then call it as #+begin_src R :noweb yes :results output latex brew(text= brewtemp ) #+end_src Brew allows loops and conditionals over both markup and code, which allows you to choose or skip a sub-document as the R code dictates. If the sub-document is of modest size and complexity, this is reasonably easy and the brew markup will be easy to read. 2) Use ravel (at https://github.com/chasberry/orgmode-accessories/) to export an org subtree as a knitr parent document in Rnw format (akin to Sweave) and another org subtree as a knitr child document. The parent document must call the child from within a code block to allow loops and conditionals. Then run knitr. For more complicated sub-documents, this might work better than building brew templates in latex src blocks as editting the org structure and retooling R src blocks is easier (for me at least) than re-organizing a lengthy latex src block with embedded brew calls. HTH, Chuck Eric Schulte eric.schu...@gmx.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, is there a possibility to exclude (or include) parts of the document based on some babel source block result? First some use case: Say, I am doing a statistical test. And only if the test turns out to be significant, a follow-up analysis is carried out. Is that possible? One thinkable and ugly option would be to allow lisp-generated tags like in this dummy example: #+begin_org * The Test #+name: sometest #+begin_src R test_result - 0.03 #+end_src ** export maybe (if ( (string-to-number (sbe sometest)) 0.05) :export: :noexport:) The follow-up #+end_org Regards, Andreas Hi Andreas, When doing something this complex you may just want to write your own function which could say... take a subtree ID and a boolean flag as arguments and then set the export flag on that subtree as appropriate. The org-id-goto and org-toggle-comment functions may help in implementing this function. Best, Hi Eric, in my opinion, there are more complex things in org-mode already ;-) I agree, that such functionality doesn't need to be provided in org itself. Thanks a lot for the pointers to possible entry-points for an implementation. I hope, I'll find time to to go for it. Would be good for my elisp, anyway... Regards, Andreas -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Converting Org to Sweave (*.Rnw)
Julian Gehring julian.gehr...@gmail.com writes:
Hi,
is there a way to convert Org-mode files with R code blocks to the
Sweave ('*.Rnw') [1] file format or has anyone planned to work on
this?
First, there is this thread:
http://comments.gmane.org/gmane.emacs.orgmode/7931
and then there is this
http://yihui.name/knitr/demo/org/
But I wanted more, and I think the new exporter provides some awesome
possibilities, so...
I have put together a rudimentary exporter for Sweave and for brew style
chunks and hope to have several of the knitr chunk flavors supported
soon. I've not looked closely, but I think pander can be supported, too.
The basic idea is to use the new export engine. See
http://orgmode.org/worg/dev/org-export-reference.html
for background.
The e-latex, e-html, and other modes are used as parent backends and
e-latex-rnw, e-html-brew, etc are *derived* backends. It is pretty easy
to hitch a ride on the work done to make a parent backend and then add a
minimal definition of the chunk formatting.
The only tricky bit is getting Babel to help in the process, but not
interfere. I want Babel to porcess non-R src blocks and clean out R
#+RESULTS blocks, but not strip out the header args, as these may be
wanted (as you suggest below) to inform the chunk arguments. I've
managed this by advise'ing org-babel-exp-do-export to do special
handling of R src blocks.
I've not yet delved into translating the headers into code chunk
arguments. Some like 'width' seem pretty obvious. Others like the
:exports + :results translation may take some thought. And there are
some idioms in Sweave and kntir that have not corresponding idiom in org
(which is a strong motive for doing this work) like 'dev' in knitr as
well as ':cache yes' versus 'cache=T', which are false cognates, so to
speak
So far, what I've done is do add a header arg like this:
Here is an inline chunk: src_R{ rnorm(1) } which the brew export
renders as %= rnorm(1) -% (i.e. print the result, but do not place
a line break after the result), making a non-printing version of this
is done by using this src_R[ :ravel % -% ]{ rnorm(1) }, which
renders as % rnorm(1) -%.
or this
: #+name: aCachedChunk
: #+begin_src R :ravel cache=T
: x - rnorm(1e7)
: #+end_src
which is rendered as
aCachedChunk, cache=T=
x - rnorm(1e7)
@ %def
when using the Sweave style exporters.
However, Nicolas *just* added support for #+ATTR_SOMETHING, where
SOMETHING is a user defined key. And I incline to the view that using
something like
: #+attr_ravel: cache=T
: #+name: aCachedChunk
: #+begin_src R
: x - rnorm(1e7)
: #+end_src
might be preferred.
Anyway, I'll try to get a version up where you can have a look at it
sometime today.
I am keen to collaborate on this.
Chuck
Sweave is heavily used in the R community in terms of literate
programming, and has a tight integration into current package building
workflows. Essentially, the file format is a latex document, with
designated code chunks.
Since Org/Org-babel offers a very similar feature set, and already
covers the export to latex, I was wondering whether anyone is working
on some code that would rewrite the code block headers in the export?
In the R community, I have seen a lot of interest in such an exporter,
that would allow to write the documentation in Org itself and later
export it to several backends, including Sweave to integrate it in the
R package.
If anyone has some comments regarding this or is interested in working
on this, please let me know. My colleagues and I would be very
interested in contributing in projects in this direction.
Best
Julian
[1] http://en.wikipedia.org/wiki/Sweave
--
Charles C. BerryDept of Family/Preventive Medicine
cberry at ucsd edu UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
[O] [BUG] new exporter and #+BEGIN_CENTER
This throws an error: -- * headline 1 #+BEGIN_CENTER #+BEGIN_SRC R :exports both rnorm(10) #+END_SRC #+END_CENTER -- M-: (org-export-to-buffer 'e-latex latex buffer) RET It does not run the src block and the error is: (error Invalid search bound (wrong side of point)) re-search-forward(@@[-A-Za-z0-9]+: 31 t) [snip] org-element-export-snippet-successor(31) [rest deleted] Removing the whitespace between the BEGIN_CENTER and BEGIN_SRC lines runs, but wrongly fails to execute the src block. Removing the CENTER results in running the src block and producing the expected result. My last pull was yesterday: b7be665..69af091 HTH, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Converting Org to Sweave (*.Rnw)
Julian Gehring julian.gehr...@gmail.com writes: Hi Chuck, thanks, what you describe seems to me like a already quite elaborated solution. I would be very interested in your existing implementation for this. As you mentioned, there will probably have to be a trade-off between the syntax/functionality of Org-mode/babel and Sweave. But already a solution being able to handle to obvious cases of header argumnets would be step forward in bringing Org-mode even closer to R Sweave. Julian, Please take a look at https://github.com/chasberry/orgmode-accessories and try it out. ravel.org implements a couple of backends to export to Sweave and brew style documents. There are commands embedded to create e-ravel.el, which powers the backends as well as commentary on how to implement some extensions. There are two POC *.org files which show some of the possibilities. Best, Chuck [snip]
Re: [O] [BUG] new exporter and #+BEGIN_CENTER
Jambunathan K kjambunat...@gmail.com writes: Center within Src. I don't think you can nest the blocks. It seems you are right. At least as far as executing the src block is concerned. I was thinking along the lines of LaTeX's center environment, but I see now that a src block within a CENTER didn't work with the old exporter either. The cryptic message is org-export.el way of saying that there is a parse error or that the Org file doesn't to conform to schema. The latest git pull gives no error - it just doesn't run the src block. This throws an error: -- * headline 1 #+BEGIN_CENTER #+BEGIN_SRC R :exports both rnorm(10) #+END_SRC #+END_CENTER -- M-: (org-export-to-buffer 'e-latex latex buffer) RET It does not run the src block and the error is: (error Invalid search bound (wrong side of point)) re-search-forward(@@[-A-Za-z0-9]+: 31 t) [snip] org-element-export-snippet-successor(31) [rest deleted] Removing the whitespace between the BEGIN_CENTER and BEGIN_SRC lines runs, but wrongly fails to execute the src block. Removing the CENTER results in running the src block and producing the expected result. My last pull was yesterday: b7be665..69af091 HTH, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Output of R babel blocks with quotes is mangled/truncated
Viktor Rosenfeld listuse...@googlemail.com writes: Hi, if a value outputted by R in a Babel block contains quotes only the quoted parted is exported. Try #+begin_src R :results verbatim q = 'cat=S' q #+end_src Consider this: #+BEGIN_SRC R q = 'cat=S' q #+END_SRC #+RESULTS: : S The expected result would be entire string, i.e. 'cat=S' (without single quotes). Is there a workaround? I've tried escaping with backslashes to no avail. Cheers, Viktor -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] new exporter drops :parameters ?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, cbe...@tajo.ucsd.edu writes: BTW, #+name: aname and #+NAME: aname are handled differently in e-latex. The former gets placed in the latex output as \#+name: aname. Bug? There is a known bug about affiliated keywords not being removed during export, but I don't know if you're describing the same problem. Do you have an ECM illustrating it ? Yes and No. I tried to put an ECM together earlier today, but couldn't trigger the bug. Then a few minutes ago it bit. And this simple subtree triggered it: , | * here is a subtree to export | #+COMMENT: (org-export-to-buffer 'e-latex *rnw out* t) | | ** src block | | #+name: ablock | #+begin_src R | rnorm(10) | #+end_src ` But I restarted emacs, loaded contrib/lisp/org-export.el and contrib/lisp/org-e-latex.el, and ran the command in the COMMENT line again and the *rnw out* buffer looked justed fine (no \#+name... stuff). And I repeated as many of my earlier steps as I could and still no bug bite. So whatever the problem is, it is not something I can reliably reproduce. If I come up with anything, I'll get back to you. Chuck Regards, -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] new exporter drops :parameters ?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Charles Berry ccbe...@ucsd.edu writes: I am trying to put together a derived backend that makes use of Src Block :parameters attribute. [deleted] AFAICS :parameters is nowhere to be found when using org-export-to-buffer. This is because src blocks are executed before buffer is parsed. You can try to call `org-export-blocks-preprocess' on the following buffer (associated to a file): Thanks! I get it. It turns out I can piggyback extra info needed on the ':name' element and use that in lieu of ':parameters'. BTW, #+name: aname and #+NAME: aname are handled differently in e-latex. The former gets placed in the latex output as \#+name: aname. Bug? Chuck --8---cut here---start-8--- #+name: bblock #+BEGIN_SRC R :exports code :et-cetera rnorm(2)+1 #+END_SRC --8---cut here---end---8--- and see what is really parsed: the removal happens on the Babel side. [snip] -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Auto-fill-mode with code sections
Eric Schulte eric.schu...@gmx.com writes: Ken Williams ken.willi...@windlogics.com writes: Ping - I'm still interested in this, if anyone has any recommendations. Thanks. Hi Ken, I don't know of an automatic solution here. One option is to edit code sections with org-edit-special, i.e., press C-c ' from within a code block. Best, Here is a start. It fills normal text, but leaves src blocks alone. Maybe add something to one of the org-mode hooks ? HTH, Chuck , | | * autofill, but not src blocks | | #+begin_src emacs-lisp | (defun org-auto-fill-function () | auto fill function to leave src blocks alone | (if (not (org-babel-get-src-block-info)) | (do-auto-fill))) | (setq normal-auto-fill-function 'org-auto-fill-function) | #+end_src | | | aaa aaa vvv aaa aaa vvv aaa aaa vvv aaa aaa vvv aaa aaa vvv aaa aaa | aaa aaa vvv aaa aaa vvv aaa aaa vvv aaa aaa vvv aaa aaa vvv aaa aaa | vvv aa vvv aaa aaa vvv | | #+begin_src R | x - y + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 3 | #+end_src ` -Ken From: Ken Williams Sent: Tuesday, May 01, 2012 8:51 AM To: emacs-orgmode@gnu.org Subject: Auto-fill-mode with code sections Hi, I use org-mode extensively with R code sections, as a scientific notebook. One annoyance I have is that when I have auto-fill-mode turned on (which is convenient for the main body parts of the document), it extends to the code section and starts auto-filling my code. Can anyone recommend a configuration that will get me folding in the body sections, but not in the code sections? It could use another mechanism besides auto-fill-mode if that's what's preferred these days, but auto-fill-mode is the one I'm familiar with. CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you. -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] R sessionInfo() and orgmode footnotes
Alejandro Reyes alejandro.re...@embl.de writes: Dear all, I am having troubles to export my documents to a pdf when I have the R sessionInfo() as a result. Nevertheless I can export them as a html. I think org-mode export to latex is getting confused with the output of the sessionInfo() function and the footnotes definition. The next is a example: I confirm that this fails with I try to export to latex. From my *Messages* buffer: Exporting to LaTeX... org-babel-exp processing... executing R code block... Code block evaluation complete. org-export-latex-preprocess: Wrong type argument: integer-or-marker-p, nil but not html. Chuck EXAMPLE This is a strange case [fn:1] #+BEGIN_SRC R :exports both :results output x - rnorm(100) sessionInfo() #+END_SRC [fn:1] It does not let me export to latex I am using the latest version of org-mode and emacs. Cheers, Alejandro -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Archiving only with confirmation
Markus Grebenstein p...@mgrebenstein.de writes: Dear List, from time to time I involuntarily archive parts of my thesis when I want to save (it happens when I mess up the saving keys). Since I recognized this a couple of days or even weeks later this makes recovering complicated. Therefore I would love to have the possibility to be asked whether I really want to do that. Is this what you want: , | (emacs)Top Customization Key Bindings Disabling | | 57.4.11 Disabling Commands | -- | | Disabling a command means that invoking it interactively asks for | confirmation from the user. The purpose of disabling a command is to | prevent users from executing it by accident; [...] ` For example, I have this in my macbook ~/.emacs , | ;; get rid of pesky aquamacs-save-buffers-kill-emacs binding | | (put 'aquamacs-save-buffers-kill-emacs 'disabled | Use C-x C-c to quit\n) | | (put 'aquamacs-print 'disabled Why print?\n) ` To protect against the commands bound to clover-p and clover-q being inadvertently run when what I really wanted was M-p or M-q. (The clover key sits next to the 'M-' on my keyboard.) HTH, Chuck I used org-archive-subtree-default-with-confirmation but I did not get what the meaning of that one is. When I use that command I am sure that I want to archive and as far as I see it does not change the default behavior. Does anybody have an idea how to achieve what I want? Thanks in advance, Markus -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@isciences.com writes: cberry at tajo.ucsd.edu writes: Eric Schulte eric.schulte at gmx.com writes: Does this do what you want? Have you looked at the :cache header argument [1], from my understanding of your use case it should be exactly what you are after. Its a step in the right direction. It seems I have to set :cache yes on every block I use before I invoke it. My attempt to use a buffer-wide PROPERTY setting for cache did not pan out. Were these technical problems with the implementation of :cache, or logistical problems specific to your organization of code blocks? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
cbe...@tajo.ucsd.edu writes: inline correction below. Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@isciences.com writes: cberry at tajo.ucsd.edu writes: Eric Schulte eric.schulte at gmx.com writes: Does this do what you want? Have you looked at the :cache header argument [1], from my understanding of your use case it should be exactly what you are after. Its a step in the right direction. It seems I have to set :cache yes on every block I use before I invoke it. My attempt to use a buffer-wide PROPERTY setting for cache did not pan out. Were these technical problems with the implementation of :cache, or logistical problems specific to your organization of code blocks? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | Of course that should have been #+property: cache yes but the result below is the same. Chuck | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
Nick Dokos nicholas.do...@hp.com writes: cbe...@tajo.ucsd.edu wrote: cbe...@tajo.ucsd.edu writes: inline correction below. Eric Schulte eric.schu...@gmx.com writes: Matthew Landis lan...@isciences.com writes: cberry at tajo.ucsd.edu writes: Eric Schulte eric.schulte at gmx.com writes: Does this do what you want? Have you looked at the :cache header argument [1], from my understanding of your use case it should be exactly what you are after. Its a step in the right direction. It seems I have to set :cache yes on every block I use before I invoke it. My attempt to use a buffer-wide PROPERTY setting for cache did not pan out. Were these technical problems with the implementation of :cache, or logistical problems specific to your organization of code blocks? [rest deleted] Eric, your response is threaded as a reply to Matthew, but here you have replied to my comment about buffer wide PROPERTY setting of :cache. Here is an example of the difficulty I face: , | #+property: :cache yes | Of course that should have been #+property: cache yes but the result below is the same. Did you C-c C-c on the #+property: line after changing it? I think it works as expected. You are right. It reports the cache'd value of the date. I've been bitten by the 'no C-c C-c' after changing a #+property line so many times, you would think I'd learn. :-( Thanks. Chuck Nick Chuck | | #+name: Ablock | #+begin_src emacs-lisp :results value :exports both | (current-time-string) | #+end_src | | #+results[2ca40f0dc0f23e5743133e229d9e8f31b31830c5]: Ablock | : Wed Feb 29 11:57:19 2012 | | | * headline 1 | :PROPERTIES: | :cache: no | :END: | | #+CALL: Ablock() :exports results | ` When I place point under the headline and issue C-c @ C-c C-e a I get , | headline 1 | == | | Author: | Date: 2012-03-02 11:28:54 PST | | | | | Fri Mar 2 11:28:52 2012 | ` showing that Ablock() actually was executed. If the :cache setting under 'headline 1' is omitted then no update of the time string is performed. I understand that this behavior might be considered a *feature*, not a *bug*. Either way, having an easy way to copy results into other parts of a document would help me out. Best, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
t...@tsdye.com (Thomas S. Dye) writes: cbe...@tajo.ucsd.edu writes: I sometimes create large documents with many dozens of src blocks and associated #+RESULTS. I'd like to be able to grab some of these results blocks and export them into a document. Since revisions of the src blocks can change the results, I do not want to just and to copy and paste the results in case I need to revise the sub-document(s). And with long running blocks, I do not want to use a noweb strategy to rerun the code in the src blocks. As an example, I might have this in a file with many other headlines and src blocks: , | * Selectively Export Some Results | :PROPERTIES: | :EXPORT_FILE_NAME: Selected_Results.pdf | :EXPORT_TITLE: Selected Results | :END: | | Here are the results from block named Ablock: | | #+CALL: show-results(Ablock) | | and here they are for a block named Bblock: | | #+CALL: show-results(Bblock) ` and if I put point on the headline and type C-c @ C-c C-e d, I'd like to have a document that includes the two results blocks in it after each CALL line. It looks like many of the pieces I need are available, but I don't see how to stitch them together to create the show-results() function. TIA, Chuck Hi Chuck, Thanks for the reply. Does this do what you want? No. When I put point under the headline and type C-c @ C-c C-e d, it prompts me to evaluate each of the blocks, and when I answer 'no' to each, it produces a document that omits the previously computed results. What I want is to grab *existing* results blocks and use them. And if at a later date some of those results blocks have changed, when I again put point under the headline and type C-c @ C-c C-e d, I'd like the newer blocks to be updated. The computations in some blocks run for many minutes, so it is impractical to recompute them every time I want to tweak the format of a document that depends on them. Chuck * Selectively Export Some Results :PROPERTIES: :EXPORT_FILE_NAME: Selected_Results.pdf :EXPORT_TITLE: Selected Results :END: Here are the results from block named Ablock: #+CALL: Ablock() :exports results and here they are for a block named Bblock: #+CALL: Bblock() :exports results All the best, Tom -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Selectively export RESULTS
Eric Schulte eric.schu...@gmx.com writes: Does this do what you want? No. When I put point under the headline and type C-c @ C-c C-e d, it prompts me to evaluate each of the blocks, and when I answer 'no' to each, it produces a document that omits the previously computed results. What I want is to grab *existing* results blocks and use them. And if at a later date some of those results blocks have changed, when I again put point under the headline and type C-c @ C-c C-e d, I'd like the newer blocks to be updated. The computations in some blocks run for many minutes, so it is impractical to recompute them every time I want to tweak the format of a document that depends on them. Hi Chuck, Thanks for your reply. Have you looked at the :cache header argument [1], from my understanding of your use case it should be exactly what you are after. Its a step in the right direction. It seems I have to set :cache yes on every block I use before I invoke it. My attempt to use a buffer-wide PROPERTY setting for cache did not pan out. With org-confirm-babel-evaluate set to t, it prompts for confirmation of each and every block/call it encounters, which is a bit tiresome. I can set this to nil, but the potential for causing mischief by unintenionally evaluating blocks whose results were OK and needed for a quick report worries me. Its pretty clear that the machinery needed to capture results is all there. If I can find time, I'll trace thru what is going on when cache yes is set and see if I can do so more directly. Chuck Best, Footnotes: [1] http://orgmode.org/manual/cache.html -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
[O] Selectively export RESULTS
I sometimes create large documents with many dozens of src blocks and associated #+RESULTS. I'd like to be able to grab some of these results blocks and export them into a document. Since revisions of the src blocks can change the results, I do not want to just and to copy and paste the results in case I need to revise the sub-document(s). And with long running blocks, I do not want to use a noweb strategy to rerun the code in the src blocks. As an example, I might have this in a file with many other headlines and src blocks: , | * Selectively Export Some Results | :PROPERTIES: | :EXPORT_FILE_NAME: Selected_Results.pdf | :EXPORT_TITLE: Selected Results | :END: | | Here are the results from block named Ablock: | | #+CALL: show-results(Ablock) | | and here they are for a block named Bblock: | | #+CALL: show-results(Bblock) ` and if I put point on the headline and type C-c @ C-c C-e d, I'd like to have a document that includes the two results blocks in it after each CALL line. It looks like many of the pieces I need are available, but I don't see how to stitch them together to create the show-results() function. TIA, Chuck -- Charles C. BerryDept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] how do scientists use org mode?
Christopher W. Ryan cr...@binghamton.edu writes:
I'm fairly experienced with emacs, ESS, Sweave, and R, but I've only
started to dabble in Org mode in the past couple of weeks. Just as
Christoph is, I'm trying to decide whether/how Org-mode might be useful
in organizing and carrying out research projects, presentations, etc. So
this thread has been very useful and timely.
I'm trying to envision what a small research project, managed via a
single Org file, might look like. There would be notes from meetings,
thoughts from brainstorming sessions, scheduled appointments, data, R
code, R output, and manuscript/presentation prose. Some of this might be
destined for a manuscript, some for a beamer presentation, and some only
for internal consumption. How are all these pieces differentiated in
the Org file, so that Org knows what to put in the
presentation/manuscript, and what not to? Could anyone share or point to
a short, perhaps fictional, example?
Have you looked at
http://orgmode.org/worg/org-contrib/babel/uses.html
??
There are almost too many possibilities --- it is a bit overwhelming.
Here are three things I find useful:
1) The ability to export a subtree allows you to have many documents
within the *.org file. Setting EXPORT_* properties for the subtree gives
you a lot of flexibility. And it is easy to do with TAB completion to
prompt you to fill in the needed pieces.
2) Internal hyperlinks are really useful in staying on course in a big,
complicated document.
3) Noweb syntax allows you to mix and match different parts of the
document. Below is a minimal example. The latex chunks can be used
anywhere I need them. Navigating to '* mini report' and typing
'C-c @ C-c C-e l'
produces mini.tex.
,
| * COMMENT latex chunks
|
| #+name: chunk1
| #+begin_src latex
| \begin{displaymath}
| y = r\sin\theta
| \end{displaymath}
| #+end_src
|
| #+name: chunk2
| #+begin_src latex
| \begin{displaymath}
| x = s\cos\theta
| \end{displaymath}
| #+end_src
|
|
| * mini report
| :PROPERTIES:
| :EXPORT_FILE_NAME: mini.tex
| :EXPORT_TITLE: Minimal Report
| :EXPORT_AUTHOR: Mister CCB
| :END:
|
| #+begin_src latex :noweb yes
| chunk1
| chunk2
| #+end_src
`
HTH,
Chuck
Thanks very much.
--Chris
[snip]
--
Charles C. BerryDept of Family/Preventive Medicine
cberry at ucsd edu UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] About the use of PROPERTY meta lines...
Torsten Wagner torsten.wag...@gmail.com writes: Hmm... but this point is really interesting at least worse to write down in the manual. From my understanding a #+PROPERTY: var bar=2 sets bar globally to 2 somewhere and many lines and headers later #+PROPERTY: var bar=5 would change this value to 5 for either the rest of the file or until a new assignment is given... I think the behavior is trickier than that. This file: , | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | #+property: var+ bar=20 | | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src ` Yields '30' after each block upon C-c C-e A, suggesting it is the last #+property setting the global property. But this one: , | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src ` Yields '3' after each block. So the global behavior of the second 'var foo' line depends on there baing a subsequent 'var+' line. Is this really the expected behavior? (Org-mode version 7.8.03) Chuck in that way a property line would be an tree-independent global variable in contrast, a property-block is only valid of the given tree (and subtrees?). This brings up the question if there is a need for #+PROPERTY: const bar=2 which would behave exactly the same like var but issue an error message if someone tries to set it again somewhere in the file. Torsten On 01/06/2012 04:28 PM, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: Hi Eric and all, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: #+TITLE: Properties #+AUTHOR:Seb Vauban #+PROPERTY: var foo=1 #+PROPERTY: var+ bar=2 * Abstract IIUC, properties are set in this way: - on a file basis, before any heading, through the =PROPERTY= keyword, - on a subtree basis, through the =PROPERTIES= block. My comprehension is that the =PROPERTY= keyword may not be used inside trees, and should be ignored if that would happen. While it is not normal usage, I think that it is legal for #+PROPERTY: lines (or #+Option: lines etc...) to appear inside of subtrees. I realize this is not especially a Babel question, but more a Org core question... Thanks for your answer -- which generates a new one, though: what is then the expected *semantics* of such a construct? There are at least 3 different views on such a construct: putting a PROPERTY line inside a subtree... - ... resets some values from that point up to the end of the subtree - ... resets some values from that point up to the end of the buffer - ... defines some values which can have already been by the subtree I agree this is murky and whatever behavior we want should be clearly thought out and documented in the manual. I would argue that you missed another possible semantics, the simple semantics which are currently implemented in which a property line *anywhere* in a buffer sets a global property. Cheers, Best regards, Seb The following example shows that either: - I'm wrong to think so, - there is a bug. What is the right assumption here? * Subtree Being located in a subtree, the following lines are ill-placed IMHO: #+PROPERTY: var foo=Hello #+PROPERTY: var+ world Though, they're well taken into account: #+begin_src emacs-lisp foo #+end_src #+results: : Hello world These lines have even wiped the definition of =bar= (because of the use of =var= without any =+=): #+begin_src emacs-lisp (+ foo bar) #+end_src returns the error Symbol's value as variable is void: bar.
[O] [babel] PROPERTY doesn't do what BABEL did
I would like to get the same behavior as when I export a file with (say) these three lines: #+begin_src emacs-lisp :var foo=1 :var bar=2 :results value :exports both (+ foo bar) #+end_src But I'd like to set a buffer wide PROPERTY to achieve that as with a file with these lines: #+property: var foo=1 #+property: var+ bar=2 #+begin_src emacs-lisp :results value :exports both (+ foo bar) #+end_src it throws an error under 7.8.02 (downloaded as tar.gz) when I try to export it with 'C-c C-e a yes RET' : progn: Symbol's value as variable is void: foo Other trials seem to show that #+PROPERTY: is ignored by the src blocks I'd really like to get something that does what BABEL used to do as I have a lot of code that relies on that behavior. :-( Chuck ---
Re: [O] [babel] PROPERTY doesn't do what BABEL did
Eric Schulte eric.schu...@gmx.com writes: cbe...@tajo.ucsd.edu writes: I would like to get the same behavior as when I export a file with (say) these three lines: #+begin_src emacs-lisp :var foo=1 :var bar=2 :results value :exports both (+ foo bar) #+end_src But I'd like to set a buffer wide PROPERTY to achieve that as with a file with these lines: #+property: var foo=1 #+property: var+ bar=2 #+begin_src emacs-lisp :results value :exports both (+ foo bar) #+end_src The above works on my system. You may want to try C-c C-c on one of the property lines so that Org-mode re-reads them (it does this automatically upon opening an Org-mode file). Eric, That did it. So when editting #+PROPERTY lines, C-c C-c on one of them to update the settings. I see this documented in org-ctrl-c-ctrl-c now. But I missed it in the manual. Thanks, Chuck Best, it throws an error under 7.8.02 (downloaded as tar.gz) when I try to export it with 'C-c C-e a yes RET' : progn: Symbol's value as variable is void: foo Other trials seem to show that #+PROPERTY: is ignored by the src blocks I'd really like to get something that does what BABEL used to do as I have a lot of code that relies on that behavior. :-( Chuck ---
Re: [O] Not overwriting unchanged source code files when tangling
Holger Hoefling hhoef...@gmail.com writes: Hi Carsten, thanks for the suggestion, but as I agree with Brian. If there is more than one source file in the org-file, then the whole project would still be recompiled, not just the updated file.To be more exact, I actually don#39;t want to compile things, but run R scripts using make. There are caching tools in R that might handle this. packages weaver and cacheSweave come to mind. For example, tangling your *.org file to produce a trivial Sweave document consisting of a single code chunk with the 'cache=T' argument, then Sweaving it using the 'weaver' driver from the weaver package will cache all the computations. Subsequent changes to the code followed by a new weave will result in cached values being used when possible and fresh computations being done as needed. I believe this is done on an expression by expression basis so adding a bit of whitespace or a comment will not trigger recomputation. So you can overwrite the document and making trivial changes to expressions without having to recompute expressions that have not changed (and have no dependencies that are changed). HTH, Chuck So the waiting time if a computationally intensive step is repeated although it is not necessary can be substantial. I wonder how difficult the following change would be (no emacs lisp experience, also do not know the org source code):- would it be possible to write out the source files when tangling into a temporary directory, then compare to the actual target files and overwrite only if something has changed? Then the time stamps would stay fixed. Hopefully, this would not involve too much work: - creating temporary files and remembering the mapping to true files- tangling out as usual into temporary files (so probably little change there)- compare temporary file to true file (does emacs already have a diff utility that could be used?) - overwrite true file if any changes- delete temporary filesEspecially, with this method no dependencies would be necessary and it would not be necessary to keep track in the org files which source blocks have been changed since the last tangling Thank you for your suggestionHolger On Fri, Nov 18, 2011 at 6:02 PM, Carsten Dominik span dir=ltrmailto:carsten.domi...@gmail.com/span wrote: On 18.11.2011, at 14:17, Holger Hoefling wrote: Hi, I have a problem/request for org-mode and was looking for help. I am using org-mode to write source code files and tangle them out. I want to compile them using make. My problem now is that org-mode overwrites the old files every time I tangle them out, therefore also updating the time stamp - even if nothing has changed. Subsequently, when I run make, everything gets recompiled, not just the changed source code files as all time stamps have changed. Is there an option for org-mode to only overwrite source code files that get tangled out if they have truly changed? How about changing the make file so that the dependence is on the Org file, not on the source file? You could then arrange for make to call emacs in batch-mode to tangle the source file and then compile it? Something along the lines of (untested, and probably wrong in this way...) file.o: http://somefile.org emacs -batch --eval #39;(org-babel-tangle-file http://somefile.org;)#39; cc file.o - Carsten -- Charles C. BerryDept of Family/Preventive Medicine cbe...@tajo.ucsd.eduUC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
Re: [O] Code vanishes on export
suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Eric, On Wed, Aug 24, 2011 at 3:58 PM, Eric Schulte schulte.e...@gmail.com wrote: Vikas Rawal vikasli...@agrarianresearch.org writes: I obviously do not want the code to be removed from my org file. There are ways of controlling whether code or results or both or neither are included in code export. As far as I understand from Vikas' last remark, his org file is getting changed. FWIW, I experienced this myself. #+begin_src R blocks vanished from the *.org file during export (but I was saved by version control!). I think this behavior showed up after 7.7, but I cannot reproduce it now (I did a git pull at release_7.7.170.gcaaad.dirty and have since modified the *.org file on which it happened). IIRC, it did not happen for exports when :export never was set for the buffer and not circumvented by '#+begin_src R :eval t'. Maybe this has (coincidentally) been corrected by the recent update of ob-exp.el, ob.el, and org-exp-blocks.el? Chuck -- Charles C. Berry
