Re: [O] New Exporter html - latex - beamer
Robert Eckl writes:
> Eric S Fraga writes:
>
>> Robert Eckl 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
,
|
| http://my.com"; alt="my altname" title="my full title" align="right"
width="30%" padding="0em" padding-top="0em">my place.jpg
| More stuff
|
|
| item 1
|
| item 1.1
|
| item 1.2
|
|
|
|
`
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
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 "\n%s" ... > > 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 --
[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 "\n%s" ... 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] new exporter, conditional options according to backend
Nicolas Goaziou writes: > Hello, > > Ezequiel Birman 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 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
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
[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] Generating captions--is there a better way?
Michael Gauland 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 writes:
> On Wed, Oct 31, 2012 at 11:41 AM, dir="ltr"><mailto:cbe...@tajo.ucsd.edu> 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'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] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
John Hendy 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] [new exporter] latex: why does {{}} become \{\{\}\} ?
Charles Berry 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 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 writes:
> Nick Dokos wrote:
>
>> Steve Prud'Homme wrote:
>>
>> >
>> > ! LaTeX Error: File `wrapfig.sty' not found.
>> >
>> > Type X to quit or to proceed,
>> > or enter new name. (Default extension: sty)
>> >
>> > Enter file name:
>> > ! Emergency stop.
>> >
>> >
>> > 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 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 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 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 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
Re: [O] new exporter now drops labels
Nicolas Goaziou 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. Berry Dept of Family/Preventive Medicine cberry at ucsd edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
[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 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= <> ) #+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 writes: > >> Andreas Leha 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] [BUG] new exporter and #+BEGIN_CENTER
Jambunathan K 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] Converting Org to Sweave (*.Rnw)
Julian Gehring 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]
[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 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
<>=
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
Re: [O] Output of R babel blocks with quotes is mangled/truncated
Viktor Rosenfeld 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. Berry Dept 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 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 writes: > Hello, > > Charles Berry 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. Berry Dept 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 writes: > Ken Williams 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 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 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
Nick Dokos writes: > cbe...@tajo.ucsd.edu wrote: > >> cbe...@tajo.ucsd.edu writes: >> >> inline correction below. >> >> > Eric Schulte writes: >> > >> >> Matthew Landis writes: >> >> >> >>> tajo.ucsd.edu> writes: >> >>> >> >>>> >> >>>> Eric Schulte 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
cbe...@tajo.ucsd.edu writes: inline correction below. > Eric Schulte writes: > >> Matthew Landis writes: >> >>> tajo.ucsd.edu> writes: >>> >>>> >>>> Eric Schulte 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
Eric Schulte writes: > Matthew Landis writes: > >> tajo.ucsd.edu> writes: >> >>> >>> Eric Schulte 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
Eric Schulte 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
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
[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. Berry Dept 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" 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
| <>
| <>
| #+end_src
`
HTH,
Chuck
>
> Thanks very much.
>
> --Chris
[snip]
--
Charles C. Berry Dept 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 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 Vauban" writes: >> >>> Hi Eric and all, >>> >>> Eric Schulte wrote: "Sebastien Vauban" 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."
Re: [O] [babel] PROPERTY doesn't do what BABEL did
Eric Schulte 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 >> >> --- >> >>
[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] Not overwriting unchanged source code files when tangling
Holger Hoefling 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'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 dir="ltr"><mailto:carsten.domi...@gmail.com> 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 '(org-babel-tangle-file "http://somefile.org";)' > 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 writes: > Hi Eric, > > On Wed, Aug 24, 2011 at 3:58 PM, Eric Schulte wrote: >> Vikas Rawal 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
