[O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
On 02/07/14, 07:18 , John Hendy wrote:
Greetings,
I don't usually tangle, but am creating a code file to go along with a
presentation I'm giving this weekend so that attendees can try things
out afterward by cloning my github repo where all the data and
necessary files are stored.
In my presentation (Beamer), I create plots via the R pdf() device,
and noticed that all of the tangled code where plots are generated
contains the following:
pdf(file=file.pdf); tryCatch({
code block contents here
},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
paste('ERROR', e$message, sep=' : ')}); dev.off()
Is there a way to omit this?
This is a bug which must have been introduced some time ago - in the
stock version of emacs (Org-mode version 7.9.3f
(release_7.9.3f-17-g7524ef @
/usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
tangle the enclosing commands to create graphics, but in 8.2 it does (I
don't have an older version at hand to go further back).
I'm guessing this is here to create a blank plot with the error as the
output when something goes awry?
Yes.
I checked around variable completions of org-babel-tangle-* and
searched google for terms like org babel tangle try catch but am not
finding anything that looks like what I need.
There is nothing, as it should not be tangled. The enclosing commands
concern the export, but not tangling,
I agree that the :result graphics header argument caused commands should
not be in the tangled file.
Another question is about the :epilogue and :prologue which I think
should be present (haven't checked if they are...).
Cheers,
Rainer
Thanks,
John
--
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
signature.asc
Description: OpenPGP digital signature
Re: [O] Feature request: filling of long captions
Hello, Eric Schulte schulte.e...@gmail.com writes: For a while now I've been wishing that keywords (namely #+Caption:) could be equivalently specified as blocks (e.g., #+begin/end_Caption:). Would that be another possible solution here? That would defeat the purpose of the distinction between a block and an affiliated keyword (i.e., a property added to that block). Besides the change of paradigm, it would introduce a lot of problems (handle syntax limitation in such block, for example, since I assume plain lists would be forbidden). Also, current syntax also handles short captions, so you would have to rely on another trick for them. I'm sure this idea wouldn't be a net benefit for Org syntax clarity, even for the occasional three lines caption need. Regards, -- Nicolas Goaziou
Re: [O] Feature request: filling of long captions
Hi all, Nicolas Goaziou n.goaz...@gmail.com writes: I'm sure this idea wouldn't be a net benefit for Org syntax clarity, even for the occasional three lines caption need. I agree. Nicolas, what do you think of enhancing the auto-filling (and delete-indentation) capabilities for some affiliated keywords? #+CAPTION: #+HEADER: #+TBLFM: The last two would require special auto-filling functions, but at least for #+TBLFM I see the point of enabling this. Thanks, -- Bastien
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Hello, Bastien b...@gnu.org writes: I see that turning a commented line is prevented, while turning several commented lines is allowed. This feels weird. I don't think we should prevent this. What do you think? I don't think there's much point in comparing function's behaviours when acting on a single line or on a region: they are very different. For example, you can break the structure of an example block in the latter case, but not in the former. Anyway, in this particular case, I guess we could consider comments as a stack of one line elements. I added the feature. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Nicolas Goaziou n.goaz...@gmail.com writes: Anyway, in this particular case, I guess we could consider comments as a stack of one line elements. I added the feature. Thanks! -- Bastien
Re: [O] Feature request: filling of long captions
Hello, Nicolas, what do you think of enhancing the auto-filling (and delete-indentation) capabilities for some affiliated keywords? #+CAPTION: #+HEADER: #+TBLFM: Not that it matters much, but TBLFM is not an affiliated keyword per se, it belongs to the table syntax. OTOH, you can have CAPTION and HEADER keywords on top of almost any element type. Anyway, the three keywords are very different. To start with the one I know the most, CAPTION can have an optional value, and multiple caption lines can have as many optional values. #+CAPTION[short caption]: long caption #+CAPTION[short caption, continued]: long caption, continued. Therefore, filling it can be tricky since you have to pay attention to both values. Moreover, if the short caption is too long to fit on one line, that line still needs to end with ]: to be valid. #+CAPTION[very very ... long short caption]: #+CAPTION[continued even here]: long caption #+CAPTION: long caption continued. The difficulty lies elsewhere for HEADER and TBLFM. The question is: can we split a HEADER or TBLFM line anywhere, e.g., in the between a keyword and its value (or at a space in the middle of a value) for the former, and in the middle of a formula in the latter? It depends on how org-table.el and ob.el read these keywords. I didn't check. Also, please bear in mind that filling functions have unit tests, so any new feature ought to be also tested. Regards, -- Nicolas Goaziou
Re: [O] Feature request: filling of long captions
Hello, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Nicolas, what do you think of enhancing the auto-filling (and delete-indentation) capabilities for some affiliated keywords? #+CAPTION: #+HEADER: #+TBLFM: Not that it matters much, but TBLFM is not an affiliated keyword per se, it belongs to the table syntax. OTOH, you can have CAPTION and HEADER keywords on top of almost any element type. Anyway, the three keywords are very different. To start with the one I know the most, CAPTION can have an optional value, and multiple caption lines can have as many optional values. #+CAPTION[short caption]: long caption #+CAPTION[short caption, continued]: long caption, continued. Therefore, filling it can be tricky since you have to pay attention to both values. Moreover, if the short caption is too long to fit on one line, that line still needs to end with ]: to be valid. #+CAPTION[very very ... long short caption]: #+CAPTION[continued even here]: long caption #+CAPTION: long caption continued. This is something, that I had not thought about when I expressed my wish. I did not even know, that consecutive #+CAPTION lines could also have consecutive short captions. I see the difficulty here. Usually, my votes are in favour of backwards compatibility. So, I am not too sure about this suggestion myself: But here an obvious 'solution' would be to move the short caption to #+SHORT_CAPTION. I see that such change would bring its own difficulties besides breaking the backwards compatibility. Like what to do when there is a short caption but no 'long' caption. I am just continuing this discussion, as I do not have 'the occasional three lines caption need' but the 'always multi-lines caption need'. In my opinion, images in an article/paper/thesis/... should tell their story independently of the text referring to them. So, my captions tend to be (too?) long. So, I would benefit a lot from whatever filling mechanism might get implemented. [...] Regards, Andreas
Re: [O] Feature request: filling of long captions
Andreas Leha andreas.l...@med.uni-goettingen.de writes: But here an obvious 'solution' would be to move the short caption to #+SHORT_CAPTION. Yes. #+CAPTION[...]: is clumsy. -- Bastien
Re: [O] Feature request: filling of long captions
Bastien b...@gnu.org writes: Yes. #+CAPTION[...]: is clumsy. It follows #+RESULTS[...]: model. -- Nicolas Goaziou
[O] [RFC] Proposal for rebindings in Org 8.3
The purpose is to be polite with minor modes and to not use C-c [:punct:] keybindings, as recommended in the Elisp manual. This is related to the issues reported here: http://lists.gnu.org/archive/html/emacs-orgmode/2014-01/msg00866.html http://article.gmane.org/gmane.emacs.orgmode/82010 Here is a table to summarise the proposal: | Key | Command | Proposal | Status | |---+---+--+| | C-c # | Checkboxes| C-c x| Free | | C-c ~ | Cooperation | C-c C-~ | Free | | C-c , | Priorities| C-c C-, | Free | | C-c ? | Editing and debugging formulas| C-c C-? | Free | | C-c ! | Creating timestamps | C-c C-! | Free | | C-c . | Creating timestamps | C-c C-. | Free | | C-c ` | Built-in table editor | C-c C-` | Free | |---+---+--+| | C-c ' | Editing and debugging formulas| C-c or C-c C-' | Free | | C-c ^ | Structure editing, plain lists... | C-c C-^ | Taken | | C-c @ | Structure editing | C-c | Taken | The order is from the less problematic ones to the more problematic ones. A few comments on the last three: - is not a punctuation character, I find C-c instead of C-c ' good. - C-c C-^ is taken by org-up-element. I'm in favor of using C-c C-u (currently bound to `outline-up-heading') for `org-up-element'. Nicolas suggested C-M-u but I find it convenient to have it when editing Elisp code within Org buffers. - C-c is bound to `org-date-from-calendar', which inserts the current date (or the date from the calendar buffer) at point as an active timestamp. C-c is bound to `org-goto-calendar' and goes to the calendar, going to the date at point if any. This is just a slightly more contextual M-x calendar RET. So the whole suggestion here is: - in Org-mode, remap calendar to org-goto-calendar and unbind it from C-c - use C-c for `org-date-from-calendar' - use C-c for selecting the whole subtree, which is consistent with the use of `' as a speedy command for doing the same. Let me know how you feel about such move in general and each rebinding in particular. We are not forced to solve them all at once. Thanks, -- Bastien
Re: [O] [RFC] Move ox-koma-letter into core?
Hi, Nicolas Goaziou n.goaz...@gmail.com writes: Why this suggestion? To get Emacs core maintainers opinions on this and clarify if we can expand Org features at will or if they want to be control that somehow. We recently introduced ob-coq.el in core without asking Emacs maintainers beforehand. That's different: supporting as many programming languages is a core feature of Babel, while supporting as many export target as possible should not be a core feature of Emacs IMO, it should stay as a nice facility of the Org ecosystem. The second part of the paragraph above (while...) is where I'd be interested to hear about what Emacs core maintainers think. If you're fine with this, I'll raise the topic on both emacs-devel and this list. -- Bastien
Re: [O] intra links and worg
Bastien b...@gnu.org writes: Hi Alan, Alan Schmitt alan.schm...@polytechnique.org writes: I tried it and it does not change anything on worg. The purpose of the patch is so that C-c C-l on a headline will then insert a link without escaping whitespaces: * Headline with whitespaces [[*Headline with whitespaces][Headline with whitespaces]] Whereas now it does this: * Headline with whitespaces [[*Headline%20with%20whitespaces][Headline with whitespaces]] So if Worg pages contain escaped sequences, they will be exported with italics. Ah, thanks, I see now. It does work indeed. Alan
Re: [O] [RFC] Move ox-koma-letter into core?
Hello, Bastien b...@altern.org writes: My suggestion is to ask Emacs maintainers Why this suggestion? We recently introduced ob-coq.el in core without asking Emacs maintainers beforehand. Regards, -- Nicolas Goaziou
[O] org-edit-src-code window setup
Dear org-mode Developers and Users,
(Org-mode version 8.2.5g from git)
I want to change the behaviour of C-c ' when inside a source block.
What I am after is best described in a schematic:
+---+---+
| | |
| | 2 |
| | |
| | |
+ 1 +---+
| | |
| | 3 |
| | |
| | |
+---+---+
I am editing the .org file in window 1 ('org'). I want C-c ' to display
the code block contents in window 2 ('source'). In window 3 I want to
have the interpreter for the language I am editing ('interpreter').
I read up on the internal documentation:
`org-edit-special' `org-edit-src-code' `org-src-window-setup'
other-window (`switch-to-buffer-other-window')
Now, when I do C-c ' multiple times, the source buffer changes from 2 to
3 and back again and so on - effectively switching the 'source' and
'interpreter' window contents on each C-c '.
After reading the documentation for `switch-to-buffer-other-window', I
wanted to check out the NORECORD option that has the description:
Optional second argument NORECORD non-nil means do not put this
buffer at the front of the list of recently selected ones.
Now is there a way to control this option that I miss? Would it have
any effect? How would you handle this situation?
Best Regards,
Michael Bach
Re: [O] [RFC] Proposal for rebindings in Org 8.3
Bastien wrote: The purpose is to be polite with minor modes and to not use C-c [:punct:] keybindings, as recommended in the Elisp manual. This is related to the issues reported here: http://lists.gnu.org/archive/html/emacs-orgmode/2014-01/msg00866.html http://article.gmane.org/gmane.emacs.orgmode/82010 Here is a table to summarise the proposal: | Key | Command | Proposal | Status | |---+---+--+| | C-c # | Checkboxes| C-c x| Free | | C-c ~ | Cooperation | C-c C-~ | Free | | C-c , | Priorities| C-c C-, | Free | | C-c ? | Editing and debugging formulas| C-c C-? | Free | | C-c ! | Creating timestamps | C-c C-! | Free | | C-c . | Creating timestamps | C-c C-. | Free | | C-c ` | Built-in table editor | C-c C-` | Free | |---+---+--+| | C-c ' | Editing and debugging formulas| C-c or C-c C-' | Free | | C-c ^ | Structure editing, plain lists... | C-c C-^ | Taken | | C-c @ | Structure editing | C-c | Taken | The order is from the less problematic ones to the more problematic ones. A few comments on the last three: - is not a punctuation character, I find C-c instead of C-c ' good. - C-c C-^ is taken by org-up-element. I'm in favor of using C-c C-u (currently bound to `outline-up-heading') for `org-up-element'. Nicolas suggested C-M-u but I find it convenient to have it when editing Elisp code within Org buffers. - C-c is bound to `org-date-from-calendar', which inserts the current date (or the date from the calendar buffer) at point as an active timestamp. C-c is bound to `org-goto-calendar' and goes to the calendar, going to the date at point if any. This is just a slightly more contextual M-x calendar RET. So the whole suggestion here is: - in Org-mode, remap calendar to org-goto-calendar and unbind it from C-c - use C-c for `org-date-from-calendar' - use C-c for selecting the whole subtree, which is consistent with the use of `' as a speedy command for doing the same. You put the finger on one important note to me: that speed commands are the same as their longer counterpart. It should be good if all of them could be obtainable by adding C-c C- in front of the speed command. With that focus in mind, I find `C-c x' not a good one (for checkboxes); though, in that case, speed commands don't come into play. But I find it too different from the `C-c C-' construct used for the others? Let me know how you feel about such move in general and each rebinding in particular. We are not forced to solve them all at once. Globally, it's fine! Last remark about `C-c ' which I find not good: - `' in used for filtering categories in the agenda, - semantically, what `C-c @' does is a `C-x h' limited to a subtree; maybe there could be something inspiring similar to `C-x h'? Maybe `C-u C-x h'? Best regards, Seb -- Sebastien Vauban
Re: [O] Feature request: filling of long captions
Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Yes. #+CAPTION[...]: is clumsy. It follows #+RESULTS[...]: model. Which I feel clumsy too :) No offense to either Eric or you. The important difference is that #+RESULTS[...] is generated, while #+CAPTION[...] is manually entered. As a user, I'm more tolerant to generated clumsy syntax than to the one I need to *learn*. Anyway, that's kinda bikeshed for now. -- Bastien
Re: [O] [RFC] Proposal for rebindings in Org 8.3
Thanks for your feedback. Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: - use C-c for selecting the whole subtree, which is consistent with the use of `' as a speedy command for doing the same. You put the finger on one important note to me: that speed commands are the same as their longer counterpart. It should be good if all of them could be obtainable by adding C-c C- in front of the speed command. I think it goes in the opposite direction: if a command is bound to C-c KEY or C-c C-KEY then KEY should be used as a speed command. With that focus in mind, I find `C-c x' not a good one (for checkboxes); though, in that case, speed commands don't come into play. The mnemonic here is: `x' reminds me of [x] -- let's see if something better can be done. But I find it too different from the `C-c C-' construct used for the others? I wanted to keep it close to C-c #, and use only C-c KEY. Let me know how you feel about such move in general and each rebinding in particular. We are not forced to solve them all at once. Globally, it's fine! Last remark about `C-c ' which I find not good: - `' in used for filtering categories in the agenda, Categories are (most often) attached to a subtree. When you hit the `' speed command on this subtree then display the agenda, you don't need to filter by category with `' since the narrowing already filters (by category) for you. That's actually one of the reason for which I propose this key. - semantically, what `C-c @' does is a `C-x h' limited to a subtree; maybe there could be something inspiring similar to `C-x h'? Maybe `C-u C-x h'? The way to get the same behavior than `C-c @' is `C-c C-^ M-h'. M-h is very very handy, and probably not known enough! -- Bastien
[O] Wanted: volunteer to integrate REST-client (restclient.el)
Hi! I am not an ELISP programmer (unfortunately) but a proud heavy-user of Org-mode. At work, I need a REST-client to talk to a REST API very often. Recently, I found [1] which works quite well. However, I need to open a new buffer into restclient-mode to execute requests. Wouldn't it be nice if Org-mode could integrate this tool so that, e.g., following example could be invoked via babel? #+BEGIN_SRC REST GET http://myserver/rest/dothis Authorization: Basic YmVfcmVzdF9hZG1 Accept-Encoding: application/xml #+END_SRC #+RESULTS: : ?xml version=1.0 encoding=UTF-8 standalone=yes? : faultInfo xmlns=http://example.com/product/model; : ... : /faultInfo I also proposed this as a request on [2] but the author is not using Org-mode on a regular basis. So: is there any volunteer who wants to complete Org-mode's featureset even more? Thanks! 1. https://github.com/pashky/restclient.el 2. https://github.com/pashky/restclient.el/issues/21 -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: get Memacs from https://github.com/novoid/Memacs https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] [RFC] Proposal for rebindings in Org 8.3
Hi Bastien On Fri, Feb 7, 2014 at 11:32 AM, Bastien b...@gnu.org wrote: | C-c # | Checkboxes| C-c x| Free | I did not know C-c # (org-update-statistics-cookies) because for me it is easier to remember and therefore I always used this: Go to cookie and do C-c C-c. And C-c x does not comply with the Elisp manual: Don't define C-c letter as a key in Lisp programs. Sequences consisting of C-c and a letter (either upper or lower case) are reserved for users; they are the only sequences reserved for users, so do not block them. Changing all the Emacs major modes to respect this convention was a lot of work; abandoning this convention would make that work go to waste, and inconvenience users. Please comply with it. With these two reasons my suggestion is to just drop the binding for (org-update-statistics-cookies). Michael
[O] adding options to the minted environment of exported source blocks in latex
Hello, I use and abuse the `org-latex-minted-options' when exporting source blocks in latex, but I'm stumped by a usage pattern. I need to change the list of options for one given source block (adding a belowskip option to it). I tried the following, but it did not do anything: --8---cut here---start-8--- #+attr_latex: :belowskip 1cm #+BEGIN_SRC ocaml #load graphics.cma;; Graphics.open_graph ;; #+END_SRC --8---cut here---end---8--- I guess that I can only put some specific options for attr_latex. Is there a way to put arbitrary options in the exported minted environment? Thanks a lot, Alan
[O] Export to UTF8: tiny detail
Hello, Exporting this: --8---cut here---start-8--- - I don't see the same prices as in the tutorial: in fact, the prices of =Simulation_1= and =Simulation_3= are inverted! --8---cut here---end---8--- gives that: --8---cut here---start-8--- • I don’t see the same prices as in the tutorial: in fact, the prices of `Simulation_1' and `Simulation_3' are inverted! --8---cut here---end---8--- (see the extra spaces added at the beginning of the 2^nd line) Overall, I like a lot that export for sending emails. It's just fantastically displayed, with very nice underlines for headings, etc. Thanks! Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Proposal for rebindings in Org 8.3
Bastien b...@gnu.org writes: The purpose is to be polite with minor modes and to not use C-c [:punct:] keybindings, as recommended in the Elisp manual. This is related to the issues reported here: http://lists.gnu.org/archive/html/emacs-orgmode/2014-01/msg00866.html http://article.gmane.org/gmane.emacs.orgmode/82010 Here is a table to summarise the proposal: | Key | Command | Proposal | Status | |---+---+--+| | C-c # | Checkboxes| C-c x| Free | | C-c ~ | Cooperation | C-c C-~ | Free | | C-c , | Priorities| C-c C-, | Free | | C-c ? | Editing and debugging formulas| C-c C-? | Free | | C-c ! | Creating timestamps | C-c C-! | Free | | C-c . | Creating timestamps | C-c C-. | Free | | C-c ` | Built-in table editor | C-c C-` | Free | |---+---+--+| | C-c ' | Editing and debugging formulas| C-c or C-c C-' | Free | | C-c ^ | Structure editing, plain lists... | C-c C-^ | Taken | | C-c @ | Structure editing | C-c | Taken | The order is from the less problematic ones to the more problematic ones. A few comments on the last three: - is not a punctuation character, I find C-c instead of C-c ' good. On a QWERTY keyboard or Dvorak keyboard, requires Shifting, so you have to switch horses midstream (first Control, then SHift). Not sure about anybody else, but those are the most problematic key sequences for me. I would much prefer C-c C-': you just keep the Control key pressed for the duration. - C-c C-^ is taken by org-up-element. I'm in favor of using C-c C-u (currently bound to `outline-up-heading') for `org-up-element'. Nicolas suggested C-M-u but I find it convenient to have it when editing Elisp code within Org buffers. - C-c is bound to `org-date-from-calendar', which inserts the current date (or the date from the calendar buffer) at point as an active timestamp. C-c is bound to `org-goto-calendar' and goes to the calendar, going to the date at point if any. This is just a slightly more contextual M-x calendar RET. So the whole suggestion here is: - in Org-mode, remap calendar to org-goto-calendar and unbind it from C-c - use C-c for `org-date-from-calendar' - use C-c for selecting the whole subtree, which is consistent with the use of `' as a speedy command for doing the same. Let me know how you feel about such move in general and each rebinding in particular. We are not forced to solve them all at once. Thanks, -- Nick
Re: [O] [RFC] Proposal for rebindings in Org 8.3
Nick Dokos ndo...@gmail.com writes: Bastien b...@gnu.org writes: The purpose is to be polite with minor modes and to not use C-c [:punct:] keybindings, as recommended in the Elisp manual. This is related to the issues reported here: http://lists.gnu.org/archive/html/emacs-orgmode/2014-01/msg00866.html http://article.gmane.org/gmane.emacs.orgmode/82010 Here is a table to summarise the proposal: | Key | Command | Proposal | Status | |---+---+--+| | C-c # | Checkboxes| C-c x| Free | | C-c ~ | Cooperation | C-c C-~ | Free | | C-c , | Priorities| C-c C-, | Free | | C-c ? | Editing and debugging formulas| C-c C-? | Free | | C-c ! | Creating timestamps | C-c C-! | Free | | C-c . | Creating timestamps | C-c C-. | Free | | C-c ` | Built-in table editor | C-c C-` | Free | |---+---+--+| | C-c ' | Editing and debugging formulas| C-c or C-c C-' | Free | | C-c ^ | Structure editing, plain lists... | C-c C-^ | Taken | | C-c @ | Structure editing | C-c | Taken | The order is from the less problematic ones to the more problematic ones. A few comments on the last three: - is not a punctuation character, I find C-c instead of C-c ' good. On a QWERTY keyboard or Dvorak keyboard, requires Shifting, so you have to switch horses midstream (first Control, then SHift). Not sure about anybody else, but those are the most problematic key sequences for me. I would much prefer C-c C-': you just keep the Control key pressed for the duration. I agree that it's better if we can avoid letters needing a 'secondary' key. Unfortunately, I think this wish is hard to meet when considering several layouts. For me the following keys need shift or Alt-Gr: ^, , `, !, ?, and ~. Rasmus -- If you can mix business and politics wonderful things can happen!
Re: [O] Agenda views skip function hide parent projects
On Wed, Feb 5, 2014 at 12:54 PM, Wiskey 5 Alpha wiskey5al...@gmail.com wrote: I have some projects that are 4 levels deep, so this is quite annoying. How do I get just the deepest level project to show without it's parents ? here is my custom agenda view for projects (p @Projects tags-todo -IGNORE-someday-wait/TODO ( (org-agenda-overriding-header @Projects) (org-agenda-tags-todo-honor-ignore-options t) (org-agenda-skip-function (lambda nil (org-agenda-skip-subtree-if (quote notregexp) \\* NEXT) ) ) I think I understand the problem now, but i do not know how to fix it. The skip function matches on the parent, as well as the siblings if there is a NEXT item in the subtree. Is there any way to limit the search to only one level below the current level ? -Tim
Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
Rainer M Krug rai...@krugs.de writes:
On 02/07/14, 07:18 , John Hendy wrote:
Greetings,
I don't usually tangle, but am creating a code file to go along with a
presentation I'm giving this weekend so that attendees can try things
out afterward by cloning my github repo where all the data and
necessary files are stored.
In my presentation (Beamer), I create plots via the R pdf() device,
and noticed that all of the tangled code where plots are generated
contains the following:
pdf(file=file.pdf); tryCatch({
code block contents here
},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
paste('ERROR', e$message, sep=' : ')}); dev.off()
Is there a way to omit this?
This is a bug which must have been introduced some time ago - in the
stock version of emacs (Org-mode version 7.9.3f
(release_7.9.3f-17-g7524ef @
/usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
tangle the enclosing commands to create graphics, but in 8.2 it does (I
don't have an older version at hand to go further back).
I believe this was introduced by your commit eaa3a761d. Reversion of
which with the following should provide a temporary workaround.
git revert eaa3a761d
Perhaps the try/catch code should be moved from org-babel-expand-body:R
to org-babel-execute:R. Alternately, the code should stay as is and you
should use the no-expand header argument during tangling.
I'm not sure which makes the most sense, but I'd lean towards the
former.
Best,
I'm guessing this is here to create a blank plot with the error as the
output when something goes awry?
Yes.
I checked around variable completions of org-babel-tangle-* and
searched google for terms like org babel tangle try catch but am not
finding anything that looks like what I need.
There is nothing, as it should not be tangled. The enclosing commands
concern the export, but not tangling,
I agree that the :result graphics header argument caused commands should
not be in the tangled file.
Another question is about the :epilogue and :prologue which I think
should be present (haven't checked if they are...).
Cheers,
Rainer
Thanks,
John
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Re: [O] [RFC] Move ox-koma-letter into core?
Bastien b...@gnu.org writes: To get Emacs core maintainers opinions on this and clarify if we can expand Org features at will or if they want to be control that somehow. AFAICT, we never asked Emacs maintainers before adding a feature to Org, and I don't think the number of export targets in core grew exponentially lately. Also, I don't see why Emacs maintainers would want to limit features provided in an Emacs library, as long as it doesn't impedes GNU goals and copyright issues are sorted out (which is not yet the case of the file we're talking about). That's different: supporting as many programming languages is a core feature of Babel, while supporting as many export target as possible should not be a core feature of Emacs IMO, it should stay as a nice facility of the Org ecosystem. The second part of the paragraph above (while...) is where I'd be interested to hear about what Emacs core maintainers think. Sorry, I cannot understand this argument, since the target is a tex file, and we already export to tex files. If you're fine with this, I'll raise the topic on both emacs-devel and this list. I suggested this idea because I thought it was a good one. The very fact that we're still discussing it proves that it isn't as obvious as I initially thought. That's fine with me. I will not insist anymore on this topic. Regards, -- Nicolas Goaziou
[O] another blog exporter
Hi, around the org-mode 8.0 release I began to write a new blog exporter using the new export framework. I wanted one feature org2blog didn't offer, support for different syntax highlighters, and i wanted to learn about the new exporter and Emacs programming. Around Christmas I did some polishing to make it ready for a greater public. Would there a place for it in contrib/ or is it better suited for a github repository? Thanks and best regards Robert ;;; ox-blog.el --- Blog Back-End for Org Export Engine ;; Copyright (C) 2013, 2014 Robert Klein ;; Author: Robert Klein roklein at roklein dot de ;; Keywords: WordPress, HTML ;; This file is not part of GNU Emacs. ;; This program is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version. ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with this program. If not, see http://www.gnu.org/licenses/. ;;; Commentary: ;; This library implements an blog back-end for the Org ;; generic exporter. ;; To test it, run: ;; ;; M-x org-blog-export-as-html ;; ;; in an Org mode buffer. See ox.el and ox-html.el for more details ;; on how this exporter works. ;;; Code: (require 'ox-html) ;; in turn requires ox-publish and ox. (require 'xml-rpc) ; (require 'wp-xml-rpc) ; (require 'cl) (org-export-define-derived-backend 'blog 'html :menu-entry '(?b Export to WP Blog Presentation ((?H To temporary buffer org-blog-export-as-html) (?h To file org-blog-export-to-html) (?d To blog as draft org-blog-export-to-blog-as-draft) (?p To blog and publish org-blog-export-to-blog-as-publish) (?o To file and open (lambda (a s v b) (if a (org-blog-export-to-html t s v b) (org-open-file (org-blog-export-to-html nil s v b))) :options-alist '((:blog-url BLOG_URL nil nil t) (:blog-username BLOG_USERNAME nil nil t) (:blog-id BLOG_ID nil nil t) (:blog-password BLOG_PASSWORD nil nil t) (:blog-post-id BLOG_POST_ID nil nil t) (:blog-publish-datetime BLOG_PUBLISH_DATETIME nil nil t) (:blog-post-type BLOG_POST_TYPE post-type org-blog-post-type t) (:blog-syntax-highlighter BLOG_SYNTAX_HIGHLIGHTER bloghl org-blog-syntax-highlighter t) (:blog-timezone BLOG_TIMEZONE blogtz nil t) (:blog-tags BLOG_TAGS nil org-blog-tags newline) (:blog-confirm-new-tags BLOG_CONFIRM_NEW_TAGS nil org-blog-confirm-new-tags t) (:blog-categories BLOG_CATEGORIES nil org-blog-categories newline) (:blog-confirm-new-categories BLOG_CONFIRM_NEW_CATEGORIES nil org-blog-confirm-new-categories t) (:blog-use-tags-as-categories BLOG_USE_TAGS_AS_CATEGORIES nil nil t) (:blog-upload-filetypes BLOG_UPLOAD_FILETYPES nil org-blog-upload-filetypes split)) :translate-alist '(;(inner-template . org-blog-inner-template) ;; use org-html-inner-template (example-block . org-blog-example-block) (keyword . org-blog-keyword) (latex-environment . org-blog-latex-environment) (latex-fragment . org-blog-latex-fragment) (link . org-blog-link) (src-block . org-blog-src-block) (template . org-blog-template))) ;;; Internal variables ;(defvar org-blog-id 1 ; ID of blog. Typically 1.) (defvar org-blog-files-to-upload nil A list containing the file names to upload to the blog.) (defvar org-blog-image-list nil Images to upload/change URL in buffer.) ;;; User Configuration Variables (defgroup org-export-blog nil Options for exporting Org mode files to a wordpress based blog. :tag Org Export Blog :group 'org-export) (defcustom org-blog-project-alist nil Association list to control blog publication behavior. Eash element of the alist is a blog 'project.' The CAR of each element is a string, uniquely identifying the project. The CDR of each element is in the following form: 1. A well-formed property list with an even number of elements, alternating keys and values, specifying parameters for the publishing process. When a property is given a value in `org-blog-project-alist', its setting overrides the value of the corresponding user variable (if any) during publishing. However, options set within a file override everything. Most properties are optional, but some should always be set: `:base-directory' Directory containing publishing source files. `:blog-url' Blog where posts will be published. `:blog-id' Blog ID; usually `1'. Some properties control details of the Org publishing process, and are equivalent to the
Re: [O] org-edit-src-code window setup
On Fri, Feb 7, 2014 at 5:29 AM, Michael Bach pha...@gmail.com wrote:
Dear org-mode Developers and Users,
(Org-mode version 8.2.5g from git)
I want to change the behaviour of C-c ' when inside a source block.
What I am after is best described in a schematic:
+---+---+
| | |
| | 2 |
| | |
| | |
+ 1 +---+
| | |
| | 3 |
| | |
| | |
+---+---+
I am editing the .org file in window 1 ('org'). I want C-c ' to display
the code block contents in window 2 ('source'). In window 3 I want to
have the interpreter for the language I am editing ('interpreter').
Can you clarify whether you simply want to obtain this view in Emacs
and are not sure how, or if you are asking for a way to automate the
process via a keyboard binding/macros/function in order to do this
automatically on every use of =C-c '=?
[snip]
Best Regards,
Michael Bach
Re: [O] [RFC] Move ox-koma-letter into core?
Nicolas Goaziou n.goaz...@gmail.com writes: That's different: supporting as many programming languages is a core feature of Babel, while supporting as many export target as possible should not be a core feature of Emacs IMO, it should stay as a nice facility of the Org ecosystem. The second part of the paragraph above (while...) is where I'd be interested to hear about what Emacs core maintainers think. Sorry, I cannot understand this argument, since the target is a tex file, and we already export to tex files. Did we ask about ox-beamer? If we support the creation of slides why not letters? Both are representations of LaTeX and extensions of ox-latex.el. If you're fine with this, I'll raise the topic on both emacs-devel and this list. I suggested this idea because I thought it was a good one. The very fact that we're still discussing it proves that it isn't as obvious as I initially thought. That's fine with me. Based on google search, the Worg page for the exporter has some attention. https://startpage.com/do/search?query=koma-script+letter My — biased — opinion is that ox-koma-letter provides a nice way of typesetting and structuring letters (compared to the raw tex format), e.g. here: http://orgmode.org/worg/exporters/koma-letter-export.html#sec-1-3 http://orgmode.org/w/?p=worg.git;a=blob_plain;f=images/ox-koma-letter/koma-letter-new-example.pdf —Rasmus -- Summon the Mothership!
Re: [O] another blog exporter
Robert Klein rokl...@roklein.de writes: Hi, around the org-mode 8.0 release I began to write a new blog exporter using the new export framework. I wanted one feature org2blog didn't offer, support for different syntax highlighters, and i wanted to learn about the new exporter and Emacs programming. Around Christmas I did some polishing to make it ready for a greater public. Cool. Could you provide an example blog so that we can see the output? ;;; Transcode Functions Example Block (defun org-blog-example-block (example-block contents info) Transcode a EXAMPLE-BLOCK element from Org to HTML. CONTENTS is nil. INFO is a plist holding contextual information. (if (org-export-read-attribute :attr_html example-block :textarea) (org-html--textarea-block example-block) ;;; beginnin here we need org/wp-syntac/syntaxhl information (format pre class=\example\\n%s/pre (org-html-format-code example-block info Isn't this an exact copy of the corresponding entry in ox-html (Less the name)? Why? Latex Environment (defun org-blog-latex-environment (latex-environment contents info) Transcode a LATEX-ENVIRONMENT element from Org to HTML. CONTENTS is nil. INFO is a plist holding contextual information. (let ((processing-type (plist-get info :with-latex)) (latex-frag (org-remove-indentation (org-element-property :value latex-environment))) (attributes (org-combine-plists (org-export-read-attribute :attr_html latex-environment) (org-export-read-attribute :attr_blog latex-environment (case processing-type ((t mathjax) (org-html-format-latex latex-frag 'mathjax info)) ((dvipng imagemagick) (let ((formula-link (org-html-format-latex latex-frag processing-type info))) (when (and formula-link (string-match file:\\([^]]*\\) formula-link)) ;; Do not provide a caption or a name to be consistent with ;; `mathjax' handling. (org-html--wrap-image (org-blog--format-image (match-string 1 formula-link) attributes info) info (t latex-frag Same. There seems to be a couple of these. . . Rasmus -- Don't panic!!!
Re: [O] [RFC] Move ox-koma-letter into core?
Aloha all, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: To get Emacs core maintainers opinions on this and clarify if we can expand Org features at will or if they want to be control that somehow. AFAICT, we never asked Emacs maintainers before adding a feature to Org, and I don't think the number of export targets in core grew exponentially lately. Also, I don't see why Emacs maintainers would want to limit features provided in an Emacs library, as long as it doesn't impedes GNU goals and copyright issues are sorted out (which is not yet the case of the file we're talking about). That's different: supporting as many programming languages is a core feature of Babel, while supporting as many export target as possible should not be a core feature of Emacs IMO, it should stay as a nice facility of the Org ecosystem. The second part of the paragraph above (while...) is where I'd be interested to hear about what Emacs core maintainers think. Sorry, I cannot understand this argument, since the target is a tex file, and we already export to tex files. If you're fine with this, I'll raise the topic on both emacs-devel and this list. I suggested this idea because I thought it was a good one. The very fact that we're still discussing it proves that it isn't as obvious as I initially thought. That's fine with me. I will not insist anymore on this topic. IMO, it would be nice if a lightweight markup language like Org supported sophisticated letter writing out of the box. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [RFC] Proposal for rebindings in Org 8.3
i'd like to point out that some of these bindings are problematic on qwerty in a way that is not obvious to many users. many people use shifting keys on both sides of the keyboard. they do not issue the control of control g using left hand. that is a bad idea. instead, they hold down the right control with right hand then do g with left hand. any sequence where one step is on one side and another step is on the other side is fine unless they are both shifted. at that point they become so cumbersome they are likely to be rebound by the user. fortunately, most of emacs does not use the cumbersome type of binding. hih. samuel -- 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] Export to UTF8: tiny detail
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Exporting this: - I don't see the same prices as in the tutorial: in fact, the prices of =Simulation_1= and =Simulation_3= are inverted! gives that: • I don’t see the same prices as in the tutorial: in fact, the prices of `Simulation_1' and `Simulation_3' are inverted! (see the extra spaces added at the beginning of the 2^nd line) This should be fixed in maint. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
On 02/07/14, 17:47 , Eric Schulte wrote:
Rainer M Krug rai...@krugs.de writes:
On 02/07/14, 07:18 , John Hendy wrote:
Greetings,
I don't usually tangle, but am creating a code file to go along with a
presentation I'm giving this weekend so that attendees can try things
out afterward by cloning my github repo where all the data and
necessary files are stored.
In my presentation (Beamer), I create plots via the R pdf() device,
and noticed that all of the tangled code where plots are generated
contains the following:
pdf(file=file.pdf); tryCatch({
code block contents here
},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
paste('ERROR', e$message, sep=' : ')}); dev.off()
Is there a way to omit this?
This is a bug which must have been introduced some time ago - in the
stock version of emacs (Org-mode version 7.9.3f
(release_7.9.3f-17-g7524ef @
/usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
tangle the enclosing commands to create graphics, but in 8.2 it does (I
don't have an older version at hand to go further back).
I believe this was introduced by your commit eaa3a761d. Reversion of
which with the following should provide a temporary workaround.
I checked it with version 8.2, which was, as far as I remember, before
my change of the R code to include the error handling, and the pdf(...)
... dev.off() was in the tangled file as well - so the behaviour must
have been introduced earlier. The only change I did was to change the R
code, so no change in the behavior if it is tangled or not.
I will look at it again on Monday to go back through the released
versions to narrow down where this had changed.
git revert eaa3a761d
I don't think that this actually changes much - only that the enclosing
code will become pdf(...) THE CODE dev.off()
Cheers,
Rainer
Perhaps the try/catch code should be moved from org-babel-expand-body:R
to org-babel-execute:R. Alternately, the code should stay as is and you
should use the no-expand header argument during tangling.
I'm not sure which makes the most sense, but I'd lean towards the
former.
Best,
I'm guessing this is here to create a blank plot with the error as the
output when something goes awry?
Yes.
I checked around variable completions of org-babel-tangle-* and
searched google for terms like org babel tangle try catch but am not
finding anything that looks like what I need.
There is nothing, as it should not be tangled. The enclosing commands
concern the export, but not tangling,
I agree that the :result graphics header argument caused commands should
not be in the tangled file.
Another question is about the :epilogue and :prologue which I think
should be present (haven't checked if they are...).
Cheers,
Rainer
Thanks,
John
--
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
signature.asc
Description: OpenPGP digital signature
Re: [O] another blog exporter
Hi Rasmus, thank you very much for your feedback! On 02/07/2014 06:35 PM, Rasmus wrote: Could you provide an example blog so that we can see the output? The two latest posts (FreeBSD and DHCP) at http://www.xyzzy.de/ I put the original org for download at the end of both posts. ;;; Transcode Functions Example Block (defun org-blog-example-block (example-block contents info) Transcode a EXAMPLE-BLOCK element from Org to HTML. CONTENTS is nil. INFO is a plist holding contextual information. (if (org-export-read-attribute :attr_html example-block :textarea) (org-html--textarea-block example-block) ;;; beginnin here we need org/wp-syntac/syntaxhl information (format pre class=\example\\n%s/pre (org-html-format-code example-block info Isn't this an exact copy of the corresponding entry in ox-html (Less the name)? Why? - org-blog-example-block /is/ an exact copy, I planned to add the highlighters here, too, and to support line numbers. Forgot it :( - org-blog-latex-environment adds support for =#+ATTR_BLOG:= - org-blog-latex-fragment currently also is an exact copy. I'm not sure mathjax works, so I put it here for further work. - org-blog-link supports =attr_blog= and fills the list of images to be uploaded. (I really hated to copy this one... in an earler version I cl-flet-ted org-html--format-image to avoid copying this one. for org-blog-export-[as|to]-blog, I had no choice. :) I just found out, when I introduced scheduled posting I broke unscheduled posting; this is the patch: --- emacs/ox-blog.el2014-01-21 10:57:50 + +++ emacs/ox-blog.el2014-02-07 18:38:52 + @@ -1089,7 +1089,7 @@ ;; administrator may post (post-status (cond ((equal draft-or-publish-p draft) draft) ((equal contributor user-role) pending) - ((and publish-datetime + ((and (not (string= publish-datetime)) (or (equal author user-role) (equal administrator user-role))) future) Best regards and thank you very much for the feedback, Robert
Re: [O] Feature request: filling of long captions
Bastien b...@gnu.org writes: Hi all, Nicolas Goaziou n.goaz...@gmail.com writes: I'm sure this idea wouldn't be a net benefit for Org syntax clarity, even for the occasional three lines caption need. I agree. Nicolas, what do you think of enhancing the auto-filling (and delete-indentation) capabilities for some affiliated keywords? I did not realize that consecutive caption lines would be merged. This largely addresses my problem (no more Org-mode files going to column 600). If Org-mode had been thoughtful enough to autofill my #+Column lines as they got too long then I would have been completely satisfied. Thanks, #+CAPTION: #+HEADER: #+TBLFM: The last two would require special auto-filling functions, but at least for #+TBLFM I see the point of enabling this. Thanks, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] adding rudimentary support for Coq code blocks
Eric Schulte schulte.e...@gmail.com writes: See the attached example file. This is very rudimentary, only supporting session evaluation and without support for smart translation between Org-mode and Coq data structures. Very nice, thanks a lot! I use org mode with Coq, but only to document Coq developments. See http://jscert.org/dvpt.html for instance. By the way, I recently converted two persons to org mode because of its abilities to easily extract source code to pretty typesetting, both in HTML and LaTeX. Alan
Re: [O] adding options to the minted environment of exported source blocks in latex
Hello, Alan Schmitt alan.schm...@polytechnique.org writes: I use and abuse the `org-latex-minted-options' when exporting source blocks in latex, but I'm stumped by a usage pattern. I need to change the list of options for one given source block (adding a belowskip option to it). I tried the following, but it did not do anything: #+attr_latex: :belowskip 1cm #+BEGIN_SRC ocaml #load graphics.cma;; Graphics.open_graph ;; #+END_SRC I guess that I can only put some specific options for attr_latex. Is there a way to put arbitrary options in the exported minted environment? At the moment, there is no Org way to add arbitrary options to listings or minted on a per block basis. There are basically two ways to implement this. Either we add an :options keyword and stuff options there: #+attr_latex: :options a=b,c=d #+begin_src ... Another option is to turn options into keywords: #+attr_latex: :a b :c d #+begin_src ... The latter is more elegant, but it requires to know about every minted/listings options. It is also possible to do something in-between, i.e., tell Org about a few selected keywords and stuff the others into :options. This is what is done for images. Org knows about :height and :width and uses :options for everything else. Regards, -- Nicolas Goaziou
[O] Conditionally display breadcrumbs in agenda view
I know there is a way to display parent headlines using the agenda prefix. Is there a simple way to do this conditionally for certain subtrees? Here's my use case. I have an org file machines.org for keeping track of what I do to various machines I work on/administer (though I use that term hesitantly and extremely lightly :)). I keep TODO items for each machine for things like backups and updates. Sometimes I'll have an item that has subtasks and I don't want to make the parent heading a TODO item because it will clutter my agenda view. I just want the subtasks to show, but I'd like to have some reference to the overarching task. For example: * Tmux ** TODO Install ** TODO Set up basic keybindings ** TODO Fine tune config These showing up on their own could be a little esoteric. What I've been doing so far is just setting a CATEGORY property under Tmux so I can see what the top task is, but ideally I'd like to be able to set just this subtree to show Tmux/Install, etc in the agenda and everything else display normally. Is this possible? Thanks in advance Pete
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.hendy at gmail.com writes: An interesting update on this. Aside from some image and code block stuff, the following works surprisingly well! - Export Org - markdown (md) - Start an R session and `setwd(/path/to/file.md)` - Run `library(slidify)` and `author(deck) - Copy the deck/assets folder into the parent directory - Copy the header code from the resultant deck/index.Rmd file into exported .md file - Add three hyphens before each heading (headings are # Slide title) - Save the file as file.Rmd (vs. file.md) - From the R session, do `setwd(../)` (running `author(deck)` changes the working directory to deck/ - Run `slidify(file.Rmd)` [much deleted] John, You can put the header code into an MD export block (and ignore index.Rmd). You can add '#+MD: ---' keyword lines to mark new slides. Then you export to my.Rmd directly (using ravel) and run slidify(my.Rmd). Graphics 'just work', but you have to mind the spacing to be sure the slides render nicely. The file slidify-example.org at https://github.com/chasberry/orgmode-accessories/ produces a minimal slidify slideshow with code, computed results, and graphics. And it has some notes on org -- slidify using the md-knitr backend from ox-ravel. Ideally, a `md-slidify' backend would get written to automagically produce the yaml header, separate slides based on headline levels, et cetera. But that is a low priority right now. HTH, Chuck
Re: [O] Bug: dragging a line in agenda moves following hidden lines
Hi, Bastien, If it's difficult to keep dragging from moving hidden lines, I agree, `/ /' removing the re-ordering would be less confusing than seeing the hidden lines moved. By the way, another useful feature could be dragging all lines in the region if it's active. Thanks, Thomas
Re: [O] another blog exporter
Hi Robert, On Fri, 7 Feb 2014, Robert Klein wrote: around the org-mode 8.0 release I began to write a new blog exporter using the new export framework. I wanted one feature org2blog didn't offer, support for different syntax highlighters, and i wanted to learn about the new exporter and Emacs programming. Does your exporter work across multiple files (one file per post), or only one file? -k.
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.hendy at gmail.com writes:
On Fri, Feb 7, 2014 at 3:50 PM, Charles Berry ccberry at ucsd.edu wrote:
John Hendy jw.hendy at gmail.com writes:
An interesting update on this. Aside from some image and code block
[snip - how John turn org to Rmd to md]
John,
You can put the header code into an MD export block (and ignore
index.Rmd).
You can add '#+MD: ---' keyword lines to mark new slides.
Awesome! Hadn't thought of that, and sounds great.
Then you export to my.Rmd directly (using ravel) and run
slidify(my.Rmd).
Graphics 'just work', but you have to mind the spacing to be sure the
slides
render nicely.
Hmmm. Could you elaborate on this? I haven't experienced this with R +
ggplot. The presentation I'm working on for tomorrow is on geo-spatial
data with R and I generate a lot of maps. I find that something like
this doesn't produce properly scaled images:
#+header: :file .map.pdf
#+begin_src R :results output graphics :exports results
# install.packages(maps)
library(maps)
world - map_data(world)
p - ggplot(world, aes(x = long, y = lat, group = group))
p - p + geom_polygon(colour = white)
p
#+end_src
I often get something squarish, which makes the map look really
compressed (see attached). Thus, I seem to need both this (name,
header)
This is a problem that results from rendering in a square rather than
something proportional to what Mercator used: 202cm x 124cm, I think.
slidify wants to have png files for images, so I think you are stuck
having to set up the size of the device as well as the displayed size
to get nice looking results.
#+name: world-adj
#+header: :file map-adj.pdf :width 9 :height 6
#+begin_src R :results output graphics :exports results
# code from above
#+end_src
and this (right height for latex)
#+begin_center
#+attr_latex: :height 6cm
#+RESULTS: world-map
[[file: world-adj.pdf]]
#+end_center
I guess in this example, the heights are the same, however sometimes
this isn't the case as to use the right height for the slides can goof
with how proportionally big the axis, label, and legend text is and it
requires, in my opinion, wy more work to use the theme() arguments
in ggplot2 to tailor them correctly vs. just playing with
:width/:height options and then scaling the final image in the
#+RESULTS section.
I would love to avoid the above if you have more clarification on just
work :)
I wasn't thinking about the case you just demonstrated. I have to use
a line that gives out.width, out.height, fig.width, and fig.height, which
slidify ('knitr' under the hood) uses to render the png and the page as you
did to make something that looks like the Mercator map and still have
the text look OK. See http://yihui.name/knitr/options if the options
listed are not familiar. (knitr chunk options can be put in #+ATTR_RAVEL:
lines for ravel exports to use them.)
[more deleted]
One other question while we're at it... I noticed that
#+begin/end_center produces this in the output .md file:
div class=center
/div
This doesn't export with slidify. [snip more details]
Right. IMO, using the knitr tools for dealing with such issues beats
wrestling with the babel and md exporter. i.e. fig.align=center handles
this. A good part of my motivation for ox-ravel is that I can deal with
fine tuning output from knitr more easily than I can w/ babel exports.
HTH,
Chuck
[O] Hide done/ cancelled items
Is there a way to hide done/ cancelled items? I have ** A Project and lots of *** items that are done and I want to hide to avoid distractions. After the project is done, I will move the ** A Project along with all the *** items to the _archive file. Thanks.
Re: [O] Proposal/request for input: slidify export for html slides
On Fri, Feb 7, 2014 at 11:38 PM, John Hendy jw.he...@gmail.com wrote:
On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry ccbe...@ucsd.edu wrote:
[snip]
I'll look into those. I just cloned your repo and loaded ox-ravel.
Quite nice! It worked /pretty/ well out of the box. One issue is that
it doesn't seem to obey :eval no for babel blocks. I exported to .Rmd
successfully, but the presentation has a bunch of errors in the code
blocks from trying to actually execute the code. The .Rmd doesn't have
any instances of ```{r eval=F}; could this feature be added?
Just kidding. Discovered #+attr_ravel and the proper knitr argument
for code chunks, which worked as expected with:
#+attr_ravel: eval=F
#+begin_src R ...
I still think it makes sense to allow :eval no. This seems more
Org-ish since the ideology is to have one set of Org syntax where
possible, which translates to any number of languages. I get that we
have #+attr_latex for latex-only things, #+attr_html for html-only
things, and so on, but I wouldn't consider :eval to fall into this
category. Or perhaps I don't understand... would the idea be that I
don't want to run it in *Org*, but I'd not want all my chunks disabled
in the .Rmd?
My workflow might be odd in that I tend to futz with plot parameters
once, get the desired image, and then set :eval no for the rest of my
document work so I don't have to wait for plots on iterative exports.
I try to put all my setup code (load packages, data
reading/manipulation, etc.) in it's own block so that I can easily run
that whenever I first open the document. From there I only need to
re-run a plot block if necessary and I'll just temporarily change
:eval no - yes and then back again after execution.
Thanks again,
John
