Re: [O] [ANN] Edit emails in Org-mode
Hello, Thorsten Jolitz wrote: > 2.3 Usage > ~ > > There are only two commands involved: > >Command Keybinding Comment > --- >M-x outorg-edit-as-org M-# M-# or M-# # outline-prefix M-# >C-c ' outline-prefix C-c >M-x outorg-copy-edits-and-exit M-#--- When I have "message" code blocks, and when I edit them in an indirect buffer (for refilling them, for example), then I have a draft message that stays in my Gnus/Message emails. Any idea how to get rid of that? Best regards, Seb -- Sebastien Vauban
[O] Help with beamer environments
I am trying to use textpos to position images at specific location on
a frame.
I would like something like this in the beamer export:
\begin{textblock}{10}(3,3) \visible <2-> {
\includegraphics[width=.9\linewidth]{scatterplot2.png}
} \end{textblock}
I have defined the following beamer environment.
(add-to-list 'org-beamer-environments-extra
'("textpos1" "w" "\\begin{textblock}{%h}(3,3) \\visible %a {" "}
\\end{textblock}"))
The problem is (3,3) is fixed in the above specification. How can I
specify it for a given headline? I have tried various ways of
generalising this but nothing seems to work.
For example, if I use the following:
(add-to-list 'org-beamer-environments-extra
'("textpos1" "w" "\\begin{textblock}%h \\visible %a {" "}
\\end{textblock}"))
and write the headline as {10}(3,3), I get \{10\}(3,3) in beamer
export rather than {10}(3,3).
How does one use the escape %o? I have looked through ox-beamer.el,
worg and mailing list archives, but could not find a clear
explanation. Will be grateful for a pointer.
Vikas
Re: [O] [PATCH 1/2] org-notify: Don't use obsolete flet and macrolet
On 19.6.2013, at 20:46, David Engster wrote: > Achim Gratz writes: >> Peter Münster writes: cl-lib was just introduced in Emacs 24.3. >>> >>> Does that mean, that the trunk should be modified later? >> >> It means you should implement a solution that doesn't make Org >> non-functional for Emacs 23 users. > > The easiest solution is to simply do nothing, until Org drops support > for Emacs 24.2 and earlier. The 'cl' library will be shipped with Emacs > for a long time. > > BTW, which Emacs versions does Org support? Is this documented anywhere? No, but loosely, we have tried to support the current major version (i.e. 24) and the previous major version (i.e. 23) - Carsten
Re: [O] Slides about LaTeX export
Hello, "Fabrice Niessen" wrote: > "Fabrice Niessen" wrote: >> Viktor Rosenfeld wrote: >>> Fabrice Niessen wrote: Could one of you report (as suggested by Nick) whether it works (or not) from another browser on the Mac? >>> >>> Snow Leopard 10.6.8: >>> >>> - Chrome: only yellow boxes >>> - Safari: only yellow boxes >>> - Firefox: yellow boxes with code >> >> Thanks to all for your tests. I'll report the problems to SlideShare -- I >> think they must have the key. At least, I hope so. > > For your information, I've opened a ticket on SlideShare. But it seems we > can't expect so good news for our Beamer slides: > > ╭ http://help.slideshare.com/requests/42307 (full ticket report) > │ > │ Let me send this off to my team to look into to see if this can be > │ resolved, but since the majority of files (including PDF's) that we > │ receive on SlideShare are from more common file creation tools such as > │ PowerPoint, this may take some time, and we may not support PDF's > │ created with this process. > ╰ > > Quite disappointing: we use the best tool to typeset our presentations, > and they are the worst when displayed on SlideShare... BTW, I've now allowed (it wasn't "on" by default) downloading the original PDF file from SlideShare. So, you can get the original file (about the LaTeX exporter) in case you don't see correctly part of the pages at http://fr.slideshare.net/fniessen/org-modelatexexport Best regards, Fabrice -- Fabrice Niessen Leuven, Belgium
Re: [O] [PATCH 1/2] org-notify: Don't use obsolete flet and macrolet
On Thu, Jun 20 2013, Carsten Dominik wrote: >> The easiest solution is to simply do nothing, until Org drops support >> for Emacs 24.2 and earlier. The 'cl' library will be shipped with Emacs >> for a long time. >> >> BTW, which Emacs versions does Org support? Is this documented anywhere? > > No, but loosely, we have tried to support the current major version (i.e. 24) > and > the previous major version (i.e. 23) All right. Please apply this patch only later, when emacs 25 is out. -- Peter
Re: [O] [ANN] Edit emails in Org-mode
"Sebastien Vauban" writes: Hello, its a nice idea to be able to replace the source-blocks by their results when composing messages (if I understood your feature request right). Opens a lot of possiblilities for (semi-)automatic email creation. Here is the doc-string: #+begin_src emacs-lisp (defun outorg-replace-source-blocks-with-results (&optional arg &rest languages) "Replace source-blocks with their results. Only source-blocks with ':export results' in their header arguments will be mapped. If LANGUAGES is non-nil, only those source-blocks with a language found in the list are mapped. If LANGUAGES is nil but a prefix-argument ARG is given, only the languages read from the mini-buffer (separated by blanks) are mapped. Otherwise, all languages found in `org-babel-load-languages' are mapped." ...) #+end_src it basically says: - only blocks with ':export results' will be mapped - blocks for all languages found in `org-babel-load-languages' will be mapped, except the function ist called (from a program) with a list of language names (as strings) or the user calls the command with prefix arg (e.g. C-u) and enters language names (like this: R emacs-lisp sh org). let me know if the function does what you wanted. Do we need a keybinding for that, or should it rather be a bit oscure (only accessible by M-x) to avoid confusing accidents? > Thorsten Jolitz wrote: >> 2.3 Usage >> ~ >> >> There are only two commands involved: >> >>Command Keybinding Comment >> --- >>M-x outorg-edit-as-org M-# M-# or M-# # outline-prefix M-# >>C-c ' outline-prefix C-c >>M-x outorg-copy-edits-and-exit M-#--- > > When I have "message" code blocks, and when I edit them in an indirect buffer > (for refilling them, for example), then I have a draft message that stays in > my Gnus/Message emails. > > Any idea how to get rid of that? > > Best regards, > Seb -- cheers, Thorsten
[O] [PATCH] link-home in html exporter
Hi list, diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 365802f..90d6a5d 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -1719,7 +1719,7 @@ holding export options." "\n" (let ((link-up (org-trim (plist-get info :html-link-up))) (link-home (org-trim (plist-get info :html-link-home - (unless (and (string= link-up "") (string= link-up "")) + (unless (and (string= link-up "") (string= link-home "")) (format org-html-home/up-format (or link-up link-home) (or link-home link-up
[O] customize category width in agenda
If I read the manual correctly the category is 10 characters wide. Is there a way to reduce it? -- New guy cross-connected phone lines with AC power bus. -- BOFH excuse #38
[O] Bug: Setting HTML_INCLUDE_STYLE: nil doesn't work [8.0.3 (8.0.3-32-g0c789f-elpa @ /home/aj/.emacs.d/elpa/org-20130617/)]
I put:
#+HTML_INCLUDE_STYLE: nil
at the top of my org-file and expect the exported html file to not
include the standard styles in it's header (documentation section
"12.6.9 CSS support").
This does not work and the styles are included as usual.
A quick debugging with edebug reveals that nil is interpreted as a
string, "nil", in the info-plist and therefore evaluates as true in the
check in org-html--build-head:
(when (plist-get info :html-head-include-default-style)
(org-element-normalize-string org-html-style-default))
(from: ox-html.el:1448)
Greetings,
Anders Johansson
Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4)
of 2013-04-14 on marid, modified by Debian
Package: Org-mode version 8.0.3 (8.0.3-32-g0c789f-elpa @
/home/aj/.emacs.d/elpa/org-20130617/)
current state:
==
(setq
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
outline-minor-mode-hook '((lambda nil (local-set-key ""
outline-mode-prefix-map)
(define-key outline-minor-mode-map
[(control tab)] (quote org-cycle))
(define-key outline-minor-mode-map [(shift
tab)] (quote org-global-cycle)))
)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-capture-after-finalize-hook '(orgaj-after-capture-options)
org-confirm-shell-link-function 'yes-or-no-p
org-speed-commands-user '(("p" ded/org-show-previous-heading-tidily)
("n" ded/org-show-next-heading-tidily))
org-startup-folded nil
org-default-notes-file "~/org/notes.org"
org-startup-indented t
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-capture-mode-hook '((lambda nil
(remove-hook (quote
org-capture-after-finalize-hook)
(quote (lambda nil (delete-frame
)
)
org-from-is-user-regexp "\\"
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-tags-column -90
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-show-block-all append local] 5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-use-speed-commands t
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-hide-inline-tasks
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-M-RET-may-split-line '((headline . t) (default . t))
org-hide-emphasis-markers t
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-fontify-whole-heading-line t
org-agenda-files '("~/org/attsalja.org" "~/org/attkopa.org"
"~/org/sakerattfixa.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-after-todo-statistics-hook '(org-summary-todo)
)
Re: [O] Slides about LaTeX export
On Jun 14, 2013 4:37 PM, "Fabrice Niessen" wrote: > > Hello, > > Just to let you know I've made a 1h30 presentation about the LaTeX exporter of > Org mode 8 at the "Stage LaTeX de Dunkerque 2013", on last Wednesday (12th of > June). > > My slides are visible on: > > http://fr.slideshare.net/fniessen/org-modelatexexport > > The Org source, LaTeX generated file and PDF output are on: > > http://www.github.com/fniessen > Very nice! Really nice overview of side by side "translations" between Org and LaTex. Out of curiosity, why didn't the exponent and subscript examples get rendered/converted on slide 22? John > Best regards, > Fabrice > > -- > Fabrice Niessen > Leuven, Belgium > >
Re: [O] customize category width in agenda
On Jun 20, 2013, at 9:30 AM, Ivan Kanis wrote: > If I read the manual correctly the category is 10 characters wide. Is > there a way to reduce it? Yes, you can, take a look at the variable org-agenda-prefix-format HTH - Carsten
Re: [O] One more question on bibliographies in Org
>> The main question is: what would be a convenient way to store the >> references in the .org file, to allow for easy editing and exporting >> ? > > What I have done so far is to use some bibtex blocks, which tangle to > an external bib files. It is sometime useful to have the bibliography > divided in separate sections inside the org file. That sounds good for purely LaTeX/PDF exports, thanks for the suggestion. Now, how to do it for HTML ? Is it possible to choose the tangle format / destination depending on the current export backend ? -- Vincent Beffara
Re: [O] [PATCH] minor patch to org-babel-load-file
Michael Brand writes: > Hi Levin > > On Tue, Jun 18, 2013 at 9:44 AM, Levin Du wrote: >> Below is the patch that solves this problem. > > Recently I also noticed a regression of org-babel-load-file that is > resolved with your patch. Thank you for saving me of one of my TODOs. > This patch doesn't fix the actual cause of this bug. The problem stems from commit 693dda67 [1], and I've just pushed up a fix in commit a79fd4be [2]. Thanks to both of your for raising this issue. Footnotes: [1] commit 693dda67e60530c9f7b2510f44f6d14595473e28 Author: Achim Gratz Date: Fri Jun 7 22:19:38 2013 +0200 ob-core: allow language specific header arguments in properties * lisp/ob-core.el (org-babel-insert-header-arg, org-babel-parse-src-block-match): Replace `if' with empty else part by `when' for readability. (org-babel-params-from-properties): Inquire for language specific and default header properties. Language specific header properties take precedence over default header properties and old-style header property specifications. This allows for header arguments to be specified as properties (including inheritance). #+PROPERTY: header-args :cache "no" #+PROPERTY: header-args:R :session "*R-property*" :PROPERTIES: :header-args: :cache "yes" :header-args:R: :session "*R-drawer*" :END: [2] commit a79fd4be2863a300c88218b40b1adca23d9e1eb8 Author: Eric Schulte Date: Thu Jun 20 09:53:56 2013 -0600 fix babel merge params bug from commit 693dda67 The `org-babel-params-from-properties' command was calling `org-babel-merge-params', the output of which was then being fed back to another call to `org-babel-merge-params'. The merge params function is not designed to allow this form of recursive calling, and as a result many variables were being set to empty values. The first noticed side effect of this bug was the breakage of the org-babel-load-file command, which relies on default header arguments (namely :tangle), which were overwritten by the bug above. The fix involved having the `org-babel-params-from-properties' function return a list of alists, which may then all be handed to the top-level merge-params call. * lisp/ob-core.el (org-babel-params-from-properties): Now returns a list of alists and does *not* call `org-babel-merge-params'. (org-babel-parse-src-block-match): Handle new list of lists output of `org-babel-params-from-properties'. (org-babel-parse-inline-src-block-match): Handle new list of lists output of `org-babel-params-from-properties'. * lisp/ob-exp.el (org-babel-exp-src-block): Handle new list of lists output of `org-babel-params-from-properties'. (org-babel-exp-non-block-elements): Handle new list of lists output of `org-babel-params-from-properties'. * lisp/ob-lob.el (org-babel-lob-execute): Handle new list of lists output of `org-babel-params-from-properties'. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Unexpected behaviour with gnuplot source blocks
Christopher Witte writes: > Hi all, > > I had some wierd behaviour with gnuplot source blocks and I'm not sure of > the best way to fix it. > > I have gnuplot source blocks that write output files that I insert into the > document using links, as such: > > #+begin_src gnuplot :file transInc.eps > reset > set encoding utf8 > set output "./fig/transInc.eps" > . > #+end_src > [[fig/transInc.eps]] > Why not do the following instead which would be equivalent and simpler. The output will be automatically set from the value of your :file header argument. #+begin_src gnuplot :file fig/transInc.eps reset set encoding utf8 . #+end_src > > and I have two documents in different directories, say 'a' and 'b' > that do this. If I go to the first document in folder 'a' and export > it to latex and then go to the second document in folder 'b' and also > export it to latex, all the generated plots end up in 'a'. It took me > a while to work it out, but this is because only one gnuplot session > is started and 'reset' doesn't reset output. Killing the gnuplot > buffer fixes this, but that is annoying if I frequently switch back > and forth between the documents. > Does setting :session to "none" for gnuplot fix this problem? > > I could use full paths, but that seams like a pain, any other suggestions? > > Thanks for the help, > Chris. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz writes: > Hi Eric, > > while starting to write up a test document I've found some behaviour > when executing LOB calls that warrant discussion, I think: > > 1. The properties are evaluated at the site of the definition rather >than the site of the call. I see what you're saying. The attached org-mode file demonstrates. * first :PROPERTIES: :CUSTOM_ID: first :END: #+name: heading-id #+begin_src emacs-lisp :var point=(point) (format "%s at %d" (org-entry-get point "CUSTOM_ID") point) #+end_src #+RESULTS: heading-id : first at 53 * second :PROPERTIES: :CUSTOM_ID: second :END: #+call: heading-id(point=(point)) #+RESULTS: heading-id(point=(point)) : first at 53 > This is simply how org-babel-process-params works, it jumps to the > definition and then executes the source block there (this may be in > another file even). > > 2. The evaluation of header arguments assumes emacs-lisp as a language. > Yes, if one wants to execute a language other than Emacs-Lisp, then they should use a full fledged code block and pass a reference to that code block into the header argument. > > These two combined make it somewhat difficult to use properties to > control the behaviour of LOB calls and understand what is happening and > why. A workaround is to beam the source to the place of call via noweb > syntax. This seem a little Rube Goldberg'ish to me. > The first point could perhaps be addressed in a cleaner way by using > org-babel-current-src-block-location when calling org-entry-get, but > I'm not sure yet if it is always correctly set. I think the best way to handle the first issue would be to use the recently introduced `org-babel-current-src-block-location' variable, and jump back to that location when evaluation header arguments. > Another thorny question is how to deal with another layer of calls > that might evaluate properties again. If this is something we need to support, then we would want to turn the `org-babel-current-src-block-location' variable into a list onto which we push and pop locations. Presumably it would then be possible to evaluate each header argument at the correct location. > A last option would be to introduce another header argument that can > be used to inject the properties into the argument list of the call > and, if set, would suppress any property evaluation in downstream > calls. > I'm not sure I fully understand this solution. > > For the second, I think that "lob" should be treated as a language for > the purpose of anything *-default-header-args* so these settings can be > independently controlled. > I don't know what this means. I'm either mis-understanding your second issue, or I strongly disagree with it. I do not think it should be possible to embed arbitrary language source code into header arguments. Cheers, > > > Thoughts, comments? > > > Regards, > Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [PATCH] minor patch to org-babel-load-file
Hi Eric On Thu, Jun 20, 2013 at 5:58 PM, Eric Schulte wrote: > I've just pushed up a fix in commit a79fd4be [2]. Thank you, the issue with org-babel-load-file that I noticed is resolved in the current master branch. Michael
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: >> 2. The evaluation of header arguments assumes emacs-lisp as a language. > > Yes, if one wants to execute a language other than Emacs-Lisp, then they > should use a full fledged code block and pass a reference to that code > block into the header argument. […] >> For the second, I think that "lob" should be treated as a language for >> the purpose of anything *-default-header-args* so these settings can be >> independently controlled. > > I don't know what this means. I'm either mis-understanding your second > issue, or I strongly disagree with it. I do not think it should be > possible to embed arbitrary language source code into header arguments. I'm talking about the ephemeral source block that org-babel-lob-execute constructs. This is an emacs-lisp block and I see indeed no use of using a different language there, but I don't think it should necessarily use the default header arguments for all other emacs-lisp blocks. If these header arguments must be changeable, rather than simply fixed, my suggestion is to use org-babel-default-header-args:lob for that (and the moral equivalent for properties) so that setting some strange default haeder args for elisp blocks doesn't inadvertently take out LOB calls. >> These two combined make it somewhat difficult to use properties to >> control the behaviour of LOB calls and understand what is happening and >> why. A workaround is to beam the source to the place of call via noweb >> syntax. > > This seem a little Rube Goldberg'ish to me. That's actually a somewhat natural looking construct in Babel; certainly not the most elegant, but it gets the job done. > I think the best way to handle the first issue would be to use the > recently introduced `org-babel-current-src-block-location' variable, and > jump back to that location when evaluation header arguments. I still have to convince myself that this works for this purpose, but yes, that'd be the most obvious solution if the properties should only be evaluated from the site of call. If anything, the resulting behaviour for nested Babel calls is more difficult to explain than what we have now however. >> Another thorny question is how to deal with another layer of calls >> that might evaluate properties again. > > If this is something we need to support, then we would want to turn the > `org-babel-current-src-block-location' variable into a list onto which > we push and pop locations. Presumably it would then be possible to > evaluate each header argument at the correct location. That may not be as easy as you make it sound in the above sentence. Anyway, if we had such a (hypothetical) facility, I'm not sure if the additional control over the execution produces a net benefit over the increased complexity. >> A last option would be to introduce another header argument that can >> be used to inject the properties into the argument list of the call >> and, if set, would suppress any property evaluation in downstream >> calls. > > I'm not sure I fully understand this solution. Since it is another hypothetical solution, I'm not sure yet either. The idea is to record only the original call site in org-babel-current-src-block-location and hand (probably a list of) additional call sites or properties evaluated at those sites over to the source block as a header argument. This would have the benefit that the called function might be able to decide what to do with those, in particular overwrite or delete it. This allows yet more control, but see above. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] [PATCH] minor patch to org-babel-load-file
Eric Schulte writes: >> Recently I also noticed a regression of org-babel-load-file that is >> resolved with your patch. Thank you for saving me of one of my TODOs. >> > > This patch doesn't fix the actual cause of this bug. The problem stems > from commit 693dda67 [1], and I've just pushed up a fix in commit > a79fd4be [2]. Thanks for catching that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [ANN] Convert Org-mode file to Source-code file
Thorsten Jolitz gmail.com> writes: > > Hi List, > > it is now possible to convert existing Org-mode files with source-blocks into > machine-executable source-code files, using the following function from > `outorg.el': > > #+begin_src emacs-lisp > (defun outorg-convert-org-file-to-source-code > (&optional mode infile outfile BATCH) With this buffer , | | | * head1 | | abc | | | #+NAME: test-src | #+BEGIN_SRC R | ls() | #+END_SRC ` it fails with Debugger entered--Lisp error: (void-variable outorg-code-buffer-beg-of-subtree-marker) (set-marker outorg-code-buffer-beg-of-subtree-marker nil) outorg-reset-global-vars() outorg-copy-edits-and-exit() ... in the backtrace. The tmp buffer looks right, though , | | | ## * head1 | | ## abc | | | ## #+NAME: test-src | ls() ` HTH, Chuck
Re: [O] [PATCH] link-home in html exporter
Hello, "Daniel G. Gerber" writes: > Hi list, > > diff --git a/lisp/ox-html.el b/lisp/ox-html.el > index 365802f..90d6a5d 100644 > --- a/lisp/ox-html.el > +++ b/lisp/ox-html.el > @@ -1719,7 +1719,7 @@ holding export options." > "\n" > (let ((link-up (org-trim (plist-get info :html-link-up))) > (link-home (org-trim (plist-get info :html-link-home > - (unless (and (string= link-up "") (string= link-up "")) > + (unless (and (string= link-up "") (string= link-home "")) > (format org-html-home/up-format >(or link-up link-home) >(or link-home link-up Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] customize category width in agenda
June, 20 at 15:03 Carsten Dominik wrote: > On Jun 20, 2013, at 9:30 AM, Ivan Kanis wrote: > >> If I read the manual correctly the category is 10 characters wide. Is >> there a way to reduce it? > > Yes, you can, take a look at the variable org-agenda-prefix-format > > HTH Perfect! -- Academic politics is the most vicious and bitter form of politics, because the stakes are so low. -- Wallace Sayre
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz writes: > Eric Schulte writes: >>> 2. The evaluation of header arguments assumes emacs-lisp as a language. >> >> Yes, if one wants to execute a language other than Emacs-Lisp, then they >> should use a full fledged code block and pass a reference to that code >> block into the header argument. > […] >>> For the second, I think that "lob" should be treated as a language for >>> the purpose of anything *-default-header-args* so these settings can be >>> independently controlled. >> >> I don't know what this means. I'm either mis-understanding your second >> issue, or I strongly disagree with it. I do not think it should be >> possible to embed arbitrary language source code into header arguments. > > I'm talking about the ephemeral source block that org-babel-lob-execute > constructs. This is an emacs-lisp block and I see indeed no use of > using a different language there, but I don't think it should > necessarily use the default header arguments for all other emacs-lisp > blocks. If these header arguments must be changeable, rather than > simply fixed, my suggestion is to use org-babel-default-header-args:lob > for that (and the moral equivalent for properties) so that setting some > strange default haeder args for elisp blocks doesn't inadvertently take > out LOB calls. > Oh, I understand now. I would also be happy with using *no* header arguments for this ephemeral elisp block if that is easily accomplished. > > >>> These two combined make it somewhat difficult to use properties to >>> control the behaviour of LOB calls and understand what is happening and >>> why. A workaround is to beam the source to the place of call via noweb >>> syntax. >> >> This seem a little Rube Goldberg'ish to me. > > That's actually a somewhat natural looking construct in Babel; certainly > not the most elegant, but it gets the job done. > >> I think the best way to handle the first issue would be to use the >> recently introduced `org-babel-current-src-block-location' variable, and >> jump back to that location when evaluation header arguments. > > I still have to convince myself that this works for this purpose, but > yes, that'd be the most obvious solution if the properties should only > be evaluated from the site of call. If anything, the resulting > behaviour for nested Babel calls is more difficult to explain than what > we have now however. > I agree. This sounds like it would probably be overkill. > >>> Another thorny question is how to deal with another layer of calls >>> that might evaluate properties again. >> >> If this is something we need to support, then we would want to turn the >> `org-babel-current-src-block-location' variable into a list onto which >> we push and pop locations. Presumably it would then be possible to >> evaluate each header argument at the correct location. > > That may not be as easy as you make it sound in the above sentence. > Anyway, if we had such a (hypothetical) facility, I'm not sure if the > additional control over the execution produces a net benefit over the > increased complexity. > Agreed. > >>> A last option would be to introduce another header argument that can >>> be used to inject the properties into the argument list of the call >>> and, if set, would suppress any property evaluation in downstream >>> calls. >> >> I'm not sure I fully understand this solution. > > Since it is another hypothetical solution, I'm not sure yet either. The > idea is to record only the original call site in > org-babel-current-src-block-location and hand (probably a list of) > additional call sites or properties evaluated at those sites over to the > source block as a header argument. This would have the benefit that the > called function might be able to decide what to do with those, in > particular overwrite or delete it. This allows yet more control, but > see above. > Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). Cheers, > > > > Regards, > Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [ANN] Convert Org-mode file to Source-code file
How does this differ from ":tangle yes :comments org"? e.g., #+Property: tangle yes #+Property: comments org * This is the top #+begin_src sh :shebang #!/bin/bash echo "##this file will cat itself" echo "" #+end_src Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. | a | table | | in | the | | tangled | file | #+begin_src sh cat $0 #+end_src tangles to #!/bin/bash # This is the top echo "##this file will cat itself" echo "" # Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec # hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam # nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis # natoque penatibus et magnis dis parturient montes, nascetur ridiculus # mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non # turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum # accumsan nisl. # | a | table | # | in | the | # | tangled | file | cat $0 Thorsten Jolitz writes: > Hi List, > > it is now possible to convert existing Org-mode files with source-blocks into > machine-executable source-code files, using the following function from > `outorg.el': > > #+begin_src emacs-lisp > (defun outorg-convert-org-file-to-source-code > (&optional mode infile outfile BATCH) > "Convert an existing Org-mode file into an Outshine buffer. > > If MODE is non-nil, the Outshine buffer will be put in this > major-mode, otherwise the major-mode of the language of the first > source-code block in the Org-mode buffer will be used. > > If INFILE is non-nil, the specified Org-mode file will be visited > and its buffer converted, otherwise the current buffer will be > converted. > > If OUTFILE is non-nil, the converted Outshine buffer will be saved in this > file. Its the user's responsability to make sure that OUTFILE's > file-extension is suited for the major-mode of the Outshine buffer to be > saved. When in doubt, consult variable `auto-mode-alist' for associations > between file-extensions and major-modes. > > If BATCH is non-nil (and OUTFILE is non-nil, otherwise it makes > no sense), the new Outshine file is saved and its buffer > deleted."...) > #+end_src > > Usage example: > > , > | (outorg-convert-org-file-to-source-code > |"emacs-lisp-mode" "~/junk/test.org" "~/junk/test.el" 'BATCH) > ` > > I'm not sure about the general use case for this, but I do have my uses for > it, so I announce it here because it might serve others too. > > PS > This is *not* about tangling, try it out to see the (big) difference. -- Eric Schulte http://cs.unm.edu/~eschulte
[O] Setting entry title by a standard org function?
Hello! Is there a standard way in the org-mode modules to change the text of a heading conserving tags, todo type, priority etc? I am writing a extension module for better multi-file handling (wiki-like) and in that context I want to set the first heading of the wiki-node-files based on the directory name. Currently my best-guess solution is to rebuild the heading line from scratch -- while I found functions for setting tags, priority, todo-keyword I didn't find one for setting the title. Downside: Doing so is probably incompatible with whatever customization-capabilities there may be in the syntax, so I want to avoid that. kind regards, Klaus
[O] Bug: broken agenda view? [8.0.2 (8.0.2-dist @ /usr/share/emacs/site-lisp/org-mode/)]
when given this file: * top level :@home: ** TODO next level :@town: * more top :@work: and doing C-cat I get this: Global list of TODO items of type: ALL Available with `N r': (0)[ALL] Isn't that wrong? It shows NO todo items. Emacs : GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.3) of 2013-05-25 on orion Package: Org-mode version 8.0.2 (8.0.2-dist @ /usr/share/emacs/site-lisp/org-mode/) current state: == (setq org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-babel-pre-tangle-hook '(save-buffer) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-metadown-hook '(org-babel-pop-to-session-maybe) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-after-todo-state-change-hook '(org-clock-out-if-current) org-confirm-shell-link-function 'yes-or-no-p ) -- -Kevin "The world belongs to those who cross many bridges in their imagination, before others see even a single bridge." - inspirational Chinese proverb
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: > Oh, I understand now. I would also be happy with using *no* header > arguments for this ephemeral elisp block if that is easily accomplished. I'll make a patch for testing this. > Hopefully the simpler solution which uses the existing value of > `org-babel-current-src-block-location' will prove sufficient (once > someone implements it that is...). I'll implement it and see if this seems more useful than the current behaviour. If it is, then we'll have to decide if that new behaviour replaces the old one or yet another header argument or option switches between old and new. I guess it could be arranged so that the old-style properties kept the old behaviour and the new-style properties followed the new… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
[O] [RFC] Replace some HTML related keywords with OPTIONS items
Hello,
Any objection to applying the following patch to master?
Basically,
#+HTML_INCLUDE_STYLE: nil
becomes
#+OPTIONS: html-style:nil
and
#+HTML_HTML5_FANCY: t
becomes
#+OPTIONS: html5-fancy:t
Regards,
--
Nicolas Goaziou
>From dff24cc4ec2c3466526802042fd89dce0d99f633 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 20 Jun 2013 21:14:57 +0200
Subject: [PATCH] ox-html: Use OPTIONS items instead of keywords for booleans
* lisp/ox-html.el (html): Replace "HTML_HTML5_FANCY" and
"HTML_INCLUDE_STYLE" with, respectively, ":html5-fancy" and
"html-style" options.
(org-html-html5-fancy): Reformat docstring.
* doc/org.texi (HTML doctypes): Reflect keyword removal.
(CSS support): Reflect keyword removal.
The reasoning behind this change is that keywords can only store
strings as value. Therefore, they are not suited for toggles ("nil"
vs nil) problem.
---
doc/org.texi| 8
lisp/ox-html.el | 9 -
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index bddc518..3f7c9fb 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11055,7 +11055,7 @@ See the variable @code{org-html-doctype-alist} for details. The default is
HTML5 introduces several new element types. By default, Org will not make
use of these element types, but you can set @code{org-html-html5-fancy} to
-@code{t} (or use the corresponding @code{HTML_HTML5_FANCY} export option), to
+@code{t} (or set @code{html5-fancy} item in an @code{OPTIONS} line), to
enable a few new block-level elements. These are created using arbitrary
#+BEGIN and #+END blocks. For instance:
@@ -11352,9 +11352,9 @@ Each exported file contains a compact default style that defines these
classes in a basic way@footnote{This style is defined in the constant
@code{org-html-style-default}, which you should not modify. To turn
inclusion of these defaults off, customize
-@code{org-html-head-include-default-style} or set @code{#+HTML_INCLUDE_STYLE}
-to @code{nil} on a per-file basis.}. You may overwrite these settings, or add to
-them by using the variables @code{org-html-head} and
+@code{org-html-head-include-default-style} or set @code{html-style} to
+@code{nil} in an @code{OPTIONS} line.}. You may overwrite these settings, or
+add to them by using the variables @code{org-html-head} and
@code{org-html-head-extra}. You can override the global values of these
variables for each file by using these keywords:
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 90d6a5d..56f478e 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -116,7 +116,7 @@
(:html-link-org-as-html nil nil org-html-link-org-files-as-html)
(:html-doctype "HTML_DOCTYPE" nil org-html-doctype)
(:html-container "HTML_CONTAINER" nil org-html-container-element)
-(:html-html5-fancy "HTML_HTML5_FANCY" nil org-html-html5-fancy)
+(:html-html5-fancy nil "html5-fancy" org-html-html5-fancy)
(:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
(:html-link-up "HTML_LINK_UP" nil org-html-link-up)
(:html-mathjax "HTML_MATHJAX" nil "" space)
@@ -124,7 +124,7 @@
(:html-preamble nil "html-preamble" org-html-preamble)
(:html-head "HTML_HEAD" nil org-html-head newline)
(:html-head-extra "HTML_HEAD_EXTRA" nil org-html-head-extra newline)
-(:html-head-include-default-style "HTML_INCLUDE_STYLE" nil org-html-head-include-default-style newline)
+(:html-head-include-default-style nil "html-style" org-html-head-include-default-style newline)
(:html-head-include-scripts "HTML_INCLUDE_SCRIPTS" nil org-html-head-include-scripts newline)
(:html-table-attributes nil nil org-html-table-default-attributes)
(:html-table-row-tags nil nil org-html-table-row-tags)
@@ -919,9 +919,8 @@ publishing, with :html-doctype."
:type 'string)
(defcustom org-html-html5-fancy nil
- "When exporting to HTML5, set this to t to use new HTML5
- elements. This variable is ignored for anything other than
- HTML5.
+ "Non-nil means using new HTML5 elements.
+This variable is ignored for anything other than HTML5 export.
For compatibility with Internet Explorer, it's probably a good
idea to download some form of the html5shiv (for instance
--
1.8.3.1
Re: [O] :session question -- and changes to #+Property: syntax
>> Hopefully the simpler solution which uses the existing value of >> `org-babel-current-src-block-location' will prove sufficient (once >> someone implements it that is...). > > I'll implement it and see if this seems more useful than the current > behaviour. If it is, then we'll have to decide if that new behaviour > replaces the old one or yet another header argument or option switches > between old and new. I guess it could be arranged so that the old-style > properties kept the old behaviour and the new-style properties followed > the new… > Introducing another header argument controlling this setting would add too much complexity. I think we either stick with the existing behavior or (preferably) change the default behavior. Thanks for taking these on! > > > Regards, > Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items
Update.
I forgot to change
#+HTML_INCLUDE_SCRIPTS: t
into
#+OPTIONS: html-scripts:t
for the same reason.
--
Nicolas Goaziou
>From f99c5a071e185301bbef576c042afa07f4c76488 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 20 Jun 2013 21:14:57 +0200
Subject: [PATCH] ox-html: Use OPTIONS items instead of keywords for booleans
* lisp/ox-html.el (html): Replace "HTML_HTML5_FANCY",
"HTML_INCLUDE_STYLE" and "HTML_INCLUDE_SCRIPTS" with, respectively,
":html5-fancy", "html-style" and "html-scripts" options.
(org-html-html5-fancy): Reformat docstring.
* doc/org.texi (HTML doctypes): Reflect keyword removal.
(CSS support): Reflect keyword removal.
The reasoning behind this change is that keywords can only store
strings as value. Therefore, they are not suited for toggles ("nil"
vs nil) problem.
---
doc/org.texi| 8
lisp/ox-html.el | 11 +--
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index bddc518..3f7c9fb 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11055,7 +11055,7 @@ See the variable @code{org-html-doctype-alist} for details. The default is
HTML5 introduces several new element types. By default, Org will not make
use of these element types, but you can set @code{org-html-html5-fancy} to
-@code{t} (or use the corresponding @code{HTML_HTML5_FANCY} export option), to
+@code{t} (or set @code{html5-fancy} item in an @code{OPTIONS} line), to
enable a few new block-level elements. These are created using arbitrary
#+BEGIN and #+END blocks. For instance:
@@ -11352,9 +11352,9 @@ Each exported file contains a compact default style that defines these
classes in a basic way@footnote{This style is defined in the constant
@code{org-html-style-default}, which you should not modify. To turn
inclusion of these defaults off, customize
-@code{org-html-head-include-default-style} or set @code{#+HTML_INCLUDE_STYLE}
-to @code{nil} on a per-file basis.}. You may overwrite these settings, or add to
-them by using the variables @code{org-html-head} and
+@code{org-html-head-include-default-style} or set @code{html-style} to
+@code{nil} in an @code{OPTIONS} line.}. You may overwrite these settings, or
+add to them by using the variables @code{org-html-head} and
@code{org-html-head-extra}. You can override the global values of these
variables for each file by using these keywords:
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 90d6a5d..a996b40 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -116,7 +116,7 @@
(:html-link-org-as-html nil nil org-html-link-org-files-as-html)
(:html-doctype "HTML_DOCTYPE" nil org-html-doctype)
(:html-container "HTML_CONTAINER" nil org-html-container-element)
-(:html-html5-fancy "HTML_HTML5_FANCY" nil org-html-html5-fancy)
+(:html-html5-fancy nil "html5-fancy" org-html-html5-fancy)
(:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
(:html-link-up "HTML_LINK_UP" nil org-html-link-up)
(:html-mathjax "HTML_MATHJAX" nil "" space)
@@ -124,8 +124,8 @@
(:html-preamble nil "html-preamble" org-html-preamble)
(:html-head "HTML_HEAD" nil org-html-head newline)
(:html-head-extra "HTML_HEAD_EXTRA" nil org-html-head-extra newline)
-(:html-head-include-default-style "HTML_INCLUDE_STYLE" nil org-html-head-include-default-style newline)
-(:html-head-include-scripts "HTML_INCLUDE_SCRIPTS" nil org-html-head-include-scripts newline)
+(:html-head-include-default-style nil "html-style" org-html-head-include-default-style)
+(:html-head-include-scripts nil "html-scripts" org-html-head-include-scripts)
(:html-table-attributes nil nil org-html-table-default-attributes)
(:html-table-row-tags nil nil org-html-table-row-tags)
(:html-xml-declaration nil nil org-html-xml-declaration)
@@ -919,9 +919,8 @@ publishing, with :html-doctype."
:type 'string)
(defcustom org-html-html5-fancy nil
- "When exporting to HTML5, set this to t to use new HTML5
- elements. This variable is ignored for anything other than
- HTML5.
+ "Non-nil means using new HTML5 elements.
+This variable is ignored for anything other than HTML5 export.
For compatibility with Internet Explorer, it's probably a good
idea to download some form of the html5shiv (for instance
--
1.8.3.1
Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items
It seems reasonable to me. I also think it is good that you are using hyphen-separated human-readable identifiers like html-style instead of single-character identifiers. I wonder if it would be worth the backward incompatibility to make a:b syntax become :a b syntax to be consistent with Babel and backends, but presume we've already decided not to do so. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] orgstruct: broken global visibility cycling, when in comments
Thanks to Christopher Schmidt for solving my problem: On Fri, Jun 14, 2013 at 11:30 PM, Nathaniel Cunningham < nathaniel.cunning...@gmail.com> wrote: > I'm attempting to use orgstruct minor mode in emacs-lisp-mode (org 8.0.3 > in recent Aquamacs and in vanilla Emacs 24.3.1). I find: > - cycling an individual headline using tab key works fine > - global cycling via S-Tab (when on a headline) to more expanded > visibility (e.g. OVERVIEW --> CONTENTS or CONTENTS --> SHOW ALL) works fine > - global cycling via S-Tab (when on a headline) to more limited visibility > fails without error (echo area still reports OVERVIEW or CONTENTS, etc.) > > I have orgstruct-heading-prefix-regexp set to "^;;". > Note that this value for the prefix (actually the version with a space, "^;; ") is suggested by the Org manual for version 8.0.3 Christopher pointed out that "orgstruct-mode implicitly starts the real regexp that is used for headline matching with a ^. Your additional ^ breaks the regexp." I verify that setting orgstruct-heading-prefix-regexp to ";;" (or ";; " with a space) solves the problem. Thank you Christopher! --Nathaniel
[O] Bug: org-html-export-to-html is failing [8.0.3 (release_8.0.3-245-g5e3c3f-git @ org-loaddefs.el can not be found!)]
Today, when I try call to org-html-export-to-html, I find the next
error:
Wrong type argument: processp, nil
What could be failing?
I'm using the git version.
Emacs : GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
of 2013-01-20 on trouble, modified by Debian
Package: Org-mode version 8.0.3 (release_8.0.3-245-g5e3c3f-git @
org-loaddefs.el can not be found!)
current state:
==
(setq
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-latex-classes '(("beamer"
"\\documentclass[presentation]{beamer}\n
[DEFAULT-PACKAGES]\n [PACKAGES]\n [EXTRA]"
("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}"
. "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("article" "\\documentclass[11pt]{article}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("report" "\\documentclass[11pt]{report}" ("\\part{%s}" .
"\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}") ("\\section{%s}" .
"\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("book" "\\documentclass[11pt]{book}" ("\\part{%s}" .
"\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}") ("\\section{%s}" .
"\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-shell-link-function 'yes-or-no-p
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-from-is-user-regexp "\\"
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '((lambda nil
(org-add-hook (quote change-major-mode-hook) (quote
org-show-block-all) (quote append)
(quote local))
)
(lambda nil
(org-add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all)
(quote append) (quote local))
)
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-hide-inline-tasks
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-babel-load-languages '((emacs-lisp . t) (R . t))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-confirm-babel-evaluate nil
)
--
David Arroyo Menéndez
http://www.davidam.com
Re: [O] Bug: broken agenda view? [8.0.2 (8.0.2-dist @ /usr/share/emacs/site-lisp/org-mode/)]
kevinbanjo writes: > when given this file: > > * top level :@home: > > ** TODO next level :@town: > > * more top :@work: > > and doing C-cat I get this: > > Global list of TODO items of type: ALL > Available with `N r': (0)[ALL] > > Isn't that wrong? It shows NO todo items. > Did you see this: http://thread.gmane.org/gmane.emacs.orgmode/73666/focus=73667 ? -- Nick
Re: [O] Bug: org-html-export-to-html is failing [8.0.3 (release_8.0.3-245-g5e3c3f-git @ org-loaddefs.el can not be found!)]
davi...@es.gnu.org (David Arroyo Menéndez) writes: > Today, when I try call to org-html-export-to-html, I find the next > error: > > Wrong type argument: processp, nil > > What could be failing? > Please provide a backtrace - see (info "(org) Feedback") on how to create a useful backtrace. -- Nick
Re: [O] [RFC] Replace some HTML related keywords with OPTIONS items
Samuel Wales writes: > I wonder if it would be worth the backward incompatibility to make a:b > syntax become :a b syntax to be consistent with Babel and backends, > but presume we've already decided not to do so. Yes, I do think that this sort of consistency would be welcome. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
