Re: [O] BABEL -- PROPERTY?
Hi Nick, Nick Dokos wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Michael Hannon wrote: (2) I typically use the following BABEL line: #+BABEL: :session *R* :cache yes :results output verbatim :exports both :tangle How would I express that using the PROPERTY syntax? #+PROPERTY: tangle yes Note that I added a yes value for the tangle property. That was missing from your BABEL line. Interesting. This is a digression, but in my version of Emacs (23.2.1, linux, 64-bit) if I try to copy a long line -- one that extends beyond the border of the window -- by doing, say: C-a C-SPACE C-e M-w I don't get the whole line. The copied text doesn't stop at the visible border of the window, but neither does it get all the way to the end of the line. Following up your digression... I've seen the same funny root problem when doing `C-e' on long lines on my Windows Emacs (23.3, I think -- I run different versions at different moments). Indeed, `C-e' sometimes does go further than the visible screen limit, but doesn't land at the end of the physical line. I thought it could be something in my (very) long .emacs file. Thanks for showing me it's not my config that's in cause! C-e is bound to org-end-of-line which does the stutter step when you have a wide buffer in a narrow window: it stops at the first previously invisible character[fn:1]. If you have a very wide screen (e.g. a table with a hundred columns or something like that) it might take a few steps before you get to the end of the line. But the main reason for org-end-of-line's existence is its behavior on headlines (and the setting of org-special-ctrl-a/e is very relevant). C-h f org-end-of-line RET and C-h v org-special-ctrl-a/e RET make for enlightening reading. Nick Footnotes: [fn:1] well, it's invisible if truncate-lines is t - part of the problem of describing the bahavior is the settings of all these flags. Tables look ugly if wrapped, so you probably want truncate-lines set to t anyway. I was aware of `org-special-ctrl-a/e' (not set in my config) to let `C-a' and `C-e' behave specially in headlines and items, but I was not aware that -- when not special -- `C-e' still behaved differently from the standard `end-of-line'. I've now bound them back to the standard functions. Thanks... Best regards, Seb -- Sebastien Vauban
[O] odt export to google-docs problem
Here is a small file for org mode #+OPTIONS: toc:nil #+TITLE: Report * Tue 8th - http://www.haskell.org/ * hello If I export to odt and then upload the odt to google docs, google-docs says the file is corrupt. It seems to make a difference whether the EOF is immediately at the end of hello or after a newline -- though not sure. As far as I can see files made directly by/in libreoffice upload to google-docs without any problem org: 7.7 emacs 23.3.1 [And in case line-endings have anything to do with it: OS: Debian/testing]
Re: [O] odt export to google-docs problem
Rustom Can you send me this odt file either on or off the list? Please make sure that the document is not resaved from Libreoffice - this is because LibreOffice rewrites XML if resaved. So send the file as soon as it is exported out of org-odt. What is the org-version? Are you exporting with a minimal emacs? Just to be sure it has nothing to do with your local configuration. You may want to check for corruption using the instructions here. (I think the ODF validator has moved elsewhere lately) , |LibreOffice reports corrupt documents when the XML emitted by the |exporter is not well-formed according to OpenDocument schema. To |identify the root cause of corruption use one of the following |methods: |1. Use an Online validator | Pass the exported document through the [[http://tools.services.openoffice.org/odfvalidator/][ODF Validator]] and note | down the errors. | |2. Use Emacs' in-built validator. Immediately after exporting | 1) C-x b test.odt | 2) Open the `content.xml' file by hitting RET on it | 3) Do M-x rng-first-error | 4) Note the error message, the XML markup at the point of error | and the surrounding context. ` Jambunathan K. Rustom Mody rustompm...@gmail.com writes: Here is a small file for org mode #+OPTIONS: toc:nil #+TITLE: Report * Tue 8th - http://www.haskell.org/ * hello If I export to odt and then upload the odt to google docs, google-docs says the file is corrupt. It seems to make a difference whether the EOF is immediately at the end of hello or after a newline -- though not sure. As far as I can see files made directly by/in libreoffice upload to google-docs without any problem org: 7.7 emacs 23.3.1 [And in case line-endings have anything to do with it: OS: Debian/ testing] --
Re: [O] odt export to google-docs problem
Rustom Mody rustompm...@gmail.com writes: Here is a small file for org mode #+OPTIONS: toc:nil #+TITLE: Report * Tue 8th - http://www.haskell.org/ * hello If I export to odt and then upload the odt to google docs, google-docs says the file is corrupt. On my local machine I am seeing that the exported file is valid and opens fine with LibreOffice-3.4 without any issues. I haven't experimented with Google docs. It seems to make a difference whether the EOF is immediately at the end of hello or after a newline -- though not sure. As far as I can see files made directly by/in libreoffice upload to google-docs without any problem org: 7.7 emacs 23.3.1 Make sure that org-odt is new. Older versions of org-odt did have some corruption issues. [And in case line-endings have anything to do with it: OS: Debian/ testing] Can anyone else reproduce this? --
Re: [O] Standardized code block syntax and Property Accumulation merged into Master
Hi Eric, Eric Schulte wrote: The standard-code-block-syntax branch has been merged into the master branch of the git repository. This brings two much discussed changes to Org-mode, first a standard set of keywords for code blocks and second the ability to accumulate properties by appending a + to the end of the property name. For much more information on both of these changes see the relevant commits [1] and [2] respectively. A function for updating existing Org-mode files to use the new standardized code block keywords is inline below [3], additionally I've updated my collection of Org-mode code block scraps [4]. Nice to see it's finally in! However, I have to report a _tiny_ feature of applying your function: [3] Function to update Org-mode buffers to use the new code block syntax. (defun update-org-buffer () Update an Org-mode buffer to the new data, code block and call line syntax. (interactive) (save-excursion (flet ((to-re (lst) (concat ^[ \t]*#\\+ (regexp-opt lst t) \\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*)) (update (re new) (goto-char (point-min)) (while (re-search-forward re nil t) (replace-match new nil nil nil 1 (let ((old-re (to-re '(RESULTS DATA SRCNAME SOURCE))) (lob-re (to-re '(LOB))) (case-fold-search t)) (update old-re name) (update lob-re call) When run on a buffer containing: #+property: var foo=1 #+begin_src emacs-lisp foo #+end_src #+results: : 1 it will translate `#+results' to `#+name': #+property: var foo=1 #+begin_src emacs-lisp foo #+end_src #+name: : 1 Further evaluations of that *un-named* code block will leave the `#+name' line. To get back the expected `#+results' line, you have to manually remove that results line, and re-evaluate the code block. Best regards, Seb -- Sebastien Vauban
[O] [bug][babel] #+call: execution broken
Hi C-c C-c on a #+call: block() statement no longer causes the block to execute. This regression occurred on Nov 8th: commit a4273cbe0e0480bd02c59464cafb985951b1c5a2 Author: Eric Schulte schulte.e...@gmail.com Date: Tue Nov 8 19:42:59 2011 -0700 call lines are more careful about being in example or verbatim blocks I've supplied a patch which provides a couple of failing tests which highlight the problem. Best, Martyn From 68a64d29222548eff3f414b8881f583f50ea4a96 Mon Sep 17 00:00:00 2001 From: Martyn Jago martyn.j...@btinternet.com Date: Thu, 17 Nov 2011 12:33:08 + Subject: [PATCH] Tests for testing basic `#+call: block-name()' actually cause block execution * testing/lisp/test-ob.el: --- testing/lisp/test-ob.el | 38 ++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index d145f4e..3fefe91 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -499,4 +499,42 @@ on two lines (provide 'test-ob) +(ert-deftest test-org-babel/basic-call-execution-bol() +Test that executing #+call: with point on # executes the block + (org-test-with-temp-text + +#+call: my-test() +#+srcname: my-test +#+begin_src emacs-lisp + (+ 2 3) +#+end_src + + (should (search-forward #+call:)) + (beginning-of-line) + (org-ctrl-c-ctrl-c) + (should (search-forward #+results: my-test())) + (forward-line) + (should (string= : 5 + (buffer-substring-no-properties + (point-at-bol) (point-at-eol)) + +(ert-deftest test-org-babel/basic-call-execution-eol() +Test that executing #+call: with point at eol executes the block + (org-test-with-temp-text + +#+call: my-test() +#+srcname: my-test +#+begin_src emacs-lisp + (* 2 3) +#+end_src + + (should (search-forward #+call:)) + (end-of-line) + (org-ctrl-c-ctrl-c) + (should (search-forward #+results: my-test())) + (forward-line) + (should (string= : 6 + (buffer-substring-no-properties + (point-at-bol) (point-at-eol)) + ;;; test-ob ends here -- 1.7.3.4
Re: [O] org-mobile-push failure with git tip
[problem with org-mobile-push from commit dc62cdcdf11f305149281d16ef2200e18c7abd43 ] I've recently pushed a patch around that area. Does the problem persist with the latest git ? Thanks. I updated (to 7c21098323bf0097c7903b014564cd6056bda374) and now all is well. pgp3WO1QFGRok.pgp Description: PGP signature
Re: [O] Standardized code block syntax and Property Accumulation merged into Master
Hi Eric, Eric Schulte wrote: The standard-code-block-syntax branch has been merged into the master branch of the git repository. [...] Additionally I've updated my collection of Org-mode code block scraps [4]. [4] http://eschulte.github.com/org-scraps/ I just looked at a couple of them, and it occurred to me that this one can't work (anymore?) as the name of the *data* table is the same as the name of the *source* block: http://eschulte.github.com/org-scraps/scraps/2011-08-19-replacing-a-table.html Changing one name or the other does cure this. Best regards, Seb -- Sebastien Vauban
[O] Quicker refile? Capture progress cookies. Using capture to count/tally
I have a list of niggles which are not on an active todo list because they only occur to me from time to time, but I wanted to be able to quickly note each time one of them bothers me, so that the most annoying ones, the ones I would want to add to my todo list first, might start to rise to the surface. So I created a capture template which inserts a todo under the already listed niggle (which has a progess cookie). It's simple and reasonably fast. Does anyone have any other ways of counting/tallying in org-mode? There are two issues with how I'm doing it. One (pretty minor) is that the inserted todo doesn't trigger off the progress cookie. It's not a big deal; when I want to know which niggle has the largest count, I just need to do C-u C-c # in the file. But I thought I'd point it out in case it could be fixed. The second issue is one I have with capture all the time; I want the refile to be faster. I have a few capture templates for logging that send to a particular headline, but most times I use capture the target can be anywhere in my main outlines. As it is, I'm almost always finishing up with C-c C-w, and in effect starting from scratch each time, narrowing down to the target from all my agenda files. I'd really like a template where once I've called it and entered text or tags or whatever, I use a single key press and the refile selection would begin with a file or headline pre-selected for quick further narrowing down. I don't know if that's do-able with IDO but I do imagine it could work with file+headline, file+olp etc. They would become file+headline+prompt etc and just as now, the template would determine which target was first suggested, but then it would still be open for quick further filtering before RET. To summarise - my 2 ideas are: 1. to add something like +prompt to refile selection in general, and 2. to allow capture templates with a +prompt target to use a single key to start the refile process. I hope all this makes sense! Geraldine
Re: [O] [bug][babel] #+call: execution broken
Martyn Jago martyn.j...@btinternet.com writes: Hi C-c C-c on a #+call: block() statement no longer causes the block to execute. This regression occurred on Nov 8th: commit a4273cbe0e0480bd02c59464cafb985951b1c5a2 Author: Eric Schulte schulte.e...@gmail.com Date: Tue Nov 8 19:42:59 2011 -0700 call lines are more careful about being in example or verbatim blocks I've supplied a patch which provides a couple of failing tests which highlight the problem. Hi Martyn, The reason that your tests are failing is because they use the old #+srcname: rather than the new #+name: syntax for naming a code block. After making this change both tests pass. Cheers -- Eric Best, Martyn -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Standardized code block syntax and Property Accumulation merged into Master
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: The standard-code-block-syntax branch has been merged into the master branch of the git repository. [...] Additionally I've updated my collection of Org-mode code block scraps [4]. [4] http://eschulte.github.com/org-scraps/ I just looked at a couple of them, and it occurred to me that this one can't work (anymore?) as the name of the *data* table is the same as the name of the *source* block: http://eschulte.github.com/org-scraps/scraps/2011-08-19-replacing-a-table.html Indeed, this change actually isn't directly related to the syntax changes but is rather a result of a recent bug fix, as whenever there are both data and code with the same name, the code should be primary because the data could simply be un-cached results of the code. Changing one name or the other does cure this. Thanks, I've simply removed this example. Cheers -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Standardized code block syntax and Property Accumulation merged into Master
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: The standard-code-block-syntax branch has been merged into the master branch of the git repository. This brings two much discussed changes to Org-mode, first a standard set of keywords for code blocks and second the ability to accumulate properties by appending a + to the end of the property name. For much more information on both of these changes see the relevant commits [1] and [2] respectively. A function for updating existing Org-mode files to use the new standardized code block keywords is inline below [3], additionally I've updated my collection of Org-mode code block scraps [4]. Nice to see it's finally in! Thanks, me too. However, I have to report a _tiny_ feature of applying your function: [3] Function to update Org-mode buffers to use the new code block syntax. (defun update-org-buffer () Update an Org-mode buffer to the new data, code block and call line syntax. (interactive) (save-excursion (flet ((to-re (lst) (concat ^[ \t]*#\\+ (regexp-opt lst t) \\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*)) (update (re new) (goto-char (point-min)) (while (re-search-forward re nil t) (replace-match new nil nil nil 1 (let ((old-re (to-re '(RESULTS DATA SRCNAME SOURCE))) (lob-re (to-re '(LOB))) (case-fold-search t)) (update old-re name) (update lob-re call) When run on a buffer containing: #+property: var foo=1 #+begin_src emacs-lisp foo #+end_src #+results: : 1 it will translate `#+results' to `#+name': #+property: var foo=1 #+begin_src emacs-lisp foo #+end_src #+name: : 1 Further evaluations of that *un-named* code block will leave the `#+name' line. To get back the expected `#+results' line, you have to manually remove that results line, and re-evaluate the code block. This, given that results and name are technically still synonyms this isn't necessarily a bug, however I do agree that a version of the functions which left the #+results: lines immediately following code blocks unchanged would be preferable. Cheers -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] odt export to google-docs problem
Hi Jambunathan, On Thu, Nov 17, 2011 at 11:06, Jambunathan K kjambunat...@gmail.com wrote: Can anyone else reproduce this? I can replicate this. The odt file exported by org-odt is not accepted by google docs even though libreoffice opens it without problems. However it I open it with libreoffice and say edit and save, google docs then accepts the new file. I have attached both odt files along with the org file. PS: tested with minimal Emacs 24 and org release_7.7-543-g176ddba -- Suvayu Open source is the future. It sets us free. #+OPTIONS: toc:nil #+TITLE: Report * Tue 8th - http://www.haskell.org/ * hello odt-test-working.odt Description: application/vnd.oasis.opendocument.text odt-test-buggy.odt Description: application/vnd.oasis.opendocument.text
Re: [O] Quicker refile? Capture progress cookies. Using capture to count/tally
Gez sule...@gmail.com writes: The second issue is one I have with capture all the time; I want the refile to be faster. I have a few capture templates for logging that send to a particular headline, but most times I use capture the target can be anywhere in my main outlines. As it is, I'm almost always finishing up with C-c C-w, and in effect starting from scratch each time, narrowing down to the target from all my agenda files. I'd really like a template where once I've called it and entered text or tags or whatever, I use a single key press and the refile selection would begin with a file or headline pre-selected for quick further narrowing down. I don't know if that's do-able with IDO but I do imagine it could work with file+headline, file+olp etc. They would become file+headline+prompt etc and just as now, the template would determine which target was first suggested, but then it would still be open for quick further filtering before RET. To summarise - my 2 ideas are: 1. to add something like +prompt to refile selection in general, and 2. to allow capture templates with a +prompt target to use a single key to start the refile process. I hope all this makes sense! Hi Geraldine, I almost exclusively use capture to quickly file away things I don't want to forget. This goes to my refile.org as a level 1 heading and isn't attached to anything yet. All of my tasks that need to be refiled show up on my block agenda view in the second section - immediately under today's agenda view. (see the screen shot after the elisp at http://doc.norang.ca/org-mode.html#sec-5-1) I'm using this block agenda view regularly during the day and the tasks to be refiled are constantly 'in my face' until I do something with them. I refile these items mostly from the agenda - I tend to get 2 or 3 of them that are going to the same target so I'll mark them with 'm' and refile with 'B r'. My refile setup uses IDO completion for refile targets and I find this works very well. If I'm refiling to file x.org under '* Tasks' I'll do something like C-c C-w x.org C-SPC tasks RET The order of entering x.org/tasks doesn't matter - IDO is limiting the targets to the entered data so I can match part of what is left in the list. This works great for me and makes refiling much faster then when I used full paths/completion in steps. I've also set up refiling to remove DONE tasks from the list of available completion targets. This helps prevent mistakes where you refile to an already done tree (or if you have repeating separate tasks with the same name only the open ones show up as refile targets.) My refile setup is described at http://doc.norang.ca/org-mode.html#Refiling The reason this works so well (for me) is I put off refiling the task until I have a minute or two during the day to deal with it. Normally when I'm capturing a task I'm in the middle of something and I just want to record whatever details I need and return to what I was doing as quickly as possible. Refiling the thing to the right place isn't important right now so I put that off. Constantly having to move things to the right place as you capture them will be too slow IMHO. Hope that helps, Regards, Bernt
[O] when export org-mode to html, don't export entries of TODO, CANCELED
hi emacsers Exporting org-mode's entries to html is a fantastic way for knowledge sharing! Usually entries of TODO HALF DELEGATE CANCELED DEFERRED are incomplete/immature knowledge. Thus, I don't want to export them. Furthermore, after they are marked as DONE, I'd like to export them. Any idea for how to do this? Note that org-export-exclude-tags doesn't help us, at my first glance. Draft solution: After checking the implementation of org-mode for this part, I found org-export-handle-export-tags function. It determines what to be excluded when exporting, by search regexp of :\\(TAG1\\|TAG2\\|...\\): in entries' title. Thus I override org-export-handle-export-tags, by search regexp of \\(TAG1\\|TAG2\\|...\\) with leading/tailing colon removed. It's ugly but it works. So my open question is what's the better solution? http://hi.baidu.com/filebat/blog/item/6406a9fd6f79fd0b08244d7d.html
Re: [O] when export org-mode to html, don't export entries of TODO, CANCELED
filebat Mark filebat.m...@gmail.com writes: Exporting org-mode's entries to html is a fantastic way for knowledge sharing! Usually entries of TODO HALF DELEGATE CANCELED DEFERRED are incomplete/immature knowledge. Thus, I don't want to export them. Furthermore, after they are marked as DONE, I'd like to export them. Any idea for how to do this? Note that org-export-exclude-tags doesn't help us, at my first glance. Draft solution: After checking the implementation of org-mode for this part, I found org-export-handle-export-tags function. It determines what to be excluded when exporting, by search regexp of :\\(TAG1\\|TAG2\\|...\\): in entries' title. Thus I override org-export-handle-export-tags, by search regexp of \\(TAG1\\|TAG2\\|...\\) with leading/tailing colon removed. It's ugly but it works. So my open question is what's the better solution? Hi, Try adding this to your org file and then exporting #+OPTIONS: tasks:(DONE) todo:nil Regards, Bernt
Re: [O] when export org-mode to html, don't export entries of TODO, CANCELED
Hi Bernt I am not sure whether I get you correctly. The behavior of [#+OPTIONS: tasks:(DONE) todo:nil] looks like (setq org-export-with-todo-keywords nil). My purpose is not to export entries of TODO, CANCELED, etc, instead of only strings of TODO, CANCELED. On Fri, Nov 18, 2011 at 9:46 AM, Bernt Hansen be...@norang.ca wrote: filebat Mark filebat.m...@gmail.com writes: Exporting org-mode's entries to html is a fantastic way for knowledge sharing! Usually entries of TODO HALF DELEGATE CANCELED DEFERRED are incomplete/immature knowledge. Thus, I don't want to export them. Furthermore, after they are marked as DONE, I'd like to export them. Any idea for how to do this? Note that org-export-exclude-tags doesn't help us, at my first glance. Draft solution: After checking the implementation of org-mode for this part, I found org-export-handle-export-tags function. It determines what to be excluded when exporting, by search regexp of :\\(TAG1\\|TAG2\\|...\\): in entries' title. Thus I override org-export-handle-export-tags, by search regexp of \\(TAG1\\|TAG2\\|...\\) with leading/tailing colon removed. It's ugly but it works. So my open question is what's the better solution? Hi, Try adding this to your org file and then exporting #+OPTIONS: tasks:(DONE) todo:nil Regards, Bernt -- Thanks Regards Denny Zhang
Re: [O] when export org-mode to html, don't export entries of TODO, CANCELED
filebat Mark filebat.m...@gmail.com writes: Hi Bernt I am not sure whether I get you correctly. The behavior of [#+OPTIONS: tasks:(DONE) todo:nil] looks like (setq org-export-with-todo-keywords nil). My purpose is not to export entries of TODO, CANCELED, etc, instead of only strings of TODO, CANCELED. This should export all headings that have no todo keyword AND headings with the DONE keyword. All other keywords are skipped which I thought was what you were trying to accomplish. I tested it with this org file: http://norang.ca/tmp/scratch.org which exports to http://norang.ca/tmp/scratch.html -Bernt On Fri, Nov 18, 2011 at 9:46 AM, Bernt Hansen be...@norang.ca wrote: filebat Mark filebat.m...@gmail.com writes: Exporting org-mode's entries to html is a fantastic way for knowledge sharing! Usually entries of TODO HALF DELEGATE CANCELED DEFERRED are incomplete/immature knowledge. Thus, I don't want to export them. Furthermore, after they are marked as DONE, I'd like to export them. Any idea for how to do this? Note that org-export-exclude-tags doesn't help us, at my first glance. Draft solution: After checking the implementation of org-mode for this part, I found org-export-handle-export-tags function. It determines what to be excluded when exporting, by search regexp of :\\(TAG1\\|TAG2\\ |...\\): in entries' title. Thus I override org-export-handle-export-tags, by search regexp of \\(TAG1\\|TAG2\\|...\\) with leading/tailing colon removed. It's ugly but it works. So my open question is what's the better solution? Hi, Try adding this to your org file and then exporting #+OPTIONS: tasks:(DONE) todo:nil Regards, Bernt -- Thanks Regards Denny Zhang
Re: [O] when export org-mode to html, don't export entries of TODO, CANCELED
Bernt Hansen be...@norang.ca writes: Yes, Bernt, this is exactly what I want. I will dig into why my org-mode behavior is different from yours, when I return home. ,--- my environment | GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-09-02 on pluot, modified by Debian | Org-mode version 7.5 `--- Thanks a lot, Bernt! Denny filebat Mark filebat.m...@gmail.com writes: Hi Bernt I am not sure whether I get you correctly. The behavior of [#+OPTIONS: tasks:(DONE) todo:nil] looks like (setq org-export-with-todo-keywords nil). My purpose is not to export entries of TODO, CANCELED, etc, instead of only strings of TODO, CANCELED. This should export all headings that have no todo keyword AND headings with the DONE keyword. All other keywords are skipped which I thought was what you were trying to accomplish. I tested it with this org file: http://norang.ca/tmp/scratch.org which exports to http://norang.ca/tmp/scratch.html -Bernt On Fri, Nov 18, 2011 at 9:46 AM, Bernt Hansen be...@norang.ca wrote: filebat Mark filebat.m...@gmail.com writes: Exporting org-mode's entries to html is a fantastic way for knowledge sharing! Usually entries of TODO HALF DELEGATE CANCELED DEFERRED are incomplete/immature knowledge. Thus, I don't want to export them. Furthermore, after they are marked as DONE, I'd like to export them. Any idea for how to do this? Note that org-export-exclude-tags doesn't help us, at my first glance. Draft solution: After checking the implementation of org-mode for this part, I found org-export-handle-export-tags function. It determines what to be excluded when exporting, by search regexp of :\\(TAG1\\|TAG2\\ |...\\): in entries' title. Thus I override org-export-handle-export-tags, by search regexp of \\(TAG1\\|TAG2\\|...\\) with leading/tailing colon removed. It's ugly but it works. So my open question is what's the better solution? Hi, Try adding this to your org file and then exporting #+OPTIONS: tasks:(DONE) todo:nil Regards, Bernt -- Thanks Regards Denny Zhang -- Denny Zhang 电话: 18621908421 邮箱: markfile...@126.com 微博: http://weibo.com/1686664253 博客: http://hi.baidu.com/filebat 你想要管理的事情越平淡无奇，你的系统就需要越复杂才能把它们管理好。 ●█〓██▄▄ ●● ▄▅██▅▄▃▂ ██ ◥⊙▲⊙▲⊙▲⊙▲⊙▲⊙▲◤
Re: [O] when export org-mode to html, don't export entries of TODO, CANCELED
markfilebat126 markfile...@126.com wrote: Bernt Hansen be...@norang.ca writes: Yes, Bernt, this is exactly what I want. I will dig into why my org-mode behavior is different from yours, when I return home. ,--- my environment | GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-09-02 on pluot, modified by Debian | Org-mode version 7.5 `--- release 7.5 was done on March 7, 2011. The tasks option was added to org-mode on March 30, 2011. So you will need to upgrade to take advantage of it. Nick
[O] Problem compiling C++ in Org-mode
Greetings. I'm having a problem compiling a C++ source-code block in
Org-mode. The same C++ code compiles and runs in the shell.
The issue seems to relate to local include files. I.e., a program that
includes only standard files, such as:
#include iostream
works fine. But Org-mode seems to be unable to find a file included from the
current directory, such as:
#include OtherStuff.cpp
I've appended the Org source code and associated error message.
I've also appended the log of a successful compilation of the same source code
in the shell, as well as the details of my configuration.
What am I missing?
Thanks,
-- Mike
## Unsuccessful attempt to compile in Org-mode
* Test
#+begin_src cpp
#include iostream
#include memory
#include OtherStuff.cpp
using namespace std;
int main() {
cout Hello! endl;
}
#+end_src
#+results:
/tmp/babel-245846_d/C-src-24584NIQ.cpp:7:26: fatal error: OtherStuff.cpp: No
such file or directory
compilation terminated.
/bin/bash: /tmp/babel-245846_d/C-bin-24584aSW: Permission denied
## Successful compilation in linux shell
$ cat junk.cpp
#include iostream
#include memory
#include OtherStuff.cpp
using namespace std;
int main() {
cout Hello! endl;
}
$ g++ -o junk -std=c++0x junk.cpp
$ ./junk
Hello!
## Org-mode compile uses same option as shell compile:
org-babel-C++-compiler is a variable defined in `ob-C.el'.
Its value is g++ -std=c++0x
Documentation:
Command used to compile a C++ source code file into an
executable.
## My configuration
Emacs : GNU Emacs 23.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.24.5)
of 2011-06-29 on x86-01.phx2.fedoraproject.org
Package: Org-mode version 7.7 (release_7.7.328.g1a97.dirty)
Re: [O] when export org-mode to html, don't export entries of TODO, CANCELED
got it， thanks all Nick Dokos nicholas.do...@hp.com编写： markfilebat126 markfile...@126.com wrote: Bernt Hansen be...@norang.ca writes: Yes, Bernt, this is exactly what I want. I will dig into why my org-mode behavior is different from yours, when I return home. ,--- my environment | GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-09-02 on pluot, modified by Debian | Org-mode version 7.5 `--- release 7.5 was done on March 7, 2011. The tasks option was added to org-mode on March 30, 2011. So you will need to upgrade to take advantage of it. Nick
Re: [O] odt export to google-docs problem
Suvayu/Rustom suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Jambunathan, On Thu, Nov 17, 2011 at 11:06, Jambunathan K kjambunat...@gmail.com wrote: Can anyone else reproduce this? I can replicate this. The odt file exported by org-odt is not accepted by google docs even though libreoffice opens it without problems. However it I open it with libreoffice and say edit and save, google docs then accepts the new file. With my some experimentation, I am able to reproduce it now. I have this in my .emacs. , | (setq org-export-odt-prettify-xml t) ` and it was preventing me to see the problem in the first place. The above variable is a custom variable and when it is true, the exporter runs indent-region on all xml files that is part of the final odt file. The default setting of this variable if off, btw, (as otherwise it could slow things down for large exported files.) Since I often have to examine the xml, I have this variable on. This setting helps exporting to google directly i.e., I don't have to edit and resave the file for succesful loading, as Suvayu is suggesting. Indentation only makes whitespace changes and it shouldn't affect how XML files are read in. So, I am unable to explain why Google accepts the indented XML file and not the original one. Anyways turn that variable on and let me know what you see. ps: It seems like there is a bug on Google side of things. Since it only says the file is corrupt and not what the *actual* corruption is I am out of my wits. So basically I am shooting in the dark ... Thanks for helping out here. May be as time progresses an understanding will emerge. I have attached both odt files along with the org file. PS: tested with minimal Emacs 24 and org release_7.7-543-g176ddba --
Re: [O] Problem compiling C++ in Org-mode
Michael Hannon jm_han...@yahoo.com writes: Greetings. I'm having a problem compiling a C++ source-code block in Org-mode. The same C++ code compiles and runs in the shell. The issue seems to relate to local include files. [...snip...] What am I missing? /tmp/babel-245846_d/C-src-24584NIQ.cpp:7:26: fatal error: OtherStuff.cpp: No such file or directory compilation terminated. /bin/bash: /tmp/babel-245846_d/C-bin-24584aSW: Permission denied Compilation is taking place in a temporary directory, miles away from where your org file lives. ## Org-mode compile uses same option as shell compile: org-babel-C++-compiler is a variable defined in `ob-C.el'. Its value is g++ -std=c++0x The current directory is not specified in the include path. You would need to add a -I option to set the (absolute path to the) directory the org file is in. If you have all your org files in ~/org, you could try g++ -std=c++0x -I~/org. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[O] 24.0.91; Emacs runtime crashes while exporting an org file
Summary: 24.0.91; Emacs runtime crashes while exporting with org-latex 1. Start Emacs with -Q 2. Open the attached .org file 3. C-c C-e l (l as in latex) 4. See that Emacs crashes I am using the Windows build downloaded from alpha.gnu.org. I don't know how to attach debugger to the Emacs build. If no one is able to reproduce the crash, I can try attaching a debugger. ps: The crash can be seen with git version of orgmode as well and manifests itself even during html export. In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-15 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.6) --no-opt --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags -LD:/devel/emacs/libs/gnutls-2.10.1/lib' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENG value of $XMODIFIERS: nil locale-coding-system: cp1252 default enable-multibyte-characters: t #+TITLE: zotero.org #+AUTHOR:Jambunathan K #+EMAIL: kjambunat...@gmail.com #+DATE: 2011-11-16 Wed #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t #+OPTIONS: TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: #+XSLT: * Zotero links as footnotes This is a footnote-style citation[fn:1]. Here the Zotero link will be formatted in to a Citation Block. * Footnotes [fn:1] [[http://www.google.com]]
