Re: [O] ocaml babel no longer works?
Hello, I've been using this patch for the last few days and I have not found any issue with it. Can I apply it? Thanks, Alan Alan Schmitt writes: Hello, I'm resurrecting this old thread as I've made some progress but I still have questions. Eric Schulte writes: The suggestion: instead of appending 'org-babel-ocaml-eoe;;' to the code, how simply put ';;' (which will make sure everything is flushed) then detect the toplevel is done by seeing the string '# ' at the beginning of the line? Would there be an issue with the fact that this line does not have a newline? If so, an alternative suggestion would be to use the longer ';; org-babel-ocaml-eoe;;' which makes sure the phrase in the input won't interact with the marker. You can customize the `org-babel-ocaml-eoe-output' and `org-babel-ocaml-eoe-indicator' variables so that they match the above. If this proves generally useful then I'd be happy to admit this change to the core. I did this very tiny change and it makes interacting with the top-level much nicer as one can forget putting ';;'. Here is a tiny diff, which I can commit if you agree with the change. (As I've added other changes while writing this email, I attach a proper patch as well for all the changes.) , | diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el | index 6a83908..e5ad447 100644 | --- a/lisp/ob-ocaml.el | +++ b/lisp/ob-ocaml.el | @@ -63,7 +63,7 @@ | (session org-babel-ocaml-eoe-output t full-body) | (insert | (concat | - (org-babel-chomp full-body)\norg-babel-ocaml-eoe-indicator)) | + (org-babel-chomp full-body);;\norg-babel-ocaml-eoe-indicator)) | (tuareg-interactive-send-input))) | (clean | (car (let ((re (regexp-quote org-babel-ocaml-eoe-output)) out) ` The second feature request: I want to use this for my ocaml lab classes (I'm thinking of giving them an org file they have to complete by writing the caml code). Could it be possible to have an option for the full output of the compiler (and not just the result) to be printed? I see it does it when it does not recognize the type of the output. So I guess such an option would be applied to either org-babel-ocaml-parse-output or the place where it's called. I would think adding a :results verbatim header argument would suffice, but perhaps this is not the case. Unfortunately this does not seem to work. I've finally managed to understand how the code work, and here is a patch to solve this. The idea is that we do not trim the type information if verbatim is specified. , | @@ -74,10 +74,13 @@ | (progn (setq out t) nil |(mapcar #'org-babel-trim (reverse raw | (org-babel-reassemble-table | - (let ((raw (org-babel-trim clean))) | - (org-babel-result-cond (cdr (assoc :result-params params)) | -;; strip type information from output | -(if (string-match = \\(.+\\)$ raw) (match-string 1 raw) raw) | + (let ((raw (org-babel-trim clean)) | + (result-params (cdr (assoc :result-params params | + (org-babel-result-cond result-params | +;; strip type information from output unless verbatim is specified | +(if (and (not (member verbatim result-params)) | + (string-match = \\(.+\\)$ raw)) | +(match-string 1 raw) raw) | (org-babel-ocaml-parse-output raw))) | (org-babel-pick-name |(cdr (assoc :colname-names params)) (cdr (assoc :colnames params))) ` Finally I found a bug with `org-babel-ocaml-parse-output': if the type returned by the toplevel was something like int - int = fun, then the matching against int would be triggered, and the conversion of fun to an integer would result in 0. To solve this, I made the regexp more precise as the value returned by the toplevel is: (identifier | -) : type = value where the identifier cannot have the ':' character. Here is the corresponding diff: , | @@ -113,7 +116,7 @@ | (defun org-babel-ocaml-parse-output (output) |Parse OUTPUT. | OUTPUT is string output from an ocaml process. | - (let ((regexp %s = \\(.+\\)$)) | + (let ((regexp [^:]+ : %s = \\(.+\\)$)) | (cond | ((string-match (format regexp string) output) |(org-babel-read (match-string 1 output))) ` Hopefully this will be helpful. Alan
Re: [O] Patch for asynchronous export of ocaml code
Hello, Can I apply this patch? Thanks, Alan Alan Schmitt writes: Hello, It is not currently possible to asynchronously export the results of the evaluation an ocaml babel block because the evaluation needs to start a toplevel and thus asks the user what program to run. This of course blocks the asynchronous export. The attached patch adds a custom variable to specify the name of the command to run, and directly calls the tuareg function that starts the toplevel given the command.
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Michael Brand writes: Does it make sense to put at least repeatable %s, but then also multiple and repeatable parameters for link abbreviations to the wish list? Or did I miss something else that supports also org-open-at-point, maybe Org macros? When link abbreviations do not suffice, you can always write a link definition in Lisp and add it with org-add-link-type. For explanation and a practical example see: info:org#Adding%20hyperlink%20types Yours, Christian PS. If Org were to add a default geo: link type, I think it would make sense to keep the parameters to a minimum, i.e. just the latitude and longitude, without backend-dependent options such as Google Maps' spn parameter. Though I can see how it would be useful.
Re: [O] issues with export of LaTeX figure captions
Hi RJ, RJ Cunningham wrote: I've encountered an issue/difference with the way the recent babel processor handles captions. In versions prior to 8 the following WORKED (on export produced a figure environment with a caption): #+CAPTION: Fails to produce table environment and so caption in the new orgmode #+LABEL: fig:fails #+begin_src R :session :results graphics :file fails.pdf :exports results plot(1:10) #+end_src Side-remark: I find it weird, if not uncorrect, to have the header argument :session empty. IIRC, this is, at best, dangerous, because it could interpret what follows as its value. Under orgmode version 8.0.2 (8.0.2-2-g93da18-elpa the same code does not work, the includegraphics is exported sans the figure environment. Under this latest orgmode the following does work: #+begin_src R :session :results graphics :file ok.pdf :exports results plot(1:10) #+end_src #+CAPTION: Succeeds to produce table environment and so caption #+LABEL: fig:OK #+RESULTS[2d39a23f088d95e808bb867f97a0ecd2df621bbd]: [[file:ok.pdf]] However, this second construction of code has the following issues: 1. it is different to prior method which worked Yes, a lot of changes have been made in Org 8. This is for good, even if the switch can be somewhat painful. 2. it is ugly to have the caption sandwiched between the code and the results Not really. Please well think that there are two different beasts here: the code block and the results block. You can export both, and you could attach (different) captions to both. So, that does not seems that illogical to me. 3. often, but not always, when the code is re-executed the caption and label is lost Can you provide an ECM for this? I also see that HTML export also fails to produce a caption. Confirmed, in a 1-min test. Though, I had the impression that captions were handled in ox-html. To be further checked. Is this an issue in orgmode that can be addressed or is it an issue with my understanding? I must admit as much as I like org-babel I have long found the options for headers and arguments hard to understand well. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] export to various flavors of (X)HTML
Carsten Dominik carsten.domi...@gmail.com writes: Hi Eric, Rick, Francois and others, Nicolas commented to me about this patch that he was wondering if it would not be better to have a separate backend for html5, i.e. ox-html5.el that could be derived from ox-html.el and make it easier in the future to build it out to take full advantage of html5 features. I think he has a point, and I would like to hear your comments. My initial reaction is: yes, eventually, but perhaps not now. A few reasons: 1. This patch is already done, and it works, modulo bugfixes (not a great reason, I know). 2. The patch ended up with two predicate functions (org-html-xhtml-p and org-html-html5-p) because we really are dealing with four distinct states: X or not, and 5 or not. Splitting off ox-html5 only isolates one of those predicates: the X or not question would still have to be asked and answered in both ox-html and ox-html5. You could just as well split it the other way (ox-xhtml and ox-html), and have the X variants actually build a DOM tree and write xml (I'm not actually advocating that, but I just read this[1]). 3. The change to org-html-special-block takes care of the large majority of new html5 features. The change to inline-images is fairly small. Otherwise, there are many new inline elements that could be used, but in many cases browser support for these is limited or nonexistent, and even basic syntax is up in the air. They can wait (or be handled with custom link types). More importantly, the html5 version of, for example, the formatting of timestamps would look very like the (x)html(4) version, except that the final tag would be a bit different (time instead of span, with different attributes). Most of the surrounding logic would be the same. So ox-html5 would only override a few of ox-html's formatting functions, and even those few would largely be copy-n-paste from ox-html. I'm not sure that's worth it. (Unless derived backends could call back to their parent backends' implementations, a la OO inheritance? But that way lies madness.) To be clear, I think *something* more drastic should be done. But my feeling is: go with this patch for now. Then stop there. The next time someone feels the need to expand org's html5 capabilities, think about new backends. I'm happy to continue with the discussion, and the coding. I think part of the problem is HTML itself: as Rick's polyglot concerns show, the formats can be multiple things at once. Another part of the problem is that org has a certain take on HTML that I guess comes out of the early days of Unix documentation, when it really was the HyperText Markup Language: linked sets of static pages, with up/prev/next links, and headers and footers on each page. `org-html-divs' is a good example of this, and a perfect example of where html5 would handle things differently. I would argue that that should no longer be the default point of view on HTML. If we're going to rethink things, let's rethink this too. Eric [1] http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html On 2.5.2013, at 23:07, Eric Abrahamsen e...@ericabrahamsen.net wrote: Rick Frankel r...@rickster.com writes: On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote: Rick Frankel r...@rickster.com writes: Whoops. Wrong key. Patch actually attached to this email... rick Great, I'll consolidate all these -- would it be better to mush them into one big patch, or to keep them separate (I suppose for ease of rollback, if something goes wrong)? Probably squashing them into one patch would be the best. But Carsten or Bastien might disagree :). rick Okay, there it is: one big patch (including your xml declaration fix). I didn't add any more refined handling of the html5-fancy option. As a second-order option it didn't seem worthy of an #+OPTIONS entry, and I didn't bother checking for an empty string, either. It can always be #+BINDed if necessary, and if it ever annoys anyone I can fix it further. E 0001-ox-html.el-Export-to-different-X-HTML-flavors-includ.patch
Re: [O] [PATCH] export to various flavors of (X)HTML
Hi Eric, thanks for the reply. OK, I am going with the patch for now, let's push more thinking about HTML5 further down the line. Thanks for working this out! - Carsten On 6.5.2013, at 09:36, Eric Abrahamsen e...@ericabrahamsen.net wrote: Carsten Dominik carsten.domi...@gmail.com writes: Hi Eric, Rick, Francois and others, Nicolas commented to me about this patch that he was wondering if it would not be better to have a separate backend for html5, i.e. ox-html5.el that could be derived from ox-html.el and make it easier in the future to build it out to take full advantage of html5 features. I think he has a point, and I would like to hear your comments. My initial reaction is: yes, eventually, but perhaps not now. A few reasons: 1. This patch is already done, and it works, modulo bugfixes (not a great reason, I know). 2. The patch ended up with two predicate functions (org-html-xhtml-p and org-html-html5-p) because we really are dealing with four distinct states: X or not, and 5 or not. Splitting off ox-html5 only isolates one of those predicates: the X or not question would still have to be asked and answered in both ox-html and ox-html5. You could just as well split it the other way (ox-xhtml and ox-html), and have the X variants actually build a DOM tree and write xml (I'm not actually advocating that, but I just read this[1]). 3. The change to org-html-special-block takes care of the large majority of new html5 features. The change to inline-images is fairly small. Otherwise, there are many new inline elements that could be used, but in many cases browser support for these is limited or nonexistent, and even basic syntax is up in the air. They can wait (or be handled with custom link types). More importantly, the html5 version of, for example, the formatting of timestamps would look very like the (x)html(4) version, except that the final tag would be a bit different (time instead of span, with different attributes). Most of the surrounding logic would be the same. So ox-html5 would only override a few of ox-html's formatting functions, and even those few would largely be copy-n-paste from ox-html. I'm not sure that's worth it. (Unless derived backends could call back to their parent backends' implementations, a la OO inheritance? But that way lies madness.) To be clear, I think *something* more drastic should be done. But my feeling is: go with this patch for now. Then stop there. The next time someone feels the need to expand org's html5 capabilities, think about new backends. I'm happy to continue with the discussion, and the coding. I think part of the problem is HTML itself: as Rick's polyglot concerns show, the formats can be multiple things at once. Another part of the problem is that org has a certain take on HTML that I guess comes out of the early days of Unix documentation, when it really was the HyperText Markup Language: linked sets of static pages, with up/prev/next links, and headers and footers on each page. `org-html-divs' is a good example of this, and a perfect example of where html5 would handle things differently. I would argue that that should no longer be the default point of view on HTML. If we're going to rethink things, let's rethink this too. Eric [1] http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html On 2.5.2013, at 23:07, Eric Abrahamsen e...@ericabrahamsen.net wrote: Rick Frankel r...@rickster.com writes: On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote: Rick Frankel r...@rickster.com writes: Whoops. Wrong key. Patch actually attached to this email... rick Great, I'll consolidate all these -- would it be better to mush them into one big patch, or to keep them separate (I suppose for ease of rollback, if something goes wrong)? Probably squashing them into one patch would be the best. But Carsten or Bastien might disagree :). rick Okay, there it is: one big patch (including your xml declaration fix). I didn't add any more refined handling of the html5-fancy option. As a second-order option it didn't seem worthy of an #+OPTIONS entry, and I didn't bother checking for an empty string, either. It can always be #+BINDed if necessary, and if it ever annoys anyone I can fix it further. E 0001-ox-html.el-Export-to-different-X-HTML-flavors-includ.patch
Re: [O] org-preview-latex-fragment is very picky
rasmus == rasmus Rasmus writes: Uwe Brauer o...@mat.ucm.es writes: Probably not. Note these are Org features irrespective of fragment preview. There was some talk about it not so long ago. Basically, it just happens that $·$ works as desired most of the time. The proper way in LaTeX as well as in Org is \(·\). Often you'll find that in challenging cases you're better off with \(·\). To see whether $·$ will work I use (setq org-highlight-latex-and-related '(latex)) To have nice symbols making preview of fragments less dire I use pretty entities: (setq org-pretty-entities t) Pretty entities can also be turned on locally. For missing glyphs you're using you can do something like: (setq org-entities-user '((implies \\Rightarrow t rArr; = = ⇒) (iff \\iff t hArr; = = ⇔))) Hope this helps. Thanks for pointing out these settings, I will try them out. Uwe smime.p7s Description: S/MIME cryptographic signature
Re: [O] Export Org-mode content to Reveal.js presentations
Hi Yujie, Org-Reveal is now updated for displaying MathJax, as the HTML exporter does, except that the MathJax.org server is used instead of Orgmode.org server. Out of curiosity: why? Please check the updated sample illustration: http://naga-eda.org/home/yujie/org-reveal/#/4/4 That's so cool! I want to write a presentation now, but unfortunately I haven't got anything to present at the moment. I like this engine as lot 'cause of its battery included-ness. E.g. it just 'looks nice' and has the cool dimensional properties that Eric mentioned. Thanks again for this, it looks great! –Rasmus -- m-mm-mmm- bacon!
Re: [O] Export Org-mode content to Reveal.js presentations
On 6 mei 2013, at 10:36, Rasmus ras...@gmx.us wrote: Hi Yujie, Org-Reveal is now updated for displaying MathJax, as the HTML exporter does, except that the MathJax.org server is used instead of Orgmode.org server. Out of curiosity: why? I see that Mathjax now recommends use of its server. When we started using MathJax, they asked users to install their own versions, probably to limit server load on their side. But since they now recommend using their server network - maybe Org should use this by default? - Carsten Please check the updated sample illustration: http://naga-eda.org/home/yujie/org-reveal/#/4/4 That's so cool! I want to write a presentation now, but unfortunately I haven't got anything to present at the moment. I like this engine as lot 'cause of its battery included-ness. E.g. it just 'looks nice' and has the cool dimensional properties that Eric mentioned. Thanks again for this, it looks great! –Rasmus -- m-mm-mmm- bacon!
Re: [O] [PATCH] export to various flavors of (X)HTML
Carsten Dominik carsten.domi...@gmail.com writes: Hi Eric, thanks for the reply. OK, I am going with the patch for now, let's push more thinking about HTML5 further down the line. Thanks for working this out! My pleasure, I hope I haven't stifled debate... On 6.5.2013, at 09:36, Eric Abrahamsen e...@ericabrahamsen.net wrote: Carsten Dominik carsten.domi...@gmail.com writes: Hi Eric, Rick, Francois and others, Nicolas commented to me about this patch that he was wondering if it would not be better to have a separate backend for html5, i.e. ox-html5.el that could be derived from ox-html.el and make it easier in the future to build it out to take full advantage of html5 features. I think he has a point, and I would like to hear your comments. My initial reaction is: yes, eventually, but perhaps not now. A few reasons: 1. This patch is already done, and it works, modulo bugfixes (not a great reason, I know). 2. The patch ended up with two predicate functions (org-html-xhtml-p and org-html-html5-p) because we really are dealing with four distinct states: X or not, and 5 or not. Splitting off ox-html5 only isolates one of those predicates: the X or not question would still have to be asked and answered in both ox-html and ox-html5. You could just as well split it the other way (ox-xhtml and ox-html), and have the X variants actually build a DOM tree and write xml (I'm not actually advocating that, but I just read this[1]). 3. The change to org-html-special-block takes care of the large majority of new html5 features. The change to inline-images is fairly small. Otherwise, there are many new inline elements that could be used, but in many cases browser support for these is limited or nonexistent, and even basic syntax is up in the air. They can wait (or be handled with custom link types). More importantly, the html5 version of, for example, the formatting of timestamps would look very like the (x)html(4) version, except that the final tag would be a bit different (time instead of span, with different attributes). Most of the surrounding logic would be the same. So ox-html5 would only override a few of ox-html's formatting functions, and even those few would largely be copy-n-paste from ox-html. I'm not sure that's worth it. (Unless derived backends could call back to their parent backends' implementations, a la OO inheritance? But that way lies madness.) To be clear, I think *something* more drastic should be done. But my feeling is: go with this patch for now. Then stop there. The next time someone feels the need to expand org's html5 capabilities, think about new backends. I'm happy to continue with the discussion, and the coding. I think part of the problem is HTML itself: as Rick's polyglot concerns show, the formats can be multiple things at once. Another part of the problem is that org has a certain take on HTML that I guess comes out of the early days of Unix documentation, when it really was the HyperText Markup Language: linked sets of static pages, with up/prev/next links, and headers and footers on each page. `org-html-divs' is a good example of this, and a perfect example of where html5 would handle things differently. I would argue that that should no longer be the default point of view on HTML. If we're going to rethink things, let's rethink this too. Eric [1] http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html On 2.5.2013, at 23:07, Eric Abrahamsen e...@ericabrahamsen.net wrote: Rick Frankel r...@rickster.com writes: On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote: Rick Frankel r...@rickster.com writes: Whoops. Wrong key. Patch actually attached to this email... rick Great, I'll consolidate all these -- would it be better to mush them into one big patch, or to keep them separate (I suppose for ease of rollback, if something goes wrong)? Probably squashing them into one patch would be the best. But Carsten or Bastien might disagree :). rick Okay, there it is: one big patch (including your xml declaration fix). I didn't add any more refined handling of the html5-fancy option. As a second-order option it didn't seem worthy of an #+OPTIONS entry, and I didn't bother checking for an empty string, either. It can always be #+BINDed if necessary, and if it ever annoys anyone I can fix it further. E 0001-ox-html.el-Export-to-different-X-HTML-flavors-includ.patch
Re: [O] Export Org-mode content to Reveal.js presentations
Hi, Rasmus, 2013/5/6 Carsten Dominik carsten.domi...@gmail.com On 6 mei 2013, at 10:36, Rasmus ras...@gmx.us wrote: Hi Yujie, Org-Reveal is now updated for displaying MathJax, as the HTML exporter does, except that the MathJax.org server is used instead of Orgmode.org server. Out of curiosity: why? I see that Mathjax now recommends use of its server. When we started using MathJax, they asked users to install their own versions, probably to limit server load on their side. But since they now recommend using their server network - maybe Org should use this by default? - Carsten Yes, as explained by Carsten, MathJax encourage using their server, while Org discourage using theirs. so I switched to MathJax server. --yujie Please check the updated sample illustration: http://naga-eda.org/home/yujie/org-reveal/#/4/4 That's so cool! I want to write a presentation now, but unfortunately I haven't got anything to present at the moment. I like this engine as lot 'cause of its battery included-ness. E.g. it just 'looks nice' and has the cool dimensional properties that Eric mentioned. Thanks again for this, it looks great! Hope you enjoy it :) -yujie –Rasmus -- m-mm-mmm- bacon!
Re: [O] issues with export of LaTeX figure captions
Thanks for the reply Seb, Sebastien Vauban sva-n...@mygooglest.com writes: Hi RJ, RJ Cunningham wrote: I've encountered an issue/difference with the way the recent babel processor handles captions. In versions prior to 8 the following WORKED (on export produced a figure environment with a caption): #+CAPTION: Fails to produce table environment and so caption in the new orgmode #+LABEL: fig:fails #+begin_src R :session :results graphics :file fails.pdf :exports results plot(1:10) #+end_src Side-remark: I find it weird, if not uncorrect, to have the header argument :session empty. IIRC, this is, at best, dangerous, because it could interpret what follows as its value. I guess it could be dangerous, though it is convenient and I don't believe it has ever caused me any issues. I note that at one time, at least, a name was an optional argument for the :session header (see http://www.jstatsoft.org/v46/i03/paper p 10). I will consider being less weird though as you suggest. Under orgmode version 8.0.2 (8.0.2-2-g93da18-elpa the same code does not work, the includegraphics is exported sans the figure environment. Under this latest orgmode the following does work: #+begin_src R :session :results graphics :file ok.pdf :exports results plot(1:10) #+end_src #+CAPTION: Succeeds to produce table environment and so caption #+LABEL: fig:OK #+RESULTS[2d39a23f088d95e808bb867f97a0ecd2df621bbd]: [[file:ok.pdf]] However, this second construction of code has the following issues: 1. it is different to prior method which worked Yes, a lot of changes have been made in Org 8. This is for good, even if the switch can be somewhat painful. Indeed. 2. it is ugly to have the caption sandwiched between the code and the results Not really. Please well think that there are two different beasts here: the code block and the results block. You can export both, and you could attach (different) captions to both. So, that does not seems that illogical to me. OK, that is not something I have ever needed but I see that it would make sense in such a situation. Is there any way that I can export figures with captions WITHOUT having to execute the code and capture the results in the org file. With the previous construction the caption was added to the executed code results on export-so reducing the clutter in the org file by not having the results in the org file. 3. often, but not always, when the code is re-executed the caption and label is lost Can you provide an ECM for this? The problem seems to relate to :cache This gobbles up the caption and label. #+begin_src R :session :results graphics :file ok.pdf :exports results :cache yes plot(1:10, col=blue,cex=1) #+end_src #+CAPTION: Succeeds to produce table environment and so caption #+LABEL: fig:OK #+RESULTS: [[file:ok.pdf]] :cache no is fine Cheers, Robert
Re: [O] org-datetree-goto-date
On Sun, May 05, 2013 at 10:26:15PM -0400, Liam Healy wrote: I wanted a function that would take me to a particular date in a datetree and didn't find one, so I wrote my own and bound it to C-c d. (defun org-datetree-goto-date (optional siblings) [...chomp...chomp...chomp...] (org-reveal siblings)) This works beautifully! I have added a (beginning-of-line) at the end since I use a lot of the speed commands. Maybe this would be useful for others if included in org-mode. I would agree. Why don't you submit this as a patch to org-datetree.el? Thanks! -- Suvayu Open source is the future. It sets us free.
Re: [O] issues with export of LaTeX figure captions
Hi RJ, RJ Cunningham wrote: Sebastien Vauban sva-n...@mygooglest.com writes: RJ Cunningham wrote: I've encountered an issue/difference with the way the recent babel processor handles captions. In versions prior to 8 the following WORKED (on export produced a figure environment with a caption): #+CAPTION: Fails to produce table environment and so caption in the new orgmode #+LABEL: fig:fails #+begin_src R :session :results graphics :file fails.pdf :exports results plot(1:10) #+end_src Side-remark: I find it weird, if not uncorrect, to have the header argument :session empty. IIRC, this is, at best, dangerous, because it could interpret what follows as its value. I guess it could be dangerous, though it is convenient and I don't believe it has ever caused me any issues. I note that at one time, at least, a name was an optional argument for the :session header (see http://www.jstatsoft.org/v46/i03/paper p 10). I will consider being less weird though as you suggest. It never occurred to me that there could be a default name (see http://orgmode.org/manual/session.html#session), but OK, maybe. Anyway, I told you that because I once had the problem of the following header arg eaten as the option given to the previous one, though not with :session. Under orgmode version 8.0.2 (8.0.2-2-g93da18-elpa the same code does not work, the includegraphics is exported sans the figure environment. Under this latest orgmode the following does work: #+begin_src R :session :results graphics :file ok.pdf :exports results plot(1:10) #+end_src #+CAPTION: Succeeds to produce table environment and so caption #+LABEL: fig:OK #+RESULTS[2d39a23f088d95e808bb867f97a0ecd2df621bbd]: [[file:ok.pdf]] However, this second construction of code has the following issues [...]: 2. it is ugly to have the caption sandwiched between the code and the results Not really. Please well think that there are two different beasts here: the code block and the results block. You can export both, and you could attach (different) captions to both. So, that does not seems that illogical to me. OK, that is not something I have ever needed but I see that it would make sense in such a situation. We do agree. Is there any way that I can export figures with captions WITHOUT having to execute the code and capture the results in the org file. Once again, some question I never asked myself, always wanting to see at least as much as what will be exported. But I understand your question, and a possible good reason therefore (when the results is huge). With the previous construction the caption was added to the executed code results on export-so reducing the clutter in the org file by not having the results in the org file. Honestly, I don't know. I would have the impression that you can't, but I may be totally mislead... 3. often, but not always, when the code is re-executed the caption and label is lost Can you provide an ECM for this? The problem seems to relate to :cache This gobbles up the caption and label. If you did not execute the code block previously. Once pre-evaluated, your bug does not appear anymore -- that does not mean it's not a problem, though. #+begin_src R :session :results graphics :file ok.pdf :exports results :cache yes plot(1:10, col=blue,cex=1) #+end_src #+CAPTION: Succeeds to produce table environment and so caption #+LABEL: fig:OK #+RESULTS: [[file:ok.pdf]] :cache no is fine I don't have time right now to further try to understand and help you, but it really is strange. I confirm your saying about with or without cache, but had other strange behaviors trying to export (only one fig got exported when I had the two blocks). I can't commit on when, but I'll also try to better understand what happens here. Maybe others (Eric, Nicolas, Achim...) will come earlier with hints about this. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] export to various flavors of (X)HTML
On Mon, May 06, 2013 at 02:05:18AM -0700, Eric Abrahamsen wrote: Carsten Dominik carsten.domi...@gmail.com writes: Hi Eric, thanks for the reply. OK, I am going with the patch for now, let's push more thinking about HTML5 further down the line. Thanks for working this out! My pleasure, I hope I haven't stifled debate... No you haven't. Rather, you have described my position much better than i could. +1 My additional 2 cents. For me, xhtml and polyglot html5 (xhtml masquerading as html5) are my primary output. html4 (with its sgml derived unclosed tags) is the anomaly. Going forward i could see something like: ox-html-base (incomplete backend) | | | ox-html4ox-xhtml(5) | ox-html5-fancy (with the html5 specific tags) rick
[O] latex export of words starting with a superscript
Dear list,
this is my first time posting here so: thanks for all the work on
org-mode! I like the new changes (although the new variable names were a
pain).
This is either a feature request, a complaint or a demonstration of my
lack of knowledge of org-mode.
When export latex of words starting with a superscript or subscript, the
caret or underscore is escaped unless preceded with something other than
a space, such that I have to use \space^{14}C for a carbon radioisotope.
I do not need this when when exporting to html.
Org-mode version 8.0.1 (8.0.1-6-ge6776c-elpa @
/home/onb134/.emacs.d/elpa/org-20130422/)
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2013-04-14 on chindi10, modified by Debian
I like things to be controlled and set:
(setq org-use-sub-superscripts {})
but it doesn't make a difference whether this is set or not.
It would be nice if this could be implemented, but I am aware of the
difficulties/conflicts given that underlining needs a word to start with
_. Maybe some nice regexp work.
Thanks!
Brian
[O] OT: Annotating PDF Org
Given the emacs and Org oriented nature of this group, I'd like to know if anyone has found a good Orgish (ie: portable, text, etc) to annotate PDFs? Features would be items like highlighting blocks, adding notes (margins or sticky notes), and saving to either a sidecar file in a text format (ala Org) or directly appending the PDF. Thanks. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [O] OT: Annotating PDF Org
Given the emacs and Org oriented nature of this group, I'd like to know if anyone has found a good Orgish (ie: portable, text, etc) to annotate PDFs? Features would be items like highlighting blocks, adding notes (margins or sticky notes), and saving to either a sidecar file in a text format (ala Org) or directly appending the PDF. Not portable probably, but Skim (a very nice PDF viewer for Mac OS X) supports notes in an xml file next to the PDF, and something like this would make sense in a more general setting. Maybe using the same spec to be compatible? (Skim can then reexport everything as a single PDF file if needed, but a nice use-case for what you suggest would be something like personal org-mode reading notes on an article for which keeping them separate would make more sense.) /v -- Vincent Beffara
Re: [O] OT: Annotating PDF Org
On Mon, May 06, 2013 at 03:53:05PM +0200, Vincent Beffara wrote: Not portable probably, but Skim (a very nice PDF viewer for Mac OS X) supports notes in an xml file next to the PDF, and something like this would make sense in a more general setting. Maybe using the same spec to be compatible? (Skim can then reexport everything as a single PDF file if needed, but a nice use-case for what you suggest would be something like personal org-mode reading notes on an article for which keeping them separate would make more sense.) An excellent suggestion! I am on Linux, but I wasn't specific about platform because I was hoping to see how other tools worked across different platforms. I'll go read up on it. Thanks. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
[O] Bibliography
Is it me or is it normal that the:
#+Bibliography: foo plain
line is not exported by the LaTeX backend?
I assume that:
\bibliography{foo}
\bibliographystyle{plain}
is a decent way to handle it.
Thanks for any comment.
--
Fabrice
[O] PATCH: Habit consistency always show DONE days green option
I had always disliked how if you miss a habit deadline and then go on a several day streak, first day still show up red. Makes it hard to visually see green streaks Following patch adds a new variable `org-habit-show-done-always-green' to fix that. It defaults to off, if enough people like it we can make it new default. To illustrate the difference in display, try to count number of two day streaks in below screen-shots. Current display: http://i.imgur.com/HlyXE2o.png With new option: http://i.imgur.com/3ZmImkP.png Note that no information is lost, you can still figure out if streak started after missing a deadline, by color of the previous day. Regards, Max From 5c7f9b63b6021631b19b883760340a18024e6344 Mon Sep 17 00:00:00 2001 From: Max Mikhanosha m...@openchat.com Date: Mon, 6 May 2013 09:26:10 -0400 Subject: [PATCH] Add option to always show DONE days as green on consistency graph. It can be enabled by setting `org-habit-show-done-alwyays-green' variable to t. * lisp/org-habit.el (org-habit-get-faces): Add show done days green option --- lisp/org-habit.el | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lisp/org-habit.el b/lisp/org-habit.el index 8465ba4..0899f45 100644 --- a/lisp/org-habit.el +++ b/lisp/org-habit.el @@ -85,6 +85,12 @@ (defcustom org-habit-completed-glyph ?* :version 24.1 :type 'character) +(defcustom org-habit-show-done-always-green nil + If non-nil, a DONE day will always be green in consistency +graph, even if it was done after deadline + :group 'org-habit + :type 'boolean) + (defface org-habit-clear-face 'background light)) (:background #8270f9)) (((background dark)) (:background blue))) @@ -272,8 +278,9 @@ (defun org-habit-get-faces (habit optional now-days scheduled-days donep) (if donep '(org-habit-ready-face . org-habit-ready-future-face) '(org-habit-alert-face . org-habit-alert-future-face))) - (t - '(org-habit-overdue-face . org-habit-overdue-future-face) + ((and org-habit-show-done-always-green donep) + '(org-habit-ready-face . org-habit-ready-future-face)) + (t '(org-habit-overdue-face . org-habit-overdue-future-face) (defun org-habit-build-graph (habit starting current ending) Build a graph for the given HABIT, from STARTING to ENDING. -- 1.7.11.rc0.100.g5498c5f
Re: [O] Bibliography
On Mon, May 06, 2013 at 04:26:16PM +0200, Fabrice Popineau wrote:
Is it me or is it normal that the:
#+Bibliography: foo plain
line is not exported by the LaTeX backend?
I assume that:
\bibliography{foo}
\bibliographystyle{plain}
is a decent way to handle it.
Sometime back there was talk about integrating bibliography in the Org
syntax. That would make it backend agnostic (always a goal with most
Org features). If you are interested, take a look at the following
thread.
http://thread.gmane.org/gmane.emacs.orgmode/67488/focus=67521
--
Suvayu
Open source is the future. It sets us free.
Re: [O] How to ensure code blocks are run during export?
Alan Schmitt alan.schm...@polytechnique.org writes: Hi Sebastien, Sebastien Vauban writes: I don't know OCaml at all, so I cannot try your example locally on my machine. And I don't know about other languages that support sessions, unfortunately. I can see something similar using haskell, if that helps: --8---cut here---start-8--- # -*- org-confirm-babel-evaluate: nil -*- Setting the stage #+BEGIN_SRC haskell :results code verbatim :exports results let f = (+1) f 1 #+END_SRC Using the function #+BEGIN_SRC haskell :results code verbatim :exports results f 3 #+END_SRC Setting another stage #+BEGIN_SRC haskell :results silent :exports none let g = (+1) g 1 #+END_SRC Using the second function #+BEGIN_SRC haskell :results code verbatim :exports results g 3 #+END_SRC --8---cut here---end---8--- Though, you speak of session: where is your session header argument? Isn't that the problem? There is a default session for Caml code, so one does not need this argument. In my example, the function f is declared in one block and successfully used in the second. The function g is declared in a third (silent) block, and results in an error when we try to call it in the fourth and final block. Does this demonstrate the default session that Alan mentioned? G
Re: [O] Exporting large documents
[Reintroducing org mailing list CC] On 05/05/2013 20:21, Nicolas Goaziou wrote: Carsten Dominik carsten.domi...@gmail.com writes: I don't think there's much to do about that. Though, some tools could benefit from caching, like Lawrence did for `org-export-resolve-fuzzy-link'. Could you point out specific ones where it would make sense? Maybe someone would like to take this up as a task. It requires some careful benchmarking. Though, good candidates are tools searching for an object or element within the full parse tree. This includes: - org-export-footnote-first-reference-p - org-export-get-footnote-number - org-export-get-category - org-export-resolve-coderef - org-export-resolve-radio-link - org-export-get-loc - org-export-get-ordinal I wonder if it would be possible to store a copy of the parse tree in a form that is more amenable to log or constant time searches. However, I note that my caching of the fuzzy link stuff brought the quadratic time export of copies of the org manual introduction down to linear (or close to) time. Most of the problem now seems to be that for big documents, many functions are called a /lot/. For example: org-element--current-element takes (on my machine) 0.0003 seconds per call. However, when exporting 128x the orgmanual introduction, it's called around 25 times giving ~ 80 seconds total time (out of ~200 total). So it sort of feels like actually what is needed is microoptimisations of the bits of the export engine that are called the most. Lawrence -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
[O] Image #s and captions missing in Org 8 Latex Export
Hey all,
I've just upgraded to org 8 (from 7.9) and am running into an issue with my
latex export. I can't get captions to show up on the results of a code
block evaluation, or reference those results with, for example
[[fig:graph]]:
#+caption: Graphviz Example
#+name: fig:graph
#+BEGIN_SRC dot :exports results :file graph.png :eval yes :cmdline -Kdot
-Tpng
digraph data_relationships {
org-mode
org-exp-blocks
dot
ditaa
HTML [shape=Mrecord, label={HTML|publish on the web\l}]
LaTeX [shape=Mrecord, label={LaTeX|publish in PDF\l}]
org-mode - org-exp-blocks
dot - org-mode
ditaa - org-mode
org-exp-blocks - HTML
org-exp-blocks - LaTeX
}
(+ 2 2)
#+END_SRC
Captions and internal links to actual code listings are working great:
#+caption: Hello, World in Clojure
#+name: fig:hello
#+BEGIN_SRC clojure :exports code :eval no
(println Hello, World!)
#+END_SRC
[[fig:hello]] resolves to 1, as expected, and the caption shows up in
HTML export and in the Latex export as Figure 1: Hello, World in Clojure.
In org 7.9, my captions resolved on the png results but would never show up
on code exports. Is there some option flag I need to enable to generate
refs for embedded PNGs?
Thanks!
Sam
--
Sam Ritchie, Twitter Inc
703.662.1337
@sritchie
(Too brief? Here's why! http://emailcharter.org)
Re: [O] odd behavior for begin_src org :results
Sebastien Vauban sva-n...@mygooglest.com writes: Hello Greg, Greg Minshall wrote: It appears that only *string* values are allowed for any :var that are defined (i.e., ':var bar=foo', and *not* ':var bar=3'). Confirmed. The following does not work. #+begin_src org :results drawer replace :var you=2 Hello $you #+end_src since i'm not 100% sure of the semantics, maybe this is desired. I dunno either. Clearly, an error should not happen. OTOH, there is no concept of Org variable, so every variable here comes down to be implemented as a simple string replacement, hence the need for strings only, maybe. I've applied a simple fix which will allow any type of object to be inserted into an Org-mode code block. Although there is a great deal of potential for more sophisticated behavior here, hopefully this simple solution will suffice. Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] How to ensure code blocks are run during export?
Alan Schmitt alan.schm...@polytechnique.org writes: Hello, I'm writing an exam in org mode, and it's going really well. I need to have some code in code blocks being run during export (as it's defining some functions for later questions), but I don't want anything to be displayed in the final document. At the moment I use the following options in the block: :results silent :exports results Is it the correct way to do it? Thanks, Alan Yes, this is the correct combination of header arguments for this use case. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] using gnuplot's splot and every commands on org-mode table data
Paul Stansell paulstans...@gmail.com writes: Hello everyone, I'd be grateful if someone would offer me advice on using gnuplot's splot and every commands when plotting data from a table within org-mode. As far as I can tell, these gnuplot commands do not work properly because org-mode exports empty fields in tables as and gnuplot's every and splot commands expect the data file to be formatted as a datablock with blank lines marking the boundaries between datablocks. (For the definition of a datablock, type help glossary at the gnuplot prompt.) I'm using org-mode version 8.0.2 and emacs version 24.2.1 on a Fedora-18 system To illustrate my point, consider a blocked datafile called block.dat containing the following: 1 1 2 1 2 5 1 3 10 2 1 5 2 2 8 2 3 13 3 1 10 3 2 13 3 3 18 For this file the gnuplot command #+begin_src gnuplot :var d=block.dat :results silent plot $d u 2:3 ev :::0::0, u 2:3 ev :::1::1, u 2:3 ev :::2::2 #+end_src shows three separate lines of different colours as gnuplot recognises the datafile as blocked data. Also, the following command produces a surface plot #+begin_src gnuplot :var d=block.dat :results silent splot $d u 1:2:3 #+end_src However, if I put the same data in the table below #+tblname: data | 1 | 1 | 2 | | 1 | 2 | 5 | | 1 | 3 | 10 | | | || | 2 | 1 | 5 | | 2 | 2 | 8 | | 2 | 3 | 13 | | | || | 3 | 1 | 10 | | 3 | 2 | 13 | | 3 | 3 | 18 | and use the following plot command #+begin_src gnuplot :var d=data :results silent plot $d u 2:3 ev :::0::0, u 2:3 ev :::1::1, u 2:3 ev :::2::2 #+end_src the result is a plot of a single line of the same colour as gnuplot joins all of the points in the data file. This seems to be because org-mode exports the table as x y z 1 1 2 1 2 5 1 3 10 2 1 5 2 2 8 2 3 13 3 1 10 3 2 13 3 3 18 and gnuplot does not recognise this as a blocked data file because it contains no blank lines. The same problem occurs for #+begin_src gnuplot :var d=data :results silent splot $d u 1:2:3 #+end_src which does not produce a gridded surface plot. Thanks for your help, Hi Paul, While I can't claim to fully follow your gnuplot examples, i would recommend using an intervening shell code block to parse the Org-mode table data into something that gnuplot will ingest. If I understand your use case correctly, then something like the following should work. #+name: data | 1 | 1 | 2 | | 1 | 2 | 5 | | 1 | 3 | 10 | | | || | 2 | 1 | 5 | | 2 | 2 | 8 | | 2 | 3 | 13 | | | || | 3 | 1 | 10 | | 3 | 2 | 13 | | 3 | 3 | 18 | #+name: clean #+begin_src sh :var data=data :results file :file /tmp/data.gnuplot echo $data /tmp/data.gnuplot #+end_src #+begin_src gnuplot :var data=clean(data) :results silent splot $data u 1:2:3 #+end_src If you really wanted to be fancy, gnuplot will let you specify shell transformations as part of the plotting command which would allow you to forego the intermediate code block. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Bug in structmode++?
Nicolas Goaziou n.goaz...@gmail.com writes: Igor Sosa Mayor joseleopoldo1...@gmail.com writes: Thanks Nicolas. At least, I dont feel alone anymore... Is there any chance this getting fixed somehow? I used to use it very often in my emails and I miss it. I miss it, too. I didn't follow recent changes to orgstruct-mode, so I cannot help here. I hope that someone more knowledgeable than I am will jump in. orgstruct(++)-mode used to set auto-fill-function to 'org-auto-fill-function. This behaviour is too intrusive so we removed it. You either need to indent secondary lines by hand or set auto-fill-function back to org-auto-fill-function. orgstruct++'s hijacker of org-insert-heading-respect-content did not respect item bodies. I fixed this in master a few minutes ago. 741bc5c * origin/master master org.el: Execute org-insert-heading and org-insert-heading-respect-content in orgstruct++-mode when the context around point is an item-body. Christopher
Re: [O] Bibliography
Sure, I remember this thread and it is clear that the problem is very
different when it is for LaTeX of for and HTML backend.
However, Reftex is provided with Emacs, and it is also integrated to Org
mode.
So I was trying to solve my simple problem about the bibliography keyword
this way:
(defadvice org-latex-keyword (around org-latex-keyword-bibliography)
Exports `bibliography' keyword with LaTeX backend.
(let ((key (org-element-property :key (ad-get-arg 0)))
(value (org-element-property :value (ad-get-arg 0
(if (and (string= key BIBLIOGRAPHY)
(string-match \\(\\S-+\\)[ \t]+\\(\\S-+\\)\\([^\r\n]*\\)
value))
(let ((bibfile (match-string 1 value))
(bibstyle (match-string 2 value)))
(format \\bibliography{%s}\n\\bibliographystyle{%s} bibfile
bibstyle))
ad-do-it)))
(ad-activate 'org-latex-keyword)
in my personal Org mode setup. However, it does not work. The advice is
called and returns the string,
but somehow it is not inserted in the buffer. If I do the same thing in
ox-latex.el:org-latex-keyword function,
it does work. Any idea why ?
Fabrice
2013/5/6 Suvayu Ali fatkasuvayu+li...@gmail.com
On Mon, May 06, 2013 at 04:26:16PM +0200, Fabrice Popineau wrote:
Is it me or is it normal that the:
#+Bibliography: foo plain
line is not exported by the LaTeX backend?
I assume that:
\bibliography{foo}
\bibliographystyle{plain}
is a decent way to handle it.
Sometime back there was talk about integrating bibliography in the Org
syntax. That would make it backend agnostic (always a goal with most
Org features). If you are interested, take a look at the following
thread.
http://thread.gmane.org/gmane.emacs.orgmode/67488/focus=67521
--
Suvayu
Open source is the future. It sets us free.
--
Fabrice Popineau
-
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
--
Re: [O] Patch for asynchronous export of ocaml code
This looks great, please apply this patch. Thanks, Alan Schmitt alan.schm...@polytechnique.org writes: Hello, It is not currently possible to asynchronously export the results of the evaluation an ocaml babel block because the evaluation needs to start a toplevel and thus asks the user what program to run. This of course blocks the asynchronous export. The attached patch adds a custom variable to specify the name of the command to run, and directly calls the tuareg function that starts the toplevel given the command. For some context, here is the code that starts the caml session. #+BEGIN_SRC emacs-lisp (defvar tuareg-interactive-buffer-name) (defun org-babel-prep-session:ocaml (session params) Prepare SESSION according to the header arguments in PARAMS. (require 'tuareg) (let ((tuareg-interactive-buffer-name (if (and (not (string= session none)) (not (string= session default)) (stringp session)) session tuareg-interactive-buffer-name))) (save-window-excursion (if (fboundp 'tuareg-run-caml) (tuareg-run-caml) (tuareg-run-ocaml)) (get-buffer tuareg-interactive-buffer-name #+END_SRC And this is the code from tuareg that is run. #+BEGIN_SRC emacs-lisp ;;;###autoload (defun tuareg-run-ocaml () Run an OCaml toplevel process. I/O via buffer `*ocaml-toplevel*'. (interactive) (tuareg-run-process-if-needed) (display-buffer tuareg-interactive-buffer-name)) (defun tuareg-run-process-if-needed (optional cmd) Run an OCaml toplevel process if needed, with an optional command name. I/O via buffer `*ocaml-toplevel*'. (if cmd (setq tuareg-interactive-program cmd) (unless (comint-check-proc tuareg-interactive-buffer-name) (setq tuareg-interactive-program (read-shell-command OCaml toplevel to run: tuareg-interactive-program (unless (comint-check-proc tuareg-interactive-buffer-name) (let ((cmdlist (tuareg-args-to-list tuareg-interactive-program)) (process-connection-type nil)) (set-buffer (apply (function make-comint) ocaml-toplevel (car cmdlist) nil (cdr cmdlist))) (tuareg-interactive-mode) (sleep-for 1 #+END_SRC With this patch (and setting `org-confirm-babel-evaluate' to nil), I'm able to export documents requiring the evaluation of caml code asynchronously. Alan -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Exporting large documents
Lawrence Mitchell wrote: [...] And here's the profile for exporting the whole of orgmanual.org to latex. You can see that a lot of the time comes from quite cheap functions that are called lots. org-latex-export-as-latex 1 415.52740777 415.52740777 org-export-to-buffer 1 414.89446185 414.89446185 org-export-as 1 414.89314727 414.89314727 org-entry-get 362909 377.15499961 0.0010392550 org-export-execute-babel-code 1 248.09360062 248.09360062 org-babel-exp-process-buffer 1 248.08328800 248.08328800 org-babel-exp-src-block137 243.10403972 1.7744820417 org-export-data33704 241.13159257 0.0071543909 org-babel-get-src-block-info 3811241.06197704 0.0632542579 org-babel-parse-src-block-match3811239.00537768 0.0627146097 org-babel-exp-do-export137 238.11539604 1.7380685842 org-babel-exp-code 137 237.68002300 1.7348906788 org-babel-expand-noweb-references 24 237.62374387 9.9009893283 org-babel-params-from-properties 3811237.29706205 0.0622663505 org-entry-get-with-inheritance 99086 234.87738424 0.0023704396 org-get-property-block 322856 121.21322218 0.0003754405 org-macro-replace-all 2 112.94112931 56.470564655 org-element-context8588107.43778316 0.0125102216 org-element-at-point 8976101.79823538 0.0113411581 org-element--current-element 236519 91.414278451 0.0003864986 org-up-heading-safe263822 84.507423221 0.0003203198 org-element--parse-elements311340.774293673 0.0130980705 org-back-to-heading1209279 40.394825581 3.340...e-05 org-element-headline-parser59033 32.808386543 0.0005557634 org-before-first-heading-p 272799 32.791086826 0.0001202023 org-list-struct803520.801415973 0.0025888507 org-element-map19598 20.466600874 0.0010443208 org-latex-link 341 19.91215084 0.0583934042 org-export-resolve-fuzzy-link 281 19.879402747 0.0707452055 ... Functions taking less than 15 seconds cumulative time elided. -- Lawrence Mitchell we...@gmx.li
Re: [O] ocaml babel no longer works?
Alan Schmitt alan.schm...@polytechnique.org writes: Hello, I'm resurrecting this old thread as I've made some progress but I still have questions. Eric Schulte writes: The suggestion: instead of appending 'org-babel-ocaml-eoe;;' to the code, how simply put ';;' (which will make sure everything is flushed) then detect the toplevel is done by seeing the string '# ' at the beginning of the line? Would there be an issue with the fact that this line does not have a newline? If so, an alternative suggestion would be to use the longer ';; org-babel-ocaml-eoe;;' which makes sure the phrase in the input won't interact with the marker. You can customize the `org-babel-ocaml-eoe-output' and `org-babel-ocaml-eoe-indicator' variables so that they match the above. If this proves generally useful then I'd be happy to admit this change to the core. I did this very tiny change and it makes interacting with the top-level much nicer as one can forget putting ';;'. Here is a tiny diff, which I can commit if you agree with the change. (As I've added other changes while writing this email, I attach a proper patch as well for all the changes.) , | diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el | index 6a83908..e5ad447 100644 | --- a/lisp/ob-ocaml.el | +++ b/lisp/ob-ocaml.el | @@ -63,7 +63,7 @@ | (session org-babel-ocaml-eoe-output t full-body) | (insert | (concat | - (org-babel-chomp full-body)\norg-babel-ocaml-eoe-indicator)) | + (org-babel-chomp full-body);;\norg-babel-ocaml-eoe-indicator)) | (tuareg-interactive-send-input))) | (clean | (car (let ((re (regexp-quote org-babel-ocaml-eoe-output)) out) ` The second feature request: I want to use this for my ocaml lab classes (I'm thinking of giving them an org file they have to complete by writing the caml code). Could it be possible to have an option for the full output of the compiler (and not just the result) to be printed? I see it does it when it does not recognize the type of the output. So I guess such an option would be applied to either org-babel-ocaml-parse-output or the place where it's called. I would think adding a :results verbatim header argument would suffice, but perhaps this is not the case. Unfortunately this does not seem to work. I've finally managed to understand how the code work, and here is a patch to solve this. The idea is that we do not trim the type information if verbatim is specified. , | @@ -74,10 +74,13 @@ | (progn (setq out t) nil |(mapcar #'org-babel-trim (reverse raw | (org-babel-reassemble-table | - (let ((raw (org-babel-trim clean))) | - (org-babel-result-cond (cdr (assoc :result-params params)) | -;; strip type information from output | -(if (string-match = \\(.+\\)$ raw) (match-string 1 raw) raw) | + (let ((raw (org-babel-trim clean)) | + (result-params (cdr (assoc :result-params params | + (org-babel-result-cond result-params | +;; strip type information from output unless verbatim is specified | +(if (and (not (member verbatim result-params)) | + (string-match = \\(.+\\)$ raw)) | +(match-string 1 raw) raw) | (org-babel-ocaml-parse-output raw))) | (org-babel-pick-name |(cdr (assoc :colname-names params)) (cdr (assoc :colnames params))) ` Finally I found a bug with `org-babel-ocaml-parse-output': if the type returned by the toplevel was something like int - int = fun, then the matching against int would be triggered, and the conversion of fun to an integer would result in 0. To solve this, I made the regexp more precise as the value returned by the toplevel is: (identifier | -) : type = value where the identifier cannot have the ':' character. Here is the corresponding diff: , | @@ -113,7 +116,7 @@ | (defun org-babel-ocaml-parse-output (output) |Parse OUTPUT. | OUTPUT is string output from an ocaml process. | - (let ((regexp %s = \\(.+\\)$)) | + (let ((regexp [^:]+ : %s = \\(.+\\)$)) | (cond | ((string-match (format regexp string) output) |(org-babel-read (match-string 1 output))) ` Hopefully this will be helpful. Hi Alan, I think each of these patches in an improvement over the existing behavior. Please do apply them all. Thanks! Alan -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] new (iCalendar) exporter problem
Hi Nicolas, I seem to have overssen something: #+filetags: drawnin #+icalendar_exclude_tags: drawnin noexport #+bind: org-icalendar-categories (all-tags) * Test (no tag here - 2013-05-05 Sun Desc That one indeed exports, but IMO shouldn't. exclude tags are not inherited. You mean inherited tags (coming from filetags in this case) do not contribute to exclude tag filtering? If yes, why? I seems inconsistent. Cheers, Simon
[O] Question about org-plus-contrib elpa
According to http://orgmode.org/elpa.html the org-plus-contrib package has all the files in the /contrib directory but it looks like it's only grabbing the files that begin with org-. None of the ox- or ob- are in the repo. Looks like this line in servers.mk is the culprit: elpaplus-dirty elpaplus-up: ORG_ADD_CONTRIB=org-* Is this an oversight or by design? Thanks.
Re: [O] Exporting large documents
Lawrence Mitchell writes: org-element--current-element takes (on my machine) 0.0003 seconds per call. However, when exporting 128x the orgmanual introduction, it's called around 25 times giving ~ 80 seconds total time (out of ~200 total). I've traced this a bit and the question does warrant further investigation. Exporting the introduction without any duplications already shows some interesting things: the property drawer for the introduction is scanned a whopping 137 times, followed by 134 times the cindex entry following it, followed by 125 times the Summary headline. The header options feature prominently with around 100 scans each as well. The rest of the calls have mostly just a single invocation, but there are some instances where parts of the tree are traversed multiple times in succession to apparently adjust the :end property to the leaf element in small increments or decrements. If elements are mutable during parsing then caching is more difficult as well, obviously. So it sort of feels like actually what is needed is microoptimisations of the bits of the export engine that are called the most. Looking at the traces I'd think if we could eliminate the repeated backtracking to adjust the leafs or at least skip over those elements in a backtrack that are already fully parsed instead of parsing them again, that would be a good start. 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] link abbreviation with multiple params, e. g. for geo locations
On Mon, May 6, 2013 at 9:06 AM, Christian Moe m...@christianmoe.com wrote: PS. If Org were to add a default geo: link type, I think it would make sense to keep the parameters to a minimum, i.e. just the latitude and longitude, without backend-dependent options such as Google Maps' spn parameter. Though I can see how it would be useful. Good point, agreed. So what I am trying to do is less about a link type geo location but more about possibly having several different visualizations of one single geo location. When link abbreviations do not suffice, you can always write a link definition in Lisp and add it with org-add-link-type. Thinking about this and my previous post I conclude that Org babel is just perfect for my use case. Well, as a beginner of Org babel I am not yet there completely and would like to ask for help on the source block header: * Org babel function for Google Maps browser #+NAME: gmb #+HEADER: :var ty=m spn=0.2 #+HEADER: :var geo_var=(or (org-entry-get nil geo) 4.56,7.89) #+BEGIN_SRC emacs-lisp :results silent (browse-url (concat http://maps.google.ch/maps?t=; ty spn= (number-to-string spn) , (number-to-string spn) ll= geo_var q= geo_var)) #+END_SRC * example of a geo location, realistic to try out :PROPERTIES: :geo: 4.56,7.89 :END: - call_gmb() - interactively (type C-c on call_gmb) visualize the current geo location on Google Maps with a marker and as map in the browser - call_gmb(ty=k, spn=0.002) - visualize the same geo location on Google Maps with a marker, as satellite image and with a certain scale suitable for this specific geo location and view type * another geo location :PROPERTIES: :geo: 4.44,5.55 :END: - call_gmb(ty=p) - visualize another geo location as terrain The issue is that org-entry-get returns nil instead of the value of the item property :geo:, therefore my demo workaround with the or to show the principle of gmb. How to resolve this properly? Isn't there something like #+HEADER: :var geo_var=:geo: to copy the value of the item property :geo: to the babel variable unless specified by the caller? Not sure yet how to support export of such geo locations to a GPS track... That would probably be simply all item properties :geo: with the item's name and nothing else. Probably quite a boring exercise of writing a new exporter backend for someone who would know how to do it... Btw. I re-found the Org mode mailing list thread [2010-06-29 Tue] Getting a Google Maps' map for an entry http://thread.gmane.org/gmane.emacs.orgmode/26797 by Julien Danjou, currently to be found at http://julien.danjou.info/projects/emacs-packages#google-maps It can also be used as a backend to visualize a geo location and demonstrates the usage of the interesting Google Maps Static Maps API that converts a Google Maps URL to an image: https://developers.google.com/maps/documentation/staticmaps/#quick_example Michael
Re: [O] Bibliography
Hello,
Fabrice Popineau fabrice.popin...@supelec.fr writes:
Sure, I remember this thread and it is clear that the problem is very
different when it is for LaTeX of for and HTML backend.
However, Reftex is provided with Emacs, and it is also integrated to Org
mode.
Since it is back-end dependent, why don't you use:
#+latex: \bibliography{...}\bibilographystyle{...}
instead?
So I was trying to solve my simple problem about the bibliography keyword
this way:
(defadvice org-latex-keyword (around org-latex-keyword-bibliography)
Exports `bibliography' keyword with LaTeX backend.
(let ((key (org-element-property :key (ad-get-arg 0)))
(value (org-element-property :value (ad-get-arg 0
(if (and (string= key BIBLIOGRAPHY)
(string-match \\(\\S-+\\)[ \t]+\\(\\S-+\\)\\([^\r\n]*\\)
value))
(let ((bibfile (match-string 1 value))
(bibstyle (match-string 2 value)))
(format \\bibliography{%s}\n\\bibliographystyle{%s} bibfile
bibstyle))
ad-do-it)))
(ad-activate 'org-latex-keyword)
in my personal Org mode setup. However, it does not work. The advice is
called and returns the string,
but somehow it is not inserted in the buffer. If I do the same thing in
ox-latex.el:org-latex-keyword function,
it does work. Any idea why ?
You need to set `ad-return-value' somewhere, don't you?
Regards,
--
Nicolas Goaziou
Re: [O] Image #s and captions missing in Org 8 Latex Export
Hello, Sam Ritchie sritchi...@gmail.com writes: I've just upgraded to org 8 (from 7.9) and am running into an issue with my latex export. I can't get captions to show up on the results of a code block evaluation, or reference those results with, for example [[fig:graph]]: You need to apply CAPTION and NAME keywords on the results, not the source code. Regards, -- Nicolas Goaziou
Re: [O] Bibliography
Since it is back-end dependent, why don't you use:
#+latex: \bibliography{...}\bibilographystyle{...}
instead?
To avoid duplication.
Org-bibtex/reftex need the line:
#+bibliography: foo plain
You need to set `ad-return-value' somewhere, don't you?
:-) This is what I was looking for.
Thanks a lot!
Fabrice
Re: [O] Image #s and captions missing in Org 8 Latex Export
Hey, excellent, that
works. Thanks so much!
Nicolas Goaziou
May 6, 2013 1:52
PM
Hello,You
need to apply CAPTION and NAME keywords on the results, not thesource
code.Regards,
Sam Ritchie
May 6, 2013 10:40
AM
Hey all,I've
just upgraded to org 8 (from 7.9) and am running into an issue with my
latex export. I can't get captions to show up on the results of a code
block evaluation, or reference those results with, for example
[[fig:graph]]:
#+caption: Graphviz Example#+name:
fig:graph#+BEGIN_SRC dot :exports results :file graph.png
:eval yes :cmdline -Kdot -Tpngdigraph data_relationships {
"org-mode"
"org-exp-blocks" "dot" "ditaa"
"HTML" [shape=Mrecord, label="{HTML|publish on the web\l}"]
"LaTeX" [shape=Mrecord, label="{LaTeX|publish in PDF\l}"]
"org-mode" - "org-exp-blocks" "dot" -
"org-mode" "ditaa" - "org-mode"
"org-exp-blocks" - "HTML"
"org-exp-blocks" - LaTeX}(+ 2 2)#+END_SRCCaptions
and internal links to actual code listings are working great:
#+caption: Hello, World in Clojure#+name: fig:hello#+BEGIN_SRC
clojure :exports code :eval no (println "Hello, World!")#+END_SRC[[fig:hello]]
resolves to "1", as expected, and the caption shows up in HTML export
and in the Latex export as "Figure 1: Hello, World in Clojure".
In org 7.9, my captions resolved on the png
results but would never show up on code exports. Is there some option
flag I need to enable to generate refs for embedded PNGs?
Thanks!Sam-- Sam Ritchie, Twitter Inc
703.662.1337@sritchie
(Too brief? Here's why! http://emailcharter.org)
-- Sam Ritchie, Twitter Inc
703.662.1337
@sritchie
Re: [O] using gnuplot's splot and every commands on org-mode table data
Eric Schulte writes: If you really wanted to be fancy, gnuplot will let you specify shell transformations as part of the plotting command which would allow you to forego the intermediate code block. As a side-note, if we'd drop the convention that the first separator defines the heading of the table and introduced a proper heading separator, then the following would be a table that Babel languages could interpret more easily: | a | b | c | |~~~+~~~+| | 1 | 1 | 2 | | 1 | 2 | 5 | | 1 | 3 | 10 | |---+---+| | 2 | 1 | 5 | | 2 | 2 | 8 | | 2 | 3 | 13 | |---+---+| | 3 | 1 | 10 | | 3 | 2 | 13 | | 3 | 3 | 18 | 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] Bibliography
Fabrice Popineau fabrice.popin...@supelec.fr writes:
Since it is back-end dependent, why don't you use:
#+latex: \bibliography{...}\bibilographystyle{...}
instead?
To avoid duplication.
Org-bibtex/reftex need the line:
#+bibliography: foo plain
OK. Then, it may indeed be wise to support #+bibliography in latex
back-end. My only concern is about users expecting the keyword to be
recognized in other back-ends.
Regards,
--
Nicolas Goaziou
Re: [O] Question about org-plus-contrib elpa
Seth Mason writes: According to http://orgmode.org/elpa.html the org-plus-contrib package has all the files in the /contrib directory but it looks like it's only grabbing the files that begin with org-. None of the ox- or ob- are in the repo. Looks like this line in servers.mk is the culprit: elpaplus-dirty elpaplus-up: ORG_ADD_CONTRIB=org-* Is this an oversight or by design? Both. :-) Fixed in maint and master. 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
Re: [O] Exporting large documents
Hello, Achim Gratz strom...@nexgo.de writes: Lawrence Mitchell writes: org-element--current-element takes (on my machine) 0.0003 seconds per call. However, when exporting 128x the orgmanual introduction, it's called around 25 times giving ~ 80 seconds total time (out of ~200 total). I've traced this a bit and the question does warrant further investigation. Exporting the introduction without any duplications already shows some interesting things: the property drawer for the introduction is scanned a whopping 137 times, followed by 134 times the cindex entry following it, followed by 125 times the Summary headline. The header options feature prominently with around 100 scans each as well. The rest of the calls have mostly just a single invocation, but there are some instances where parts of the tree are traversed multiple times in succession to apparently adjust the :end property to the leaf element in small increments or decrements. If elements are mutable during parsing then caching is more difficult as well, obviously. So it sort of feels like actually what is needed is microoptimisations of the bits of the export engine that are called the most. Looking at the traces I'd think if we could eliminate the repeated backtracking to adjust the leafs or at least skip over those elements in a backtrack that are already fully parsed instead of parsing them again, that would be a good start. Actually this is a bit different. Parsing doesn't backtrack. Look at `org-element-parse-buffer' through elp to see that elements are parsed only once. The problem comes from `org-element-at-point'. To be effective, it needs to move back to the current headline, and start parsing buffer again from there. That means the first element after the headline (often a property drawer) will be parsed each time we need information within the section. A very good improvement for the exporter and, more importantly, for the parser, would be to cache results from `org-element--current-element'. Though, this cache would also need to be refreshed after each buffer modification. This is the tricky part. One solution would be to use `after-change-functions' and `before-change-functions' to store intervals of modified areas in the buffer. Then, during idle time, a `maphash' could update boundaries of cached values or remove them completely, according to the intervals. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Re: Can't export LaTeX source code blocks
Sebastien Vauban sva-n...@mygooglest.com writes: Sebastien Vauban wrote: Thomas S. Dye wrote: Sebastien Vauban writes: The code block is NEVER exported. I don't understand why? I'm not sure either. I took a quick look at ob-latex.el. The code there sets `:exports results' and then, IIUC, goes on its way without checking if :exports has been set in the buffer. It looks to me like ob-latex.el would need to be revised. I don't have the impression that the error lies in `ob-latex' as the other `ob-LANG' files don't either make any special check -- while all graphics-only languages do, as well, have the default of results for :exports. I have the impression the problem is to search in `ob-core' (`org-babel-execute-src-block') or `ob-exp'... But that's not yet clear to me where that could be. I think I found it. That was a priority order problem for implementing the hierarchy of header arguments inheritage in `ob-core'. Applied, Thanks! Best regards, Seb From 3339c0f7d296fc68a206b0f69270da3a91025840 Mon Sep 17 00:00:00 2001 From: Sebastien Vauban sva-n...@invalid.mygooglest.com Date: Sat, 27 Apr 2013 11:40:25 +0200 Subject: [PATCH 2/2] Fix priority order for inheriting header arguments * ob-core.el (org-babel-parse-src-block-match): Fix order of list of header arguments. --- lisp/ob-core.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 9baff0c..73dca8f 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -1,6 +1,6 @@ ;;; ob-core.el --- working with code blocks in org-mode -;; Copyright (C) 2009-2012 Free Software Foundation, Inc. +;; Copyright (C) 2009-2013 Free Software Foundation, Inc. ;; Authors: Eric Schulte ;; Dan Davison @@ -1323,8 +1323,8 @@ may be specified in the properties of the current outline entry. (buffer-string))) (org-babel-merge-params org-babel-default-header-args - (org-babel-params-from-properties lang) (if (boundp lang-headers) (eval lang-headers) nil) + (org-babel-params-from-properties lang) (org-babel-parse-header-arguments (org-no-properties (or (match-string 4) switches -- 1.7.9 -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] latex export of words starting with a superscript
Dnia 2013-05-06, o godz. 15:22:47
Brian zenli...@gmail.com napisał(a):
Dear list,
this is my first time posting here so: thanks for all the work on
org-mode! I like the new changes (although the new variable names
were a pain).
This is either a feature request, a complaint or a demonstration of
my lack of knowledge of org-mode.
Hi,
I'd rather say that it's a demonstration of the slope of LaTeX learning
curve;). TeX really is not supposed to handle formulae *starting* with
^ or _ (well, it works, since TeX - AFAIR - puts an implicit {} before
them, but this is not very usual in maths). What and _ are meant for
is *maths*, not *chemistry*. Try putting chemistry into the search
form at http://www.ctan.org/search - there are quite a few packages for
typesetting chemical formulae. (In fact, your problem is not the only
one with typesetting chemistry in TeX; positioning of
\(super\|sub\)scripts is also by default suitable for mathematics and
not chemistry!)
Then, you would (I guess) include some simple TeX markup in your Org
file and \usepackage something in the preamble.
In a pinch, try \null instead of a \space as a prefix.
hth
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Michael Brand writes: Thinking about this and my previous post I conclude that Org babel is just perfect for my use case. If you want to pass a variety of named parameters, that may be true. On the other hand, since you end up typing the parameter names anyway, the absolutely simplest way to get the behavior you want might simply be something like: : #+LINK: gmap http://maps.google.ch/maps? : [[gmap:t=pspn=0.2,0.2ll=13.0,14.3q=13.0,14.3]] Well, as a beginner of Org babel I am not yet there completely and would like to ask for help on the source block header: [...] The issue is that org-entry-get returns nil instead of the value of the item property :geo:, therefore my demo workaround with the or to show the principle of gmb. How to resolve this properly? For starters, see the docstring for org-entry-get; it expects a point-or-marker as the first argument, but you are passing nil. I'm afraid knowing that doesn't help much. The problem is, you don't know what point the inline call is at, so you cannot point org-entry-get to the right entry. If you try : (org-entry-get (point) geo) it will look for a geo property in the outline entry the source block is in, not in the entry the call comes from. I don't know any easy way to pass a parameter to a source block from an outline entry property via an inline call in that entry. Others may know better. Isn't there something like #+HEADER: :var geo_var=:geo: to copy the value of the item property :geo: to the babel variable unless specified by the caller? Afraid not. Yours, Christian
Re: [O] bug#14346: 24.3; beginning-of-visual-line jumps to previous line in org-mode
Even if the behavior doesn't change (soon), could the equivalent of the following be implemented in org-mode? It's the only place where this has been problematic for me. (defadvice org-beginning-of-line (after smart-point-adjustment activate) (setq disable-point-adjustment (or (not (invisible-p (point))) (not (invisible-p (max (point-min) (1- (point (defadvice org-end-of-line (after smart-point-adjustment activate) (setq disable-point-adjustment (or (not (invisible-p (point))) (not (invisible-p (max (point-min) (1- (point Evgeni On Sat, May 4, 2013 at 2:27 PM, E Sabof esa...@gmail.com wrote: Wouldn't it be better if forward/backward-char kept the old behavior, and the rest of the commands did something similar to this in the end: (setq disable-point-adjustment (preceding-or-following-character-visible-p)) I'm not entirely sure whether it would be better, but at the moment, I can't think of a case where it wouldn't. Evgeni On Sat, May 4, 2013 at 1:16 PM, Eli Zaretskii e...@gnu.org wrote: Date: Sat, 4 May 2013 12:17:35 +0100 From: E Sabof esa...@gmail.com Cc: 14...@debbugs.gnu.org I see what you mean. But it still looks like a bug - whether I follow the above recipe, or press C-e C-a, the point will (should?) go to the same position, but the behavior is different. The behavior depends on the direction point was moving before ending up in the invisible text. It's a heuristic, and as every heuristic, it sometimes fails.
[O] INCLUDE directives in new org-mode
Hello all,
I am trying to use the #+INCLUDE directives to have template information
for a series of orgmode files that I want to export. Prior to upgrading to
v8, the below minimal example was working. But as of the upgrade, any
text in an included file is just copied in verbatim.
--- foo.org
#+INCLUDE: date.org
* this is a test
--- date.org
{{{date(%d %b %Y)}}}
When I export foo.org using the odt exporter, the date does not show, but
it used to in previous versions. Is there something I need to do to the
syntax of the include ?
-Tim
Re: [O] INCLUDE directives in new org-mode
El lun, 06 may 2013, Wiskey 5 Alpha decía: Hello all, I am trying to use the #+INCLUDE directives to have template information for a series of orgmode files that I want to export. Prior to upgrading to v8, the below minimal example was working. But as of the upgrade, any text in an included file is just copied in verbatim. --- [1]foo.org #+INCLUDE: [2]date.org The new syntax: #+INCLUDE: date.org -- :: Osiris Alejandro Gomez (OSiUX) os...@osiux.com.ar DC44 95D2 0D5D D544 FC1A F00F B308 A671 9237 D36C http://www.osiux.com.ar http://www.altermundi.net signature.asc Description: Digital signature
Re: [O] Agenda buffer: 't' key moves current item to window's top line
Jeff Kowalski jeff.kowalski at gmail.com writes: Bastien bzg at altern.org writes: Hi James, James Harkins jamshark70 at gmail.com writes: After a recent update, I noticed that the agenda buffer now moves the displayed text when you change an item's TODO state using 't'. Fixed, thanks! I'm still seeing the move-to-top bug, as James stated in OP. I'm using Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef at /usr/share/emacs/24.3.50/lisp/org/). Bastien, in which release was it fixed? I'll answer my own question - it appears to be fixed by Org-mode version 8.0.2 (8.0.2-10-g3e1d83-elpa) Jeff
Re: [O] Bibliography
My only concern is about users expecting the keyword to be recognized in other back-ends. Yes please. I am waiting for something that will export bibtex to html. With the old exporter, org-exp-bibtex used bibtex2html to achieve it. But nothing similar is possible with the new exporter. Vikas
[O] disable tangling for an entire section?
Is there a simple way to disable tangling for an entire section's code blocks? Or to put it a different way, can tangling be toggled at the section level and not just the code-block level? I tried this: ** a section in my file :PROPERTIES: :tangle: no :END: by analogy from #+PROPERTY: tangle yes in (info (org) Header arguments in Org mode properties), but code blocks in that section were still tangled. Org-mode version 8.0.2 (release_8.0.2-61-g22dfa7 @ /home/billw/Dropbox/org/org-mode/lisp/) GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2013-03-11 on wri Thanks - bw -- Bill White . bi...@wolfram.com No ma'am, we're musicians.
