Re: [O] Capture aborts after selecting template
Bernt Hansen norang.ca> writes: > > If you want to set adaptive-fill-mode to nil you need something like > this instead: > > (add-hook 'text-mode-hook '(lambda () (setq adaptive-fill-mode nil))) > > Thanks for the detailed explanation. I added (add-hook 'text-mode-hook '(lambda () (setq adaptive-fill-mode nil))) as suggested. It didn't work at first, but then when I did C-u C-c C-x r to "reload org uncompiled" and generate a backtrace, it did work and I was able to use capture to add a todo list. The current status is that I have to reload org uncompiled every time I restart emacs to get capture to work. The situation is the same even when I comment out the preceding add-hook for text-mode-hook. Any idea how to fix this?
Re: [O] [ANN] Org Export in contrib
Hi everyone, is there anyone who is planning to implement a texinfo exporter based on org-elements? If not, I would write this exporter... - Carsten On 25.11.2011, at 18:32, Nicolas Goaziou wrote: > Hello, > > I've pushed org-export.el to contrib. It's a general export engine, > built on top of org-elements aiming at simplifying life of both > developers and maintainers (and, therefore, of end-users). > > It predates org-exp.el and org-special-blocks.el. Though, keep it mind > that, as advanced as it is, it isn't yet a drop-in replacement for > them. It still lacks an interface (à la `org-export'), back-ends, and > tons of testing and improvements. That being said, it's usable anyway > and one can already write back-ends for it. I'll show a silly example > later in this mail. > > Now, let's have a peek into the guts of that beast. > > Besides the parser, the generic exporter is made of three distinct > parts: > > - The communication channel consists in a property list, which is > created and updated during the process. Its use is to offer every > piece of information, would it be export options or contextual data, > all in a single place. The exhaustive list of properties is given in > "The Communication Channel" section of the file. > > - The transcoder walks the parse tree, ignores or treat as plain text > elements and objects according to export options, and eventually calls > back-end specific functions to do the real transcoding, concatenating > their return value along the way. > > - The filter system is activated at the very beginning and the very end > of the export process, and each time an element or an object has been > converted. It is the entry point to fine-tune standard output from > back-end transcoders. > > The core function is `org-export-as'. It returns the transcoded buffer > as a string. > > In order to derive an exporter out of this generic implementation, one > can define a transcode function for each element or object. Such > function should return a string for the corresponding element, without > any trailing space, or nil. It must accept three arguments: > > 1. the element or object itself, > 2. its contents, or nil when it isn't recursive, > 3. the property list used as a communication channel. > > If no such function is found, that element or object type will simply be > ignored, along with any separating blank line. The same will happen if > the function returns the nil value. If that function returns the empty > string, the type will be ignored, but the blank lines will be kept. > > Contents, when not nil, are stripped from any global indentation > (although the relative one is preserved). They also always end with > a single newline character. > > These functions must follow a strict naming convention: > `org-BACKEND-TYPE' where, obviously, BACKEND is the name of the export > back-end and TYPE the type of the element or object handled. > > Moreover, two additional functions can be defined. On the one hand, > `org-BACKEND-template' returns the final transcoded string, and can be > used to add a preamble and a postamble to document's body. It must > accept two arguments: the transcoded string and the property list > containing export options. On the other hand, `org-BACKEND-plain-text', > when defined, is to be called on every text not recognized as an element > or an object. It must accept two arguments: the text string and the > information channel. > > Any back-end can define its own variables. Among them, those > customizables should belong to the `org-export-BACKEND' group. Also, > a special variable, `org-BACKEND-option-alist', allows to define buffer > keywords and "#+options:" items specific to that back-end. See > `org-export-option-alist' for supported defaults and syntax. > > Tools for common tasks across back-ends are implemented in the last > part of the file. > > > * For Maintainers > > To word it differently, this exporter doesn't rely on any > text-property during the process. Thus, it makes > `org-if-unprotected-at' and alike obsolete in the whole code base. Org > core doesn't have to bother anymore about its exporter weaknesses. > > Also, buffer's pre-processing is reduced to its strict minimum: Babel > code expansion. No footnote normalization, list markers to add and > remove... > > Being only a beefed-up parse tree reader, any element or object added > to Elements is available through the exporter with no further > modification. Back-end just have to create the appropriate new > transcoders, unless that element or object should be ignored anyway. > > > * For Developers > > All data needed is available in two places: the properties associated > to the element being transcoded, through the use of > `org-element-get-property', and the communication channel, with the > help of `plist-get'. Period. > > Also, the exporter takes care about all the filtering required by > options, and enfor
Re: [O] [ANN] Org Export in contrib
Hi Nicolas, a few comments: On 25.11.2011, at 19:57, Nicolas Goaziou wrote: > > Completing myself, I'll add a few notes about the differences between > the current exporter and this one. While it tries to mimic most of the > behaviours of its ancestor, some points just couldn't fit in the new > scheme, would it be for a technical reason or by design. > > Here follows a rough list stating how the new engine stands with regards > to the older one. When possible, the reasons justifying that the > difference remains are given. > > 1. It's slower. Indeed, it has to first parse completely the area to > transcode, even if it doesn't transcode it after (i.e. archive > trees). It's the job of the exporter to decide what should or > shouldn't be exported. Anticipating filtering would be disastrous > for some exporters (i.e. the Org one) and wouldn't fit the modular > design. I am curious to see how slow it will be. If necessary, export can be pushed to a background process, but I do not think this will be necessary. > 2. The document title cannot be obtained anymore from the first line of > text. It's either explicitely defined with the =TITLE= keyword, or > derived from buffer's name. This is actually good, I think. Much of the stuff like initial text, title from text etc are leftovers from early time. It might mean that we will have to keep the old exporters around somewhere, if someone needs compatibility. > > 3. =TEXT= keywords at the beginning of the document are unneeded, and, > as such, no longer have an effect. > > 4. "[TABLE OF CONTENTS]" as a placeholder for the table of contents has > been removed. Though, a new keyword, =TOC=, achieves the same > effect, and can even take more values, like "contents", "tables", > "figures" and "listings". Tools are provided to make them available > to any exporter to come. What do you mean by "keyword"? Can you provide an example of how to place the TOC? > > 5. "-t" option at a src or example block isn't supported anymore. This > is an HTML only option that could fit in =attr_html= affiliated > keyword instead, with a "textarea" value. A new HTML back-end isn't > available yet, but should develop in that direction anyway. Yes, this is a good alternative. > > 6. Macros have been under powered a little. They cannot live anymore in > comments, example blocks, or even src blocks. In fact, one cannot > find a macro where the text isn't parsed. Macros are Org syntax. > Using such syntax where there is, by definition, none is just > nonsensical. I know that Stefan Vollmar is using macros in complicated and extensive ways. I also know that he is using the index facilities, which so far have depended heavily on the preprocessor. I am curious how indexing will work with org-elements. Have you put any thought into this? > > 7. For the same reason, invisible targets in comments have been > deprecated. For the same result, one can now use a =TARGET= keyword > instead. This is actually better... > > 8. =INCLUDE= keyword :prefix, :prefix1 and :minlevel properties support > has been dropped. Though, the keyword, which doesn't have to be at > column 0 anymore, is aware about its environment. If it belongs to > a list, the whole file will be in the current item. Also, including > a file from within a sub-tree will always make the top-level headline > of the included file is a direct child of that sub-tree. One > technical drawback is that no Babel block is executed in the included > file. Again, no loss, this was a weird feature anyway. > > 9. Table.el tables will always use their own export back-end. In other > words, no Org syntax will be recognized in such table anymore. > A table.el is an extraneous element while the parser is meant to > parse Org syntax. Now, an interesting idea from /Jambunathan K./, > namely his "list-tables", might fill the gap between the Org > spreadsheet and the table.el table. Nothing is implemented about it > right now, but we're talking about a modular and extensible parser, > after all. Maybe we should see if there is a hook in table.el which could be called to format text in a backend specific way. If it is not there, maybe we can simply introduce it ourselves, or add some advice for this purpose > > 10. Calling an export function with a numeric argument doesn't change >headline maximum level, by default. There are enough ways to change >this export property already and the argument may be required for >something more important in the future. Again, less is more. > > 11. =org-export-with-TeX-macros= has been replaced with the more >appropriate =org-export-with-entities=, and the associated =OPTIONS= >keyword's symbol changed from =TeX:nil= to =e:nil=. I do like the change, but maybe it would be good to support TeX for backward compatibility... Then, maybe, we are breaking a few things anyway. > > 12.
Re: [O] Publish HTML Without Title
Hi Nick, Thanks for you answer and your verification. > Thanks for providing your setup. I think you are right about the code > and I don't see any way to turn it off. > > It looks like another band-aid to me (and org-html definitely has more > than its fair share of those), particularly given the comment about > org-infojs: presumably, after org-infojs is fixed to look for it in > the preamble, then the header can be deleted from the "content" > div > (although anything I say about HTML should be taken with a large grain > of salt). The thing is, this is a 'new' thing, as the git blame log also suggests. Which is bothersome. But okay. > Next question: can't you get rid of the instance in your preamble at > least > temporarily? Does it have to be in the "top" div? Well, you know, I would have to redesign my website. It is possible, but I like it. . . The header on each side is something like: | Title| | Menu | | Left aligned | empty space | Right aligned | Which is rather neat IMO. It used to work. I don't know under which version of Org I wrote (probably mostly stole :) the original CSS but I am guessing 7.6. I had hoped for some command I could #+BIND to have Org behave as before, (e.g. similar to the BIND for removing \maketitle in LaTeX). Thanks for the help, Rasmus -- Sent from my Emacs
Re: [O] [PATCH] Add tikzDevice support to ob-R
Aloha Thomas,
> The attached patch adds tikzDevice support to ob-R. It requires that
> the tikzDevice package be available to R, so it must be installed and
> loaded. Something like the following code in .Rprofile will load the
> package by default:
Thanks a bunch. I always use pgfSweave and thus I haven't really
managed to move from Rnw (LaTeX + R files) to Org file.
Are you aware of the very handy pgfsweave bin? In the Arch R package it
is located in
/usr/lib/R/bin/pgfsweave
First, you don't have to load tikzDevice. Second, It makes this very
nice notation valid in Rnw files:
#+begin_src latex
\begin{figure}[tbh]
\caption{Time series $x$ and $y$}\label{fig:ts1}
<>=
plot(x.ts)
lines(y.ts)
#abline(lm(y.fil~x.fil))
@
\end{figure}
#+end_latex
which translates to the following automatically:
#+begin_src latex
\begin{figure}[tbh]
\caption{Time series $x$ and $y$}\label{fig:ts1}
\tikzsetnextfilename{class3-ts3xy-plot}
\tikzexternalfiledependsonfile{class3-ts3xy-plot}{class3-ts3xy-plot.tikz}
\input{class3-ts3xy-plot.tikz}
\end{figure}
#+end_src
It also adds nice formatting of R chucks without the need other R
packages.
Thus, using pgfSweave over regular Sweave is just wonderful. However, I
don't know whether it can integrate with Babel.
Thanks again.
–Rasmus
--
Sent from my Emacs
Re: [O] Beamer export of a subtree seems wrong.
Hi Eric, thanks for answering. > Exporting a sub-tree does not work for beamer because of how org treats > a sub-tree. Basically, when compared with an export of the full file, > all headings are promoted one level up with the top level heading taking > on the role of the "file" enclosing the talk. > > If for the whole file, you have using the structure that says that 1st > level headings are topics and second level are slides, then when > exporting a sub-tree, the 1st level heading becomes the title of the > talk and second level headings become the topics. This is not what you > expect. O.K. I got it (I guess). What a pitty, because it would be very nice to be able to split lecture notes into either individual notes per class or into a full lecture script by simply exporting the full document or a single subtree. Do you see any chance that the new way of exporting using org-elements, recently discussed will help to get this feature. At least, it seems to me it would be easier doable. Torsten
Re: [O] [ANN] Org Export in contrib
Hello,
Carsten Dominik writes:
>> 2. The document title cannot be obtained anymore from the first line of
>> text. It's either explicitely defined with the =TITLE= keyword, or
>> derived from buffer's name.
>
> This is actually good, I think. Much of the stuff like initial text,
> title from text etc are leftovers from early time. It might mean that
> we will have to keep the old exporters around somewhere, if someone
> needs compatibility.
We're not there yet. But I hope there will be no backward compatibility.
We really should remove from all export unrelated code the export
related text-properties.
>> 4. "[TABLE OF CONTENTS]" as a placeholder for the table of contents has
>> been removed. Though, a new keyword, =TOC=, achieves the same
>> effect, and can even take more values, like "contents", "tables",
>> "figures" and "listings". Tools are provided to make them available
>> to any exporter to come.
>
> What do you mean by "keyword"? Can you provide an example of how
> to place the TOC?
Just put "#+toc: headlines", "#+toc: tables", "#+toc: listings", "#+toc:
figures" anywhere in the document (at least with the LaTeX back-end).
>> 6. Macros have been under powered a little. They cannot live anymore in
>> comments, example blocks, or even src blocks. In fact, one cannot
>> find a macro where the text isn't parsed. Macros are Org syntax.
>> Using such syntax where there is, by definition, none is just
>> nonsensical.
>
> I know that Stefan Vollmar is using macros in complicated and
> extensive ways. I also know that he is using the index facilities,
> which so far have depended heavily on the preprocessor. I am curious
> how indexing will work with org-elements. Have you put any thought
> into this?
I don't think that macros will be a source of problems since comments
and example blocks were weird locations for them anyway.
In the LaTeX exporter, "#+index: something" will be transcoded into
"\index{something}". That's about it.
Should the generic export build a list of all "#+index:" values and
store it in a `:index' property (accessible through the communication
channel)?
>> 9. Table.el tables will always use their own export back-end. In other
>> words, no Org syntax will be recognized in such table anymore.
>> A table.el is an extraneous element while the parser is meant to
>> parse Org syntax.
> Maybe we should see if there is a hook in table.el which could
> be called to format text in a backend specific way. If it is not
> there, maybe we can simply introduce it ourselves, or add some
> advice for this purpose
Ok. If anyone can look at it and determine the right thing to do, I will
merge it into the exporter code.
>> 11. =org-export-with-TeX-macros= has been replaced with the more
>>appropriate =org-export-with-entities=, and the associated =OPTIONS=
>>keyword's symbol changed from =TeX:nil= to =e:nil=.
>
> I do like the change, but maybe it would be good to support TeX
> for backward compatibility... Then, maybe, we are breaking a few
> things anyway.
TeX is still supported as a "latex-fragment". In the long run, though,
I think TeX commands that are not meant for dvipng/mathjax should be
called through an export snippet (that is "@l{...}" temporary syntax).
>> 12. About variables changes, =org-export-author-info=,
>>=org-export-creator-info= and =org-export-email-info= have been
>>replaced with, respectively, =org-export-with-author=,
>>=org-export-with-creator= ad =org-export-with-email=, for the sake
>>of consistency with other opt-in variables.
>
> Are you adding defvaralias for compatibility, or are you arguing for
> a clean break here?
There is no defvaralias. Though, I don't mind adding them.
Regards,
--
Nicolas Goaziou
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Dear Eric, Apologies for my late response (too much teaching and admin in this new job :-P). Thanks a lot again for kingly adding the "eval" header argument "non-export". From what I understand in your message this would be exactly what I was looking for (allow interactive evaluation, but inhibit code block evaluation during export). I just pulled the latest org sources and tested your addition. Unfortunately, even when using this header argument value, code blocks in both Lilypond and Fomus are still executed when the buffer is exported to either PDF (via Latex) or HTML. Below is a test that I understood should not execute during export. Am I missing something? #+begin_src fomus :eval non-export :results silent :file fomus-test.ly time 1 dur 1 pitch 60; #+end_src [[file:fomus-test.pdf]] Thanks a lot again! Best wishes, Torsten On 22 Nov 2011, at 01:23, Eric Schulte wrote: > Hi Torsten, > > Torsten Anders writes: > >> Dear Sebastien and Eric, >> >> Thanks a lot for your kind replies. However, this is not yet quite what I am >> after. >> >> I want to be able to manually execute each code block, but not >> automatically whenever the whole document is rendered. So, I would >> always switch on/off "eval never". Hm... >> > > I've just pushed up a patch which adds a new option to the "eval" header > argument. Setting eval to "non-export" will now allow interactive > evaluation, but will inhibit code block evaluation during export. This > should address your need as I understand it. > >> >> I will try out the ":cache" header argument. However, again this does >> not work so well, because for the languages I am using the :file >> argument does not work very well (I have to manually change >> extensions, so I include the resulting file links by hand anyway and >> set :results to silent. >> >> So, I it sounds like few org-babel users is really running larger >> applications in their code blocks which can delay the export of the >> whole document considerably. >> > > I would not jump to that conclusion. I have used babel code blocks to > cache the results of very long running results, however between the > :cache header argument and the ability to manually disassociate > generated results from code blocks I have not had any problems > inhibiting execution during export. > > Best -- Eric > >> >> Anyway, thanks a lot for your feedback. >> >> Best wishes, >> Torsten >> >> >> >> > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/
Re: [O] Beamer export of a subtree seems wrong.
Torsten Wagner writes: > Hi Eric, > thanks for answering. > >> Exporting a sub-tree does not work for beamer because of how org treats >> a sub-tree. Basically, when compared with an export of the full file, >> all headings are promoted one level up with the top level heading taking >> on the role of the "file" enclosing the talk. >> >> If for the whole file, you have using the structure that says that 1st >> level headings are topics and second level are slides, then when >> exporting a sub-tree, the 1st level heading becomes the title of the >> talk and second level headings become the topics. This is not what you >> expect. > > O.K. I got it (I guess). What a pitty, because it would be very nice > to be able to split lecture notes into either individual notes per > class or into a full lecture script by simply exporting the full > document or a single subtree. > Do you see any chance that the new way of exporting using > org-elements, recently discussed will help to get this feature. > At least, it seems to me it would be easier doable. > > Torsten I have no idea. I'm still a long ways behind in catching up with all the org related emails I have accumulated over the past month or so. I have no idea what org-elements will or can do... I'll come back to this as soon as I know more! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.7 (release_7.7.381.g05ea.dirty)
Re: [O] LaTeX export keyword coloring
Michael Bach writes: > Can someone give me a hint on where to look for a solution? Do I miss > something obvious? Indeed I missed something obvious. Once again: More thinking, less typing. Sorry for the noise
[O] MobileOrg not listing all entries from a specific org file
Hi list, I have an org file called GTD.org, this basically has projects and next-actions. MobileOrg is showing only a couple of items from this file, although the other items are part of the agenda search filters and do have ID as well. Besides, when I check the agendas.org in MobileOrg and tap ToDo:All, the missing entries are shown, but I can't search for it nor see it when I tap into GTD.org in MobileOrg. Any ideas? Thanks, Marcelo.
Re: [O] [Orgmode] Feature request: IDs on anything
I really love this idea of ID markers. It would open so many opportunities
for semantic extensions of org-mode and not only. Using ID markers we can
make a associative array (map, dict, key-value store) out of anything.
Meaningful task planning, project management, knowledge and information
management could be made out of that. Every ID marker will effectively
become a graph vertice.
As a variant, i would propose the Clojure syntax for maps:
{"B7423F4D-2E8A-471B-8810-C40F074717E9" {:label "foo" :export-label "bar"}}
Or something like that. The nested maps are like in NoSQL DBs (ex:
CouchDB), where you have structure like {:database1 {:document1 {:key1
value1 :key2 { ... } ... } ... } ... }
However i found that curly braces are used in many occasions in org-mode:
tags mutual exclusion, column attribute summary-type, capture templates -
template expansion, tag regular expressions, #+caption: [1]{2}, macro
replacement, embedded latex, source code.
So if this syntax is unacceptable, $[] is fine too.
Re: [O] Publish HTML Without Title
Rasmus Pank Roulund wrote: > The thing is, this is a 'new' thing, as the git blame log also > suggests. Which is bothersome. But okay. > The scenario probably went something like this: a) move the title to the preamble because that's the Right Thing (TM) b) oops - org-info.js broke c) revert a) and make a note to fix it once org-info.js is fixed. Things like this happen all the time: the question is what exactly broke your web site. You could do some git archaelogy e.g. and figure out when things were working and when they broke and go through the ML and figure out why things changed the way they did etc. I suspect it's not worth your time though. > > Next question: can't you get rid of the instance in your preamble at > > least > > temporarily? Does it have to be in the "top" div? > > Well, you know, I would have to redesign my website. It is possible, > but I like it. . . > > The header on each side is something like: > > | Title| | Menu | > | Left aligned | empty space | Right aligned | > > Which is rather neat IMO. > > It used to work. I don't know under which version of Org I wrote > (probably mostly stole :) the original CSS but I am guessing 7.6. > > I had hoped for some command I could #+BIND to have Org behave as > before, (e.g. similar to the BIND for removing \maketitle in LaTeX). > You can just use your own private patch to org-html.el to get rid of the offending entry and just keep rebasing it on top of any updates. There is a section in the FAQ that describes the process. Then when things settle down and depending on *how* they settle down, you can either throw the patch away (if everything ends up working without it) or submit it for inclusion. The relevant section of the FAQ is http://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development Nick
[O] org tables to rst (reStructuredText) or Moin wiki?
I need to make a big rst or Moin wiki table (actually it's for a trac wiki, see http://trac.edgewall.org) and those tables are annoying to construct when they're large. But org mode has this wonderful table editor and I'm wondering if there's any way to export from it a rst or moin wiki table? -- -- Gary
Re: [O] Can't get column view working
Hi again, could someone please confirm about the status of column view in the present git. I can't even get examples in worg working. All I get are long empty lines Any ideas Torsten On 25 November 2011 22:42, Torsten Wagner wrote: > Hi, > > after I converted all my BibTeX stuff into a org-mode file, I thought > I can create (for the first time) a column view to see nicely title, > autors, year and bibtex-key. This would look very similar to Jabrefs > table view, which I used before. > I created the following line. > > #+COLUMNS: %25TITLE %10AUTHOR %5YEAR %10CUSTOM_ID > > However, switching into the column-view creates the column header with > the correct spacing but all headlines are empty now. Only many spaces > later in the same row I find the ... end markers. Tab still opens the > headline and q let me switch back. > Is there anything I do wrong? I tried > > #+COLUMNS: %25ITEM %10AUTHOR %5YEAR %10CUSTOM_ID > > as well as > > #+COLUMNS: %25ITEM > > without success. > > It seems the column view is not working at all for my system. I tried > the example for org-mode beamer on worg as well as the example in the > manual. I always get long blank rows. > > Any idea? > > Torsten >
Re: [O] Can't get column view working
Torsten Wagner wrote: > Hi again, > > could someone please confirm about the status of column view in the > present git. > I can't even get examples in worg working. All I get are long empty lines > Any ideas > C-c C-c on the #+COLUMNS: line? But if you open the file anew, everything should be set up correctly. In any case, it seems to be working for me: I tried --8<---cut here---start->8--- #+COLUMNS: %25TITLE %10AUTHOR %5YEAR %10CUSTOM_ID * foo ** bar :PROPERTIES: :TITLE: Catch-22 :AUTHOR: Joseph Heller :YEAR: 1967 :CUSTOM_ID: supercalifrag :END: ** baz :PROPERTIES: :TITLE: Catch-23 :AUTHOR: U.N.Known :YEAR: 2011 :CUSTOM_ID: ilisticexpi :END: --8<---cut here---end--->8--- Org-mode version 7.7 (release_7.7.597.g7fab) Did you try with emacs -q -l minimal.emacs? Maybe some customization of yours is messing it up. Nick > Torsten > > > On 25 November 2011 22:42, Torsten Wagner wrote: > > Hi, > > > > after I converted all my BibTeX stuff into a org-mode file, I thought > > I can create (for the first time) a column view to see nicely title, > > autors, year and bibtex-key. This would look very similar to Jabrefs > > table view, which I used before. > > I created the following line. > > > > #+COLUMNS: %25TITLE %10AUTHOR %5YEAR %10CUSTOM_ID > > > > However, switching into the column-view creates the column header with > > the correct spacing but all headlines are empty now. Only many spaces > > later in the same row I find the ... end markers. Tab still opens the > > headline and q let me switch back. > > Is there anything I do wrong? I tried > > > > #+COLUMNS: %25ITEM %10AUTHOR %5YEAR %10CUSTOM_ID > > > > as well as > > > > #+COLUMNS: %25ITEM > > > > without success. > > > > It seems the column view is not working at all for my system. I tried > > the example for org-mode beamer on worg as well as the example in the > > manual. I always get long blank rows. > > > > Any idea? > > > > Torsten > > >
Re: [O] [PATCH] Add tikzDevice support to ob-R
Applied, Thanks -- Eric
t...@tsdye.com (Thomas S. Dye) writes:
> Aloha all,
>
> The attached patch adds tikzDevice support to ob-R. It requires that
> the tikzDevice package be available to R, so it must be installed and
> loaded. Something like the following code in .Rprofile will load the
> package by default:
>
> old <- getOption("defaultPackages")
> options(defaultPackages = c(old, "tikzDevice"))
>
> Then, specify a .tex file in the :file header argument of the R source
> code block, e.g., :file intervals.tex, and the graphic will be produced
> by tikzDevice.
>
> The advantage of this for LaTeX export is that the resulting file will
> be set with the fonts of its surrounding document.
>
> Something like this works for me, where the \sffamily command uses the
> document's sans serif font and the file is called intervals.tex:
>
> \begin{figure}[htb!]
> \centering
> \sffamily
> \input{../figure/intervals}
> \caption[Elapsed time between Polynesian colonization of Hawai`i and
> fire-pit use]{Elapsed time between Polynesian colonization of Hawai`i
> and fire-pit use.}
> \label{fig:elapsed-time}
> \end{figure}
>
> All the best,
> Tom
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Torsten, Change "non-export" to "no-export", see the manual for valid values for the eval header argument. Best -- Eric Torsten Anders writes: > Dear Eric, > > Apologies for my late response (too much teaching and admin in this new job > :-P). Thanks a lot again for kingly adding the "eval" header > argument "non-export". From what I understand in your message this would be > exactly what I was looking for (allow interactive > evaluation, but inhibit code block evaluation during export). I just pulled > the latest org sources and tested your addition. > > Unfortunately, even when using this header argument value, code blocks in > both Lilypond and Fomus are still executed when the buffer is exported to > either PDF (via Latex) or HTML. > > Below is a test that I understood should not execute during export. Am I > missing something? > > > #+begin_src fomus :eval non-export :results silent :file fomus-test.ly > time 1 dur 1 pitch 60; > #+end_src > [[file:fomus-test.pdf]] > > Thanks a lot again! > > Best wishes, > Torsten > > > On 22 Nov 2011, at 01:23, Eric Schulte wrote: > >> Hi Torsten, >> >> Torsten Anders writes: >> >>> Dear Sebastien and Eric, >>> >>> Thanks a lot for your kind replies. However, this is not yet quite what I >>> am after. >>> >>> I want to be able to manually execute each code block, but not >>> automatically whenever the whole document is rendered. So, I would >>> always switch on/off "eval never". Hm... >>> >> >> I've just pushed up a patch which adds a new option to the "eval" header >> argument. Setting eval to "non-export" will now allow interactive >> evaluation, but will inhibit code block evaluation during export. This >> should address your need as I understand it. >> >>> >>> I will try out the ":cache" header argument. However, again this does >>> not work so well, because for the languages I am using the :file >>> argument does not work very well (I have to manually change >>> extensions, so I include the resulting file links by hand anyway and >>> set :results to silent. >>> >>> So, I it sounds like few org-babel users is really running larger >>> applications in their code blocks which can delay the export of the >>> whole document considerably. >>> >> >> I would not jump to that conclusion. I have used babel code blocks to >> cache the results of very long running results, however between the >> :cache header argument and the ability to manually disassociate >> generated results from code blocks I have not had any problems >> inhibiting execution during export. >> >> Best -- Eric >> >>> >>> Anyway, thanks a lot for your feedback. >>> >>> Best wishes, >>> Torsten >>> >>> >>> >>> >> >> -- >> Eric Schulte >> http://cs.unm.edu/~eschulte/ > -- Eric Schulte http://cs.unm.edu/~eschulte/
