Re: [O] Bugs in org-drill
Hi, On Tue, Dec 3, 2013 at 6:00 PM, Carsten Dominik carsten.domi...@gmail.com wrote: On 3.12.2013, at 17:47, Lukas Fuernkranz lukas.fuernkr...@gmail.com wrote: [...] On Mon, May 20, 2013 at 8:53 PM, Lukas Fuernkranz lukas.fuernkr...@gmail.com wrote: On Tue, May 14, 2013 at 5:19 PM, Ivan Kanis ban...@kanis.fr wrote: I tried 1.8 two weeks ago. I got two bugs in org-drill: [...] I also encountered problem 1 and opened a bug report: https://bitbucket.org/eeeickythump/org-drill/issue/9/org-drill-doesnt-accept-near-miss-and the mentioned problem was fixed quite some time ago in org-drill's repository (see the link above). However org-plus-contrib on ELPA apparently still comes with an old version of org-drill. What needs to be done to fix this? Could someone of you do this? I will grab and install the new version. when I install org-plus-contrib from ELPA I get org-drill version 2.3.7 (which suffers from the bug mentioned above), but according to http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp/org-drill.el?id=739b2649c74d01ecb515cc922d99bf26b6d403d7 it should come with version 2.4.0 (that fixes the mentioned bug and probably other stuff) -- shouldn't it? Anyway, I'm quite confused about this as I'm not familiar with org-mode's git repository. Is there something wrong with my configuration or why do I get the old version? Regards, Lukas
Re: [O] LaTeX export: Unknown LaTeX class `org-article'
Peter Davis p...@pfdstudio.com writes: [...] Ok, something weird is going on. This worked on my office MacBook, but when I try on the home one, also with org 8.2.3c, org-export-latex-classes is defined, but org-latex-classes is not. Any clues? this sounds like a mixed installation. do you have an old version of org lying around, maybe as part of the emacs installation? are the two systems running different versions of emacs? Both running emacs 24.3.1, same build Ummm, strange. What happens if you C-h v org-export-latex-classes RET e.g. does it show is a variable defined in some file? If so, where do you end up if you hit RET on that file name? -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5g-539-g0b67b7
Re: [O] Electric-indent-mode and lists
Hello, Florian Lindner mailingli...@xgm.de writes: emacs -Q M-x electric-indent-mode C-x C-f some/nonexistent/file.org Now entering * abc + a + b + c Each list entry is idented furthermore. I doesn't happen if I use M-Ret to enter a list item. Or is this behavior intended? I cannot reproduce the problem with latest Org. In any case, you can tweak `electric-indent-functions' so a function returns `no-indent' when (org-at-item-p) is non-nil. Regards, -- Nicolas Goaziou
Re: [O] LaTeX export: Unknown LaTeX class `org-article'
Eric S Fraga e.fr...@ucl.ac.uk writes: Peter Davis p...@pfdstudio.com writes: [...] Ok, something weird is going on. This worked on my office MacBook, but when I try on the home one, also with org 8.2.3c, org-export-latex-classes is defined, but org-latex-classes is not. Any clues? this sounds like a mixed installation. do you have an old version of org lying around, maybe as part of the emacs installation? are the two systems running different versions of emacs? Both running emacs 24.3.1, same build Ummm, strange. What happens if you C-h v org-export-latex-classes RET e.g. does it show is a variable defined in some file? If so, where do you end up if you hit RET on that file name? It does say the variable is define in org-latex.el, and clicking on that name takes me to the definition in org-latex.el.gz. Perhaps that one file is out of sync somehow? Strange. Thanks, -pd
[O] [RFC] Make QUOTE an export keyword instead of an element type
Hello, Quote sections are special sections triggered when their headline container has the QUOTE keyword in it: * QUOTE Headline This is a quote section. They are inherited (as many other things) from the previous export framework. The behaviour of this keyword in undocumented in Org manual, but, judging by old sources, it means that contents of such an headline should be exported verbatim (i.e. as an /example/ block, not a /quote/ block). At the moment, they are parsed specially by Org Elements, but I think it is a mistake. Like COMMENT keyword in headlines, QUOTE is more an instruction for the export framework. Therefore, they should be parsed as regular sections, and treated specially during export. The following patches permit it, in 3 steps: 1. Remove special parsing from org-element.el, 2. Turn section contents into a big example block. 3. Remove quote section translators from export back-ends (contrib directory handled separately) This change implies that any quote-section translator and filter is ignored (but it will not generate an error if present). It also means that an export back-end cannot tell the difference between an example block and a quote section. Since quote sections were treated as example blocks (except in ox-ascii.el), the export behaviour will remain unchanged (except in ox-ascii.el). Alternatives: - Treat their contents as `quote-blocks' instead of `example-block' - Remove them altogether, since they don't bring anything new. As a side note, if they are here to stay, it would be good to document them. WDYT? Regards, -- Nicolas Goaziou From 0b156539b8a0b050b6848be89926a10ce983bc83 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou n.goaz...@gmail.com Date: Sun, 26 Jan 2014 14:09:45 +0100 Subject: [PATCH 1/4] org-element: Do not parse quote sections specially To: n.goaz...@gmail.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=1.8.5.3 This is a multi-part message in MIME format. --1.8.5.3 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit * lisp/org-element.el (org-element-quote-section-parser, org-element-quote-section-interpreter): Remove functions. (org-element--current-element, org-element--parse-elements): Do not handle quote sections at all. * testing/lisp/test-org-element.el (test-org-element/quote-section-parser): Remove test. Like COMMENT keyword, QUOTE is only an export instruction, which has to be handled at the export framework level, not at the parser's. --- lisp/org-element.el | 67 +--- testing/lisp/test-org-element.el | 14 - 2 files changed, 15 insertions(+), 66 deletions(-) --1.8.5.3 Content-Type: text/x-patch; name=0001-org-element-Do-not-parse-quote-sections-specially.patch Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename=0001-org-element-Do-not-parse-quote-sections-specially.patch diff --git a/lisp/org-element.el b/lisp/org-element.el index 0027f1f..92eff3a 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -31,13 +31,12 @@ ;; ;; An element always starts and ends at the beginning of a line. With ;; a few exceptions (`clock', `headline', `inlinetask', `item', -;; `planning', `node-property', `quote-section' `section' and -;; `table-row' types), it can also accept a fixed set of keywords as -;; attributes. Those are called affiliated keywords to distinguish -;; them from other keywords, which are full-fledged elements. Almost -;; all affiliated keywords are referenced in -;; `org-element-affiliated-keywords'; the others are export attributes -;; and start with ATTR_ prefix. +;; `planning', `node-property', `section' and `table-row' types), it +;; can also accept a fixed set of keywords as attributes. Those are +;; called affiliated keywords to distinguish them from other +;; keywords, which are full-fledged elements. Almost all affiliated +;; keywords are referenced in `org-element-affiliated-keywords'; the +;; others are export attributes and start with ATTR_ prefix. ;; ;; Element containing other elements (and only elements) are called ;; greater elements. Concerned types are: `center-block', `drawer', @@ -48,10 +47,9 @@ ;; Other element types are: `babel-call', `clock', `comment', ;; `comment-block', `diary-sexp', `example-block', `export-block', ;; `fixed-width', `horizontal-rule', `keyword', `latex-environment', -;; `node-property', `paragraph', `planning', `quote-section', -;; `src-block', `table', `table-row' and `verse-block'. Among them, -;; `paragraph' and `verse-block' types can contain Org objects and -;; plain text. +;; `node-property', `paragraph', `planning', `src-block', `table', +;; `table-row' and `verse-block'. Among them, `paragraph' and +;; `verse-block' types can contain Org objects and plain text. ;; ;; Objects are related to document's contents. Some of them are ;; recursive. Associated types are of
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Aloha Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: At the moment, they are parsed specially by Org Elements, but I think it is a mistake. Like COMMENT keyword in headlines, QUOTE is more an instruction for the export framework. Therefore, they should be parsed as regular sections, and treated specially during export. The following patches permit it, in 3 steps: 1. Remove special parsing from org-element.el, 2. Turn section contents into a big example block. 3. Remove quote section translators from export back-ends (contrib directory handled separately) This change implies that any quote-section translator and filter is ignored (but it will not generate an error if present). It also means that an export back-end cannot tell the difference between an example block and a quote section. Since quote sections were treated as example blocks (except in ox-ascii.el), the export behaviour will remain unchanged (except in ox-ascii.el). Alternatives: - Treat their contents as `quote-blocks' instead of `example-block' - Remove them altogether, since they don't bring anything new. I didn't know about this undocumented feature. Since it doesn't bring anything new, I'm fine with removing it altogether. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] Conditional source-block execution based on LaTeX document class?
Just ran into something that I'm really not sure how to handle. I thought I could handle it with export filters, but actually it involves babel, and that makes it more involved than I initially suspected. I'm working on a large project involving five beamer presentations (one per day), and the sources for these will be combined into one massive beamerarticle document for the workshop attendees' reference. (If they want to print it out, it will look okay, but I won't encourage the killing of trees -- actually my early versions of the article layout looks fine on a tablet.) I'm using LaTeX's glossaries package for indexed references at the end. But, \newglossaryentry is really annoying. So I made some org tables for the glossary entries and I wrote some emacs-lisp src blocks to convert them into the right syntax for LaTeX. So here's the problem... In the individual beamer slideshows, I need to put the \newglossaryentry commands within a frame (because I'm also using beamer's ignorenonframetext class option, so that I can have text that appears only in the article but not the slides). That is (if I have H:3): *** Some frame A block Some text #+call: makegloss #+results: makegloss ... then the results of the src block to go into the frame, and then beamer doesn't ignore them and everything works. For the final article, I need a structure like this: #+options: H:4 * Day 1 #+include 01-intro/01-contents.org * Day 2 #+include 02-synthesis/02-contents.org And the problem is, if the #+call commands are replicated in each 0x-contents file, then I will have redundant \newglossaryentry commands in the LaTeX output (in the end, multiplied five times). If there's no other way, I could live with that, but ideally, I'd like to be able to put the #+call lines into the master file for the article, and then be able to suppress their execution in the #+includes. Ideally, this would be automatic based on the LaTeX document class. Any way to do this? I suppose, at worst, I can just put all of the #+call lines in, and simply say no to the ones I don't want in the final compilation. Thanks, hjh
[O] #+include doesn't export anything?
I had just asked a question about src-blocks in exports, but things just got a little weirder. Below is my export file, referring to the master source for day 1. It exports *nothing* from 01-contents.org. I get all the stuff from the header, but 01-contents.org may as well not be there. Is this a wrong approach? What's strange is that babel asks me if I want to execute #+call lines that are only in 01-contents.org, but ox-beamer ignores the lot. ?? I'll find some workaround, but this is highly inconvenient. hjh ~~ #+startup: beamer #+TITLE: SuperCollider Week, Day 1 \\ Introductory SC, Synthesis and Sequencing #+DATE: \today #+AUTHOR: H. James Harkins #+EMAIL: #+INCLUDE: ../slidehead.org #+include: ../glossary.org #+include: ./01-contents.org ~~
Re: [O] #+include doesn't export anything?
Hello, James Harkins jamshar...@gmail.com writes: I had just asked a question about src-blocks in exports, but things just got a little weirder. Below is my export file, referring to the master source for day 1. It exports *nothing* from 01-contents.org. I get all the stuff from the header, but 01-contents.org may as well not be there. Is this a wrong approach? What's strange is that babel asks me if I want to execute #+call lines that are only in 01-contents.org, but ox-beamer ignores the lot. ?? I'll find some workaround, but this is highly inconvenient. hjh ~~ #+startup: beamer #+TITLE: SuperCollider Week, Day 1 \\ Introductory SC, Synthesis and Sequencing #+DATE: \today #+AUTHOR: H. James Harkins #+EMAIL: #+INCLUDE: ../slidehead.org #+include: ../glossary.org #+include: ./01-contents.org ~~ What happens if you call (org-export-expand-include-keyword) in that buffer? Are the resulting changes valid? Regards, -- Nicolas Goaziou
Re: [O] Conditional source-block execution based on LaTeX document class?
Dnia 2014-01-26, o godz. 23:44:48 James Harkins jamshar...@gmail.com napisał(a): Just ran into something that I'm really not sure how to handle. I thought I could handle it with export filters, but actually it involves babel, and that makes it more involved than I initially suspected. I'm working on a large project involving five beamer presentations (one per day), and the sources for these will be combined into one massive beamerarticle document for the workshop attendees' reference. (If they want to print it out, it will look okay, but I won't encourage the killing of trees -- actually my early versions of the article layout looks fine on a tablet.) I'm using LaTeX's glossaries package for indexed references at the end. But, \newglossaryentry is really annoying. So I made some org tables for the glossary entries and I wrote some emacs-lisp src blocks to convert them into the right syntax for LaTeX. So here's the problem... In the individual beamer slideshows, I need to put the \newglossaryentry commands within a frame (because I'm also using beamer's ignorenonframetext class option, so that I can have text that appears only in the article but not the slides). That is (if I have H:3): *** Some frame A block Some text #+call: makegloss #+results: makegloss ... then the results of the src block to go into the frame, and then beamer doesn't ignore them and everything works. For the final article, I need a structure like this: #+options: H:4 * Day 1 #+include 01-intro/01-contents.org * Day 2 #+include 02-synthesis/02-contents.org And the problem is, if the #+call commands are replicated in each 0x-contents file, then I will have redundant \newglossaryentry commands in the LaTeX output (in the end, multiplied five times). If there's no other way, I could live with that, but ideally, I'd like to be able to put the #+call lines into the master file for the article, and then be able to suppress their execution in the #+includes. Ideally, this would be automatic based on the LaTeX document class. Any way to do this? I suppose, at worst, I can just put all of the #+call lines in, and simply say no to the ones I don't want in the final compilation. Ugly hack, but what about redefining \newglossaryentry? In general, since Org-to-LaTeX export is a bit simplistic (as compared to (La)TeX itself), I guess that solving such problems on the LaTeX side might be easier. (That said, beamer is rather opposite of simplistic, so it might as well be not true...) Thanks, hjh HTH, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] #+include doesn't export anything?
On Monday, January 27, 2014 12:36:22 AM HKT, Nicolas Goaziou wrote: What happens if you call (org-export-expand-include-keyword) in that buffer? Are the resulting changes valid? (Aside: This was challenging at first, b/c org-export-expand-include-keyword is not interactive.) Ah... now I see it. #+INCLUDE: ../slidehead.org #+include: ../glossary.org #+include: ./01-contents.org The last heading in glossary.org is :noexport: -- then, the include for 01-contents.org thinks that it should go underneath the last heading to be created in glossary.org. So, everything that was a top level heading in 01-contents.org becomes a second-level heading, underneath a :noexport: tag. So, that pretty much blows my file structure to smithereens. I suppose it's actually debatable. But, I would have assumed that the last heading level in an included file would be unwound before including the next file. That is: ~~ #+include something.org * Heading #+include something-else.org ~~ ... would denote everything in something-else.org by one level, while... ~~ #+include something.org #+include something-else.org ~~ ... would leave something-else.org's levels untouched, regardless of the headline levels in something.org. Hm. It looks like my whole idea about structuring this project was badly conceived from the beginning :( either that, or the include mechanism is not thoroughly thought-through. hjh
Re: [O] #+include doesn't export anything?
James Harkins jamshar...@gmail.com writes: I suppose it's actually debatable. But, I would have assumed that the last heading level in an included file would be unwound before including the next file. That is: ~~ #+include something.org * Heading #+include something-else.org ~~ ... would denote everything in something-else.org by one level, while... ~~ #+include something.org #+include something-else.org ~~ ... would leave something-else.org's levels untouched, regardless of the headline levels in something.org. Hm. It looks like my whole idea about structuring this project was badly conceived from the beginning :( either that, or the include mechanism is not thoroughly thought-through. See (info (org) Include files), in particular :minlevel keyword. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Nicolas Goaziou n.goaz...@gmail.com writes: Alternatives: - Treat their contents as `quote-blocks' instead of `example-block' - Remove them altogether, since they don't bring anything new. As a side note, if they are here to stay, it would be good to document them. WDYT? I'd be happy to see it go. I'm happy to reserve the space before the section-name for TODO-like words (that is COMMENT can also go IMO). –Rasmus -- May contains speling mistake
Re: [O] Naming a table produced by a CALL
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Loris, Loris Bennett loris.benn...@fu-berlin.de writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Loris Bennett loris.benn...@fu-berlin.de writes: Hi, I have a CALL which produces a table, which just gets the keyword RESULT. I would like to plot the data in the table with R and so would like to refer to the data in the table. It seems I need to need to replace RESULT by NAME in org-babel-results-keyword, but how do I pass the actual name? Cheers, Loris Make the CALL named: #+name: foo #+call: foo() HTH, Andreas Thanks. In retrospect, that seems quite obvious. Where is this documented and should it be mentioned here: http://orgmode.org/manual/Evaluating-code-blocks.html This is a 'not-so-old' feature. Yes, I believe this was added in the last month or two. And I do not know whether it is documented at all. I agree that 'Evaluating code blocks' is where the documentation should go. I'll happily apply a documentation patch. I don't believe the copyright assignment required for code contributions is required for contributions to the documentation. Best, Regards, Andreas ? Cheers, Loris -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Conditional source-block execution based on LaTeX document class?
Hi James, Maybe you could do something like the following... #+name: export-hdr-arg-backend-dep #+begin_src emacs-lisp (message do stuff) #+end_src #+call: export-hdr-arg-backend-dep() :exports (if (eq org-export-current-backend 'beamer) none results) Best, James Harkins jamshar...@gmail.com writes: Just ran into something that I'm really not sure how to handle. I thought I could handle it with export filters, but actually it involves babel, and that makes it more involved than I initially suspected. I'm working on a large project involving five beamer presentations (one per day), and the sources for these will be combined into one massive beamerarticle document for the workshop attendees' reference. (If they want to print it out, it will look okay, but I won't encourage the killing of trees -- actually my early versions of the article layout looks fine on a tablet.) I'm using LaTeX's glossaries package for indexed references at the end. But, \newglossaryentry is really annoying. So I made some org tables for the glossary entries and I wrote some emacs-lisp src blocks to convert them into the right syntax for LaTeX. So here's the problem... In the individual beamer slideshows, I need to put the \newglossaryentry commands within a frame (because I'm also using beamer's ignorenonframetext class option, so that I can have text that appears only in the article but not the slides). That is (if I have H:3): *** Some frame A block Some text #+call: makegloss #+results: makegloss ... then the results of the src block to go into the frame, and then beamer doesn't ignore them and everything works. For the final article, I need a structure like this: #+options: H:4 * Day 1 #+include 01-intro/01-contents.org * Day 2 #+include 02-synthesis/02-contents.org And the problem is, if the #+call commands are replicated in each 0x-contents file, then I will have redundant \newglossaryentry commands in the LaTeX output (in the end, multiplied five times). If there's no other way, I could live with that, but ideally, I'd like to be able to put the #+call lines into the master file for the article, and then be able to suppress their execution in the #+includes. Ideally, this would be automatic based on the LaTeX document class. Any way to do this? I suppose, at worst, I can just put all of the #+call lines in, and simply say no to the ones I don't want in the final compilation. Thanks, hjh -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] How to use ox-bibtex
o.castillo.felis...@gmail.com o.castillo.felis...@gmail.com writes:
Dear community,
I'm using org-mode to draft most of my activities, and day after day I get
closer to managing my paper writing. Nonetheless, there is a point still
drives me crazy.
All over the web I find post about using such or what tool to get emacs
org-mode to work with Bibtex... all of them seems complex to execute. I
found the exported ox-bibtex.el [1] (included in my installation from git),
which 'It also introduces cite syntax for Org links.', but no examples of
the usage are included in this document.
*Question*
Can anyone provide a minimal example of the use to this tool, including the
configuration (if needed), and the necessary external (non-org) files?
The attached two files (.org and .bib) provide an example of usage.
#+Title: An Example Demonstrating ox-bibtex Usage
#+Author: Eric Schulte
#+Options: toc:nil ^:{}
An example document demonstrating generation of bibliographies for
LaTeX, HTML and ASCII export using Org-mode cite:dominik2010org with
the =ox-bibtex= contributed package. Included code blocks are
executable for reproducibility cite:schulte2012multi.
(taken from the comments at the top of =ox-bibtex.el=)
* Introduction and Requirements
Use =cite= syntax for Org links (e.g., =cite:bibtexid=). For HTML and
ascii it uses the bibtex2html software from
http://www.lri.fr/~filliatr/bibtex2html/, and for ascii it uses the
pandoc software from http://johnmacfarlane.net/pandoc/.
* Usage
The usage is as follows:
: #+BIBLIOGRAPHY: bibfilebasename stylename optional-options
e.g. given =foo.bib= and using style plain:
: #+BIBLIOGRAPHY: foo plain option:-d
stylename can also be nil, in which case no style will be used.
Optional options are of the form:
: option:-foobar
pass '-foobar' to bibtex2html
e.g.,
| =option:-d= | sort by date |
| =option:-a= | sort as BibTeX (usually by author) *default* |
| =option:-u= | unsorted i.e. same order as in .bib file |
| =option:-r= | reverse the sort |
See the bibtex2html man page for more. Multiple options can be
combined like:
: option:-d option:-r
Limiting to only the entries cited in the document:
: limit:t
For LaTeX export this simply inserts the lines
: \bibliographystyle{plain}
: \bibliography{foo}
into the TeX file when exporting.
For HTML export it:
1) converts all =\cite{foo}= and =[[cite:foo=]] to links to the
bibliography,
2) creates a =foo.html= and =foo_bib.html=,
3) includes the contents of =foo.html= in the exported HTML file.
For ascii export it:
1) converts all =\cite{foo}= and =[[cite:foo=]] to links to the
bibliography,
2) creates a =foo.txt= and =foo_bib.html=,
3) includes the contents of foo.txt in the exported ascii file.
For LaTeX export it:
1) converts all =[[cite:foo=]] to =\cite{foo}=.
* Emacs Configuration
The =.emacs= configuration is simple. With path to Org-mode's
=contrib/= repository in your load path, require =ox-bibtex= as in the
following example.
#+begin_src emacs-lisp
(add-to-list 'load-path ~/.emacs.d/src/org-mode/contrib/lisp/)
(require 'ox-bibtex)
#+end_src
#+BIBLIOGRAPHY: ox-bibtex-example plain
@book{dominik2010org,
title={The Org Mode 7 Reference Manual-Organize your life with GNU Emacs},
author={Dominik, Carsten},
year={2010},
publisher={Network Theory Ltd.}
}
@article{schulte2012multi,
title={A multi-language computing environment for literate programming and reproducible research},
author={Schulte, Eric and Davison, Dan and Dye, Thomas and Dominik, Carsten},
journal={Journal of Statistical Software},
volume={46},
number={3},
pages={1--24},
year={2012},
publisher={American Statistical Association}
}
Best,
Thank you!
[1]
http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=contrib/lisp/ox-bibtex.el;hb=HEAD
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Re: [O] [babel] Using :prologue and :epilogue with unbalanced brackets
Rainer M Krug rai...@krugs.de writes:
On 01/20/14, 16:34 , Eric Schulte wrote:
Rainer M Krug rai...@krugs.de writes:
Hi
I would like to use :prologue and :epilogue to enclose the code block
in a local({}) block, i.e.
* test
#+begin_src R :prologue local({ :epilogue })
qwerty - test
#+end_src
I tried wrapping the prologue and epilogue values in quotes so that they
would be interpreted as strings, and I no longer see the problem you
describe and it works in a session, but I get a different R issues
outside of a session.
Agreed -
* test
#+begin_src R :results output :prologue local({ :epilogue }) :session
cat(Test)
#+end_src
#+RESULTS:
no :session nothing happens
using :session the execution does not complete because the :epilogue is not
appended.
The problem here is when `org-babel-balanced-split' parses the following
string.
:results output :prologue \local({\ :epilogue \})\ :session
It isn't smart enough to *not* balance the ({}) parens because of the
enclosing quotes. Unfortunately I don't have time to address this right
now. A hacky work around would be the following...
#+headers: :epilogue })
#+headers: :prologue local({
#+begin_src R :results output :session
cat(Test)
#+end_src
Best,
* test 2
#+begin_src R :results output :prologue cat(1, '###\n') :epilogue cat(2,
'###\n') :session
cat(Test\n)
#+end_src
#+RESULTS:
: 1 ###
: Test
works under :session and without
but
* test 2
#+begin_src R :results output :prologue {cat(1, 2 ) :epilogue cat(2,
3)} :session
cat(Test\n)
#+end_src
works only without :session as R is waiting for the } which is in the
:epilogue but which is not added.
Cheers,
Rainer
Best,
But the problem seems to be the unbalanced brackets, and everything is
passed on as the prologue, as I get the error:
Error: unexpected ':' in:
{
local({ :
Execution halted
Can I somehow use unbalanced brackets, or is this a missing option in
epilogue and prologue?
Cheers,
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Re: [O] [babel] suggestion: wrap creation of graphics into try() block
I'll send you the patch then. Sounds great, thanks. OK - here it is attached (my first patch to org :-) ) - let me know if it is OK. Looks good to me, I've just applied it. Thanks! -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] Which `odt-content' variable should I use? Why are there two?
I was browsing the customize group org-export-odt. I found two variables that seem to do the same thing. In org-odt.el, we have org-export-odt-content-template-file while in ox-odt.el, we have org-odt-content-template-file Do I need to worry about this. Will org-export check both locations, or will one take precedence somehow? (As in, if one is `nil', will it more or less have no effect on the other?) I imagine I could do some print variable testing to discover on my own, but also wanted to see if comments would be enlightening to my understanding in general. - Brady (learning Emacs because I found Org-mode; programmer)
[O] Exporting text
Well, I don't know how messed up my org-mode installation is, but in addition to my problems with LaTeX, even text exporting fails. When I try C-c C-e t A, I get: Symbol's value as variable is void: org-drawers Any clues what the problem might be? Thanks! -pd -- Peter Davis The Tech Curmudgeon www.techcurmudgeon.com
Re: [O] How to use ox-bibtex
Thank you Eric, I'll try it asap! Cheers! On Jan 26, 2014 4:20 PM, Eric Schulte schulte.e...@gmail.com wrote: o.castillo.felis...@gmail.com o.castillo.felis...@gmail.com writes: Dear community, I'm using org-mode to draft most of my activities, and day after day I get closer to managing my paper writing. Nonetheless, there is a point still drives me crazy. All over the web I find post about using such or what tool to get emacs org-mode to work with Bibtex... all of them seems complex to execute. I found the exported ox-bibtex.el [1] (included in my installation from git), which 'It also introduces cite syntax for Org links.', but no examples of the usage are included in this document. *Question* Can anyone provide a minimal example of the use to this tool, including the configuration (if needed), and the necessary external (non-org) files? The attached two files (.org and .bib) provide an example of usage. Best, Thank you! [1] http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=contrib/lisp/ox-bibtex.el;hb=HEAD -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] LaTeX export: Unknown LaTeX class `org-article'
Peter Davis p...@pfdstudio.com writes: Eric S Fraga e.fr...@ucl.ac.uk writes: Peter Davis p...@pfdstudio.com writes: [...] Ok, something weird is going on. This worked on my office MacBook, but when I try on the home one, also with org 8.2.3c, org-export-latex-classes is defined, but org-latex-classes is not. Any clues? this sounds like a mixed installation. do you have an old version of org lying around, maybe as part of the emacs installation? are the two systems running different versions of emacs? Both running emacs 24.3.1, same build Ummm, strange. What happens if you C-h v org-export-latex-classes RET e.g. does it show is a variable defined in some file? If so, where do you end up if you hit RET on that file name? It does say the variable is define in org-latex.el, and clicking on that name takes me to the definition in org-latex.el.gz. Perhaps that one file is out of sync somehow? Strange. This one file is probably part of the org-mode distributed with your emacs (that's why it is compressed: the files that you get through git, or tar or ELPA are uncompressed[fn:1]). You are picking that up before you pick up the org-latex.el from the 8.2.3c version of org-mode, presumably because you loaded it early before you changed the value of load-path to prefer the 8.2.3c version. What happens if you set load-path properly at the very beginning of your .emacs file? See section 1.2 of the org manual. Footnotes: [fn:1] I'm sure about git, but it's only my belief in the other two cases since I have never used either of those methods. -- Nick
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Rasmus ras...@gmx.us writes: Nicolas Goaziou n.goaz...@gmail.com writes: Alternatives: - Treat their contents as `quote-blocks' instead of `example-block' - Remove them altogether, since they don't bring anything new. As a side note, if they are here to stay, it would be good to document them. WDYT? I'd be happy to see it go. I'm happy to reserve the space before the section-name for TODO-like words (that is COMMENT can also go IMO). I agree. Getting rid of COMMENT also sounds reasonable to me although that might produce more backward compatibility problems since it's more likely to have been used. But since the functionality is easily achievable (through :noexport: tags and #+BEGIN_COMMENT/#+END_COMMENT blocks e.g. - one can even add a :comment: tag to the EXCLUDE set if so desired), it should be possible to deprecate it for a while, and then get rid of it. As an added bonus, we can then get rid of one of the (iirc) questionable keydefs: C-c ; won't have anything to do. -- Nick
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
My guess is that quote should go. Does anybody use it? I'd strongly want to keep comment, however, if that were questioned. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
[O] export to ODT fails strangely
Hello, I hope somebody can point me in the right direction. I am trying to export a large document to ODT to share with my collaborators. Exporting to LaTeX works like a charm. However, with ODT, the exporter fails with: , | OpenDocument export failed: FIXME: Resolve (paragraph (:begin 23510 :end | 23635 :contents-begin 23599 :contents-end 23629 :post-blank 1 | :post-affiliated 23599 :name fig:graph :caption (((#(Dependency graph | of major tasks in the project. 0 47 (:parent #4) :results () | [...] ` The messages buffer contains a very large amount of text, including most of my document in one form or another it seems... I have no idea where to start. I cannot seem to come up with a minimal example and the long example has too much confidential material for me to pass on to anybody at all unfortunately. Argg. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5g-539-g0b67b7
Re: [O] export to ODT fails strangely
Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: I hope somebody can point me in the right direction. I am trying to export a large document to ODT to share with my collaborators. Exporting to LaTeX works like a charm. However, with ODT, the exporter fails with: , | OpenDocument export failed: FIXME: Resolve (paragraph (:begin 23510 :end | 23635 :contents-begin 23599 :contents-end 23629 :post-blank 1 | :post-affiliated 23599 :name fig:graph :caption (((#(Dependency graph | of major tasks in the project. 0 47 (:parent #4) :results () | [...] ` I guess you are cross-referencing to a paragraph (probably a standalone image) named fig:graph. You can probably get an ECM if you isolate both that paragraph and the link referring to it. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Hi Nicolas, I think removing QUOTE won't hurt that much. PS: Removing COMMENT would be more problematic, as it is very handy to temporarily prevent a section from being exported or tangled. -- Bastien
Re: [O] bug: Please save the buffer to a file before refiling when the buffer is already saved
Samuel Wales samolog...@gmail.com writes: When I run refile goto in the same buffer, it goes to the correct location and then does that. When I run refile goto in a different buffer, it does not go anywhere and it does that. Because for now you need to add the file name when refiling to a different buffer. I agree we should provide a better error, or just ask again. I don't see how to remove the need for the file name though. Taking into account that several buffers may contain subtrees with the same headline. If you have any idea, please let us know. -- Bastien
Re: [O] Bugs in org-drill
Hi Lukas, Lukas Fuernkranz lukas.fuernkr...@gmail.com writes: when I install org-plus-contrib from ELPA I get org-drill version 2.3.7 (which suffers from the bug mentioned above), but according to http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp/org-drill.el?id=739b2649c74d01ecb515cc922d99bf26b6d403d7 it should come with version 2.4.0 (that fixes the mentioned bug and probably other stuff) -- shouldn't it? Anyway, I'm quite confused about this as I'm not familiar with org-mode's git repository. Is there something wrong with my configuration or why do I get the old version? org-plus-contrib is built from the maint branch of the repo, which contains the latest stable version. Probably the bugs were fixed in the master branch version, so you'll have to clone Org's repo to have them. ~$ git clone git://orgmode.org/org-mode.git -- Bastien
Re: [O] Exporting text
Hi Peter, Peter Davis p...@pfdstudio.com writes: Well, I don't know how messed up my org-mode installation is, but in addition to my problems with LaTeX, even text exporting fails. When I try C-c C-e t A, I get: Symbol's value as variable is void: org-drawers Any clues what the problem might be? You don't give us a lot to chew on :) How did you install Org? I suggest you install Org through git, as explained in the manual. Don't forget to ~$ make autoloads or just ~$ make HTH, -- Bastien
Re: [O] emacs calc and src block editing
On 25.01.2014 13:49, Eric S Fraga wrote: There is a niggling aspect of editing source code blocks. If, while in the src block buffer (reached by C-c '), if you start up calc and request calc-copy-to-buffer to place a result in the source code being edited, the copy is actually placed in the original org buffer and subsequently lost when exiting the src buffer. In my opinion, the copy should be place in the src buffer at point. It is a feature of calc, not to copy to internal (starred) buffers. I have no idea whether or how this could be fixed. It's not a major problem but I thought I would mention it in case it's easy to fix. I'm afraid the only way to fix this is inside calc. You can do it yourself with advice, e.g.: (advice-add 'calc-find-writable-buffer :before-until (lambda (buf mode) (if (and (string-match \\`\\*Org Src (buffer-name (car buf))) (get-buffer-window (car buf))) (car buf))) '((name . calc-copy-to-org-src))) Remove it with: (advice-remove 'calc-find-writable-buffer 'calc-copy-to-org-src) HTH.
[O] How to replace \( by $$ and such when exporting to markdown
Hi all, I'm trying to publish some beamer presentations with mathematical content as pages in octopress. I think I'm on my way to get a working setup, but I would like some help to achieve the following: With an up-to-date org (from git), define some functions that, when exporting to markdown with ox-md, automatically replace all instances of \(, \), \[ and \] with $$. Thanks in advance for any help. Rafael
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Bastien b...@gnu.org writes: PS: Removing COMMENT would be more problematic, as it is very handy to temporarily prevent a section from being exported or tangled. Doesn't a :noexport: tag do exactly that? (not sure about tangling actually, but that should be not be a big problem.) Why are two mechanisms needed? -- Nick
Re: [O] Feature Request: Allow Tangling Named INCLUDEs
Nick Daly wrote: Hi folks, I have a situation where I have many named code snippets currently available in external files, and would like to tangle them into an Org mode file. Eric Schulte schulte.e...@gmail.com writes: The following function works for me on a simple example file... Thank you, that function worked perfectly! It's now found a new home in my .emacs file. I'm not sure if this is common enough to have functionality added to the core. Maybe adding a `with-expanded-includes' macro would be useful though. It probably isn't very common at all, but its incredibly handy to keep the size of the org-mode file down: it keeps the literate source readable and free of boilerplate code. Thanks for your help, Nick pgpqkaftcNv2e.pgp Description: PGP signature
Re: [O] Feature Request: Allow Tangling Named INCLUDEs
Hi Bastien, Nick Daly wrote: Hi folks, I have a situation where I have many named code snippets currently available in external files, and would like to tangle them into an Org mode file. Bastien writes: I'm not the one who would undertake this, so my opinion on this should not matter much... but I think #+INCLUDE is well suited for exporting, not for tangling. I'm not able to say why, this is just an intuition. It seems to me like it's trying to unify exporting and tangling: this emphasizes that tangling is just another (very specific plain-text) form of exporting. Using Eric's function for exporting allows me to remove lots of boilerplate code from the source org file and keep the org source better focused on the code's function and structure. Sure it's weird, but it sure is handy. Nick pgpprBnhpS6um.pgp Description: PGP signature
Re: [O] #+include doesn't export anything?
On Jan 27, 2014 12:52 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: See (info (org) Include files), in particular :minlevel keyword. Oh... RTFM *sheepish grin* Workflow for using org: 1. Ask/complain about something on the mailing list. 2. Get a reference to the manual. 3. Find out that org already does that. Sorry for the complaining tone... I was inches away from declaring Day 1 of the workshop finished, then ran into this. Thanks again! hjh
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Nick Dokos ndo...@gmail.com writes: Bastien b...@gnu.org writes: PS: Removing COMMENT would be more problematic, as it is very handy to temporarily prevent a section from being exported or tangled. Doesn't a :noexport: tag do exactly that? (not sure about tangling actually, but that should be not be a big problem.) Why are two mechanisms needed? My thought exactly. You could even bind whatever keybinding COMMENT is on to toggle a noexport tag. Anyway, COMMENT discussions are slightly off topic. Rasmus -- The Kids call him Billy the Saint
Re: [O] How to replace \( by $$ and such when exporting to markdown
Rafael rvf0...@gmail.com writes: Hi all, I'm trying to publish some beamer presentations with mathematical content as pages in octopress. I think I'm on my way to get a working setup, but I would like some help to achieve the following: With an up-to-date org (from git), define some functions that, when exporting to markdown with ox-md, automatically replace all instances of \(, \), \[ and \] with $$. Thanks in advance for any help. You want to look into filters, probably org-export-filter-latex-fragment-functions and org-export-filter-latex-environment-functions. They are listed in ox.el. It should be fairly easy to deal with in your case with regexp. –Rasmus -- Together we'll stand, divided we'll fall
Re: [O] bug: Please save the buffer to a file before refiling when the buffer is already saved
Hi Bastien, Thank you for commenting and providing a clue. If I understand correctly, I don't see the need for any error or asking again, as it is always obvious what I, at least, want to do. It shows an olpath, so what I want is to refile or goto that olpath in every case. I also don't see the need for a distinction between this file and not this file. I never care what file I am in when I refile or goto. === It is the default Ido selection (after typing emacs) that errors, which seems like an indication that we need a different solution. In other cases, the default Ido selection always misfiles with no error (ECM similar to the thread leader message but without an error). Thus, you end up with stuff in the wrong place, silently. And in a third case, it silently fails. So you think you refiled but you did not. All three bugs happen quite frequently. Error, misfile, or silently doing nothing. === If the distinction between current file and non-current file is the reason, can we make it consistent by adding the filename for the same buffer also? That way all choices are equivalent. I find it confusing, as I never care what file I am in when I refile or goto. I don't think of Org as a single-file tree, but as a forest of equal trees. To have to think about this is the same file and no, I am going to a different file interrupts the refile for me; I never make that distinction. org-refile-use-outline-path set to file or full file path seems to not affect the result. === Perhaps somebody else who uses Ido refiling can test the thread leader case (/computer/emacs/myorg, refile to myorg, try to refile to emacs) and comment? === Are you talking about 2 olpaths pointing to different files? I never have that use case, because I always show the olpath and never repeat it. But what does happen is that I get one olpath that causes an error and another that does not. And the one that causes the error is always the Ido default, so I can't press RET. === Is what shows the same as what is used to disambiguate? Can we have the full path name + olpath in Lisp and only show the olpath? That would be ideal. I wanted to make this message shorter, but this is the best I was able to do. Thanks. Samuel On 1/26/14, Bastien b...@gnu.org wrote: Samuel Wales samolog...@gmail.com writes: When I run refile goto in the same buffer, it goes to the correct location and then does that. When I run refile goto in a different buffer, it does not go anywhere and it does that. Because for now you need to add the file name when refiling to a different buffer. I agree we should provide a better error, or just ask again. I don't see how to remove the need for the file name though. Taking into account that several buffers may contain subtrees with the same headline. If you have any idea, please let us know. -- Bastien -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Conditional source-block execution based on LaTeX document class?
On Monday, January 27, 2014 1:35:13 AM HKT, Eric Schulte wrote:
Hi James,
Maybe you could do something like the following...
#+name: export-hdr-arg-backend-dep
#+begin_src emacs-lisp
(message do stuff)
#+end_src
#+call: export-hdr-arg-backend-dep() :exports (if (eq
org-export-current-backend 'beamer) none results)
Ah... that's really cool. I hadn't realized you could run lisp in the
header arguments.
I couldn't check the current export backend because the org markup uses
beamer-specific features. The way to export the article format is to use
the beamer backend, but with document class = article and a
\usepackage{beamerarticle} line in the preamble.
But, I figured out a little hack: to put this at the top of the container
file:
# ## top of slide container
#+name: set-slide-flag
#+begin_src emacs-lisp :exports results :results value latex
(setq hjh-exporting-slides 't)
#+end_src
# ## top of article container
#+name: set-slide-flag
#+begin_src emacs-lisp :exports results :results value latex
(setq hjh-exporting-slides nil)
#+end_src
Then I can test this variable in all of the #+calls.
It seems to be working. When I export from the slide container file, it
runs each #+call once. When I export from the article container (where I
have the calls in the container), it runs the calls for the article
container but it does *not* execute the calls redundantly for the two slide
show source files I have now.
Thanks for the tip -- that's working a treat!
I think I owe it to the org community to write up this workflow, after the
project is over. The help from Nicolas, you and others has been invaluable.
hjh
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
On 26 Jan 2014, at 23:03, Bastien b...@gnu.org wrote: Hi Nicolas, I think removing QUOTE won't hurt that much. I agree. I would also like to see it removed. PS: Removing COMMENT would be more problematic, as it is very handy to temporarily prevent a section from being exported or tangled. Well, I am one person who does use COMMENT, and some of my COMMENT sections contain remarks and that should never make it into an exported file. My preference would be to keep this, for reasons of backward compatibility. - Carsten
Re: [O] No title in org-export-as-odt
Miguel Ruiz rbenit68 at yahoo.es writes: Any hint to get rid of the title in a org-export-as-odt session? I had the same problem. I noticed a lot of new lines, `\n', so I tried to remove more than just title. For my solution, I changed insert to ignore. ;; Preamble - Title, Author, Date etc. (ignore changed insert to ignore (let* ((title (org-export-data (plist-get info :title) info)) (author (and (plist-get info :with-author) (let ((auth (plist-get info :author))) (and auth (org-export-data auth info) (email (plist-get info :email)) ;; Switch on or off above vars based on user settings (author (and (plist-get info :with-author) (or author email))) (email (and (plist-get info :with-email) email))) (concat ;; Title. (when title (concat (format \ntext:p text:style-name=\%s\%s/text:p OrgTitle (format \ntext:title%s/text:title title)) ;; Separator. \ntext:p text:style-name=\OrgTitle\/)) This was in .emacs.d/elpa/org-[...]/ox-odt.el, that is, org export to odt. Also, not sure if it was necessary, but I deleted ox-odt.elc, the compiled version. Brady org-odt-format-preamble function says: ... (when title (concat (org-odt-format-stylized-paragraph 'title (org-odt-format-tags '(text:title . /text:title) title)) ;; separator text:p text:style-name=\OrgTitle\/)) ... So I only need to find a way to assign nil to title variable inside the document. Also I might define a new option with org-export-inbuffer-options-extra, but the elaboration of the function is beyond my knowledge. I would appreciate any idea.
