Re: [O] New exporter and dates in tables
OK, thank you. - Carsten On 9.8.2013, at 13:02, Bernt Hansen be...@norang.ca wrote: Hi Carsten! All of my headings are followed by an inactive timestamp. I've started leaving a blank line before the content for the heading so the inactive timestamp is not exported when timestamps are disabled with the :nil option. This works fine for me. Regards, Bernt Carsten Dominik carsten.domi...@gmail.com writes: Hi guys, did you arrive at a conclusion of this thread, or is this still open? Thanks - Carsten On 16.4.2013, at 09:48, Bastien b...@gnu.org wrote: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: We can widen the definition of `standalone': a standalone timestamp is a timestamp belonging to a paragraph that contains only timestamps objects. Great. If that's possible, then I think that's the best solution. The following patch should do that. It comes with tests, but it should be tested extensively, if only to know if this feature is as useful as it seems. I think I nailed down the root of the confusion. org-export-with-planning does the job that org-export-with-timestamps used to do. So first of all, org-export-with-timestamps should be an alias to org-export-with-planning so that users who customized org-export-with-timestamps don't have to change their customization: (define-obsolete-variable-alias 'org-export-with-timestamps 'org-export-with-planning 24.4) Today, org-export-with-timestamps does a completely different job, more fine-grained than the old org-export-with-timestamps. I suggest to rename it to org-export-with-individual-timestamps and to use the latest patch you sent, with a default value of t. I expect the next useful value is 'not-standalone. But if someone wants to get rid of time-stamps in tables or in lists, he now can. Note that another option is to allow all timestamps, put timestamps you don't want to export in a specific drawer (e.g. TIME), and ignore this drawer during export. Yes, but that requires educating users, which I don't really like. Thanks, -- Bastien
Re: [O] New exporter and dates in tables
Hi guys, did you arrive at a conclusion of this thread, or is this still open? Thanks - Carsten On 16.4.2013, at 09:48, Bastien b...@gnu.org wrote: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: We can widen the definition of `standalone': a standalone timestamp is a timestamp belonging to a paragraph that contains only timestamps objects. Great. If that's possible, then I think that's the best solution. The following patch should do that. It comes with tests, but it should be tested extensively, if only to know if this feature is as useful as it seems. I think I nailed down the root of the confusion. org-export-with-planning does the job that org-export-with-timestamps used to do. So first of all, org-export-with-timestamps should be an alias to org-export-with-planning so that users who customized org-export-with-timestamps don't have to change their customization: (define-obsolete-variable-alias 'org-export-with-timestamps 'org-export-with-planning 24.4) Today, org-export-with-timestamps does a completely different job, more fine-grained than the old org-export-with-timestamps. I suggest to rename it to org-export-with-individual-timestamps and to use the latest patch you sent, with a default value of t. I expect the next useful value is 'not-standalone. But if someone wants to get rid of time-stamps in tables or in lists, he now can. Note that another option is to allow all timestamps, put timestamps you don't want to export in a specific drawer (e.g. TIME), and ignore this drawer during export. Yes, but that requires educating users, which I don't really like. Thanks, -- Bastien
Re: [O] New exporter and dates in tables
Hi Carsten! All of my headings are followed by an inactive timestamp. I've started leaving a blank line before the content for the heading so the inactive timestamp is not exported when timestamps are disabled with the :nil option. This works fine for me. Regards, Bernt Carsten Dominik carsten.domi...@gmail.com writes: Hi guys, did you arrive at a conclusion of this thread, or is this still open? Thanks - Carsten On 16.4.2013, at 09:48, Bastien b...@gnu.org wrote: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: We can widen the definition of `standalone': a standalone timestamp is a timestamp belonging to a paragraph that contains only timestamps objects. Great. If that's possible, then I think that's the best solution. The following patch should do that. It comes with tests, but it should be tested extensively, if only to know if this feature is as useful as it seems. I think I nailed down the root of the confusion. org-export-with-planning does the job that org-export-with-timestamps used to do. So first of all, org-export-with-timestamps should be an alias to org-export-with-planning so that users who customized org-export-with-timestamps don't have to change their customization: (define-obsolete-variable-alias 'org-export-with-timestamps 'org-export-with-planning 24.4) Today, org-export-with-timestamps does a completely different job, more fine-grained than the old org-export-with-timestamps. I suggest to rename it to org-export-with-individual-timestamps and to use the latest patch you sent, with a default value of t. I expect the next useful value is 'not-standalone. But if someone wants to get rid of time-stamps in tables or in lists, he now can. Note that another option is to allow all timestamps, put timestamps you don't want to export in a specific drawer (e.g. TIME), and ignore this drawer during export. Yes, but that requires educating users, which I don't really like. Thanks, -- Bastien
Re: [O] [New Exporter] org-export-latex-after-initial-vars-hook
Nicolas Goaziou address@hidden writes: Søren Mikkelsen address@hidden writes: * But I have a problem with the exporter:* ** * I have modified by org-exporter to export latex-files with the xelatex* * compiler. The implementation uses the* * org-export-latex-after-initial-vars-hook-hook to reconfigure the* * default process, however, this hook seems to be deleted and I'm not* * able to find equivalent hook.* Isn't it sufficient to customize `org-latex-pdf-process' so it uses xelatex? I assume Søren is using a similar snippet [1] as I do which is very convenient (credit goes to Bruno Tavernier). This approach lets you specify a #+LATEX_CMD (think of xelatex, -shell-escape, etc.) on a per file basis and allows LaTeX package 'injection'. Is there a hook that is run before actual LaTeX export of a given org-mode buffer in the new exporter engine? [1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-10/msg00218.html
Re: [O] [New Exporter] org-export-latex-after-initial-vars-hook
To minimize risk of eye cancer (previous version was sent from gmail web interface at work without plain text setting) here it goes again: Nicolas Goaziou address@hidden writes: Søren Mikkelsen address@hidden writes: But I have a problem with the exporter: I have modified by org-exporter to export latex-files with the xelatex compiler. The implementation uses the org-export-latex-after-initial-vars-hook-hook to reconfigure the default process, however, this hook seems to be deleted and I'm not able to find equivalent hook. Isn't it sufficient to customize `org-latex-pdf-process' so it uses xelatex? I assume Søren is using a similar snippet [1] as I do which is very convenient (credit goes to Bruno Tavernier). This approach lets you specify a #+LATEX_CMD (think of xelatex, -shell-escape, etc.) on a per file basis and allows LaTeX package 'injection'. Is there a hook that is run before actual LaTeX export of a given org-mode buffer in the new exporter engine? [1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-10/msg00218.html
Re: [O] [New Exporter] org-export-latex-after-initial-vars-hook
Is there a hook that is run before actual LaTeX export of a given org-mode buffer in the new exporter engine? For reference: I got it to work by adapting the snippet from Bruno Tavernier[1]: #+begin_src emacs-lisp (defun my-auto-tex-cmd (backend) When exporting from .org with latex, automatically run latex, pdflatex, or xelatex as appropriate, using latexmk. (let ((texcmd)) (setq texcmd latexmk -pdf %f) (if (string-match LATEX_CMD: pdflatex (buffer-string)) (setq texcmd latexmk -pdflatex=pdflatex -pdf %f)) (if (string-match LATEX_CMD: pdflatex-shell-escape (buffer-string)) (setq texcmd latexmk -pdflatex=pdflatex --shell-escape -pdf %f)) (if (string-match LATEX_CMD: xelatex (buffer-string)) (setq texcmd latexmk -pdflatex=xelatex -pdf %f)) (setq org-latex-pdf-process (list texcmd (add-hook 'org-export-before-parsing-hook 'my-auto-tex-cmd) #+end_src One thing that tripped me up initially was the requirement for the function to accept exactly one argument (unused in this case). [1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-10/msg00218.html
Re: [O] {New exporter] What happened to the export template
Hi Robert, Robert Goldman rpgold...@sift.info writes: A very late follow-up: I note that the Worg instructions for HTML export still cite org-insert-export-options-template: http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html Can you fix this? Please send me your public key if you don't have access to Worg already, I'll give you push access. Thanks in advance! -- Bastien
Re: [O] {New exporter] What happened to the export template
A very late follow-up: I note that the Worg instructions for HTML export still cite org-insert-export-options-template: http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html
Re: [O] [new exporter] how can I export drawers?
On 2.5.2013, at 21:28, Eric S Fraga e.fr...@ucl.ac.uk wrote: Carsten Dominik carsten.domi...@gmail.com writes: [...] Hi Eric, I can see that this must be painful, so you are one of the people who suffer from this more that others. On the other hand, this also makes you an asset for Org-mode, because you keep testing the exporter in many different ways. I hope that you can stay patient and keep reporting problems - by the end of this you will have your complete environment working and the exporter will have gotten better. Hi Carsten, Sorry! I did not mean to come across as complaining at all. You did not, I wanted to tell you that your input is appreciated. Cheers - Carsten I have been stressed every so often lately because of the move to the new exporter but *nobody* forced me to move over when I did. I am obviously a masochist at heart ;-) I track the git version to make life interesting... To be clear: yes, the move to the new exporter has caused me a few problems but none of the problems has been to the point that I have regretted basing so much of my work on org. Org has transformed, in a very positive way, quite a few aspects of both my work and personal lives and I owe much to you and everybody else that has contributed to org. If I can contribute by testing at the bleeding edge, I am happy that at least I am making some contribution. I wish I had the time and expertise (in Emacs Lisp) to contribute more. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-60-g713208
Re: [O] [new exporter] how can I export drawers?
Carsten Dominik carsten.domi...@gmail.com writes: You did not, I wanted to tell you that your input is appreciated. Thanks! -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-67-gc36435
Re: [O] [new exporter] how can I export drawers?
On 1.5.2013, at 14:28, Eric S Fraga e.fr...@ucl.ac.uk wrote: Thomas S. Dye t...@tsdye.com writes: Hi Eric, I haven't been following closely, so I'm just checking that you're aware of a new variable org-export-allow-bind-keywords, which could play a role in the behavior you are seeing. Thanks Tom. I am indeed aware of this variable. And it usually works. For some reason, some times the bindings are ignored but not in any consistent manner. I am going to keep trying to see if I can come up with an example that is reproducible but so far no luck! I should add that, generally, the new exporter is excellent. My problem has been that I have so many documents on the go (from slides to papers, memos, minutes and notes) that the conversion process from old to new exporter is causing me a bit of stress. Typically, when I re-visit a document that was prepared with the old exporter, it's because I need it *now* and I rush into making the changes that are needed for the new exporter... :( Obviously, I need to use org more effectively for my time management ;-) Hi Eric, I can see that this must be painful, so you are one of the people who suffer from this more that others. On the other hand, this also makes you an asset for Org-mode, because you keep testing the exporter in many different ways. I hope that you can stay patient and keep reporting problems - by the end of this you will have your complete environment working and the exporter will have gotten better. Thanks! - Carsten Anyway, I have just submitted a paper for publication, written entirely in org (+babel), including all the data processing, figure generation, etc. Org is a brilliant tool all around! Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.1-60-gcb6284
Re: [O] [new exporter] how can I export drawers?
Carsten Dominik carsten.domi...@gmail.com writes: [...] Hi Eric, I can see that this must be painful, so you are one of the people who suffer from this more that others. On the other hand, this also makes you an asset for Org-mode, because you keep testing the exporter in many different ways. I hope that you can stay patient and keep reporting problems - by the end of this you will have your complete environment working and the exporter will have gotten better. Hi Carsten, Sorry! I did not mean to come across as complaining at all. I have been stressed every so often lately because of the move to the new exporter but *nobody* forced me to move over when I did. I am obviously a masochist at heart ;-) I track the git version to make life interesting... To be clear: yes, the move to the new exporter has caused me a few problems but none of the problems has been to the point that I have regretted basing so much of my work on org. Org has transformed, in a very positive way, quite a few aspects of both my work and personal lives and I owe much to you and everybody else that has contributed to org. If I can contribute by testing at the bleeding edge, I am happy that at least I am making some contribution. I wish I had the time and expertise (in Emacs Lisp) to contribute more. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-60-g713208
Re: [O] [new exporter] how can I export drawers?
Thomas S. Dye t...@tsdye.com writes: Hi Eric, I haven't been following closely, so I'm just checking that you're aware of a new variable org-export-allow-bind-keywords, which could play a role in the behavior you are seeing. Thanks Tom. I am indeed aware of this variable. And it usually works. For some reason, some times the bindings are ignored but not in any consistent manner. I am going to keep trying to see if I can come up with an example that is reproducible but so far no luck! I should add that, generally, the new exporter is excellent. My problem has been that I have so many documents on the go (from slides to papers, memos, minutes and notes) that the conversion process from old to new exporter is causing me a bit of stress. Typically, when I re-visit a document that was prepared with the old exporter, it's because I need it *now* and I rush into making the changes that are needed for the new exporter... :( Obviously, I need to use org more effectively for my time management ;-) Anyway, I have just submitted a paper for publication, written entirely in org (+babel), including all the data processing, figure generation, etc. Org is a brilliant tool all around! Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.1-60-gcb6284
Re: [O] [new exporter] how can I export drawers?
Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: I am going a little crazy here! I have an org document which I need to export to PDF using latex. Everything works just fine with the new exporter except for one thing: I cannot get it to export drawers. I have set org-export-with-drawers to t, I have set d:t in the OPTIONS line, I have defined org-latex-format-drawer-function as described in the documentation. None of this has made any difference. Now, having looked at the code, it almost seems that there is no such functionality? Grepping for org-export-with-drawers only brings up three lines in all of lisp/*.el, none of which does anything with this variable. Is there any way to export drawers (LOGBOOK in my case)? I don't understand your problem. Drawers are correctly exported here. Could you provided an ECM? Regards, -- Nicolas Goaziou
Re: [O] [new exporter] how can I export drawers?
Hello, Thorsten Jolitz tjol...@gmail.com writes: I would like to be able to export drawers to ASCII too, although, as Nicolas mentioned in an earlier thread, the ascii exporter currently does not handle this. Did I say that? AFAICT, drawers are correctly exported in ASCII export. Regards, -- Nicolas Goaziou
Re: [O] [new exporter] how can I export drawers?
Nicolas Goaziou n.goaz...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: I would like to be able to export drawers to ASCII too, although, as Nicolas mentioned in an earlier thread, the ascii exporter currently does not handle this. Did I say that? AFAICT, drawers are correctly exported in ASCII export. You are right, that thread was about property-drawers, drawers are actually exported to ASCII with '#+OPTIONS: d:t'. -- cheers, Thorsten
Re: [O] [new exporter] how can I export drawers?
Nicolas Goaziou n.goaz...@gmail.com writes: [...] I don't understand your problem. Drawers are correctly exported here. Could you provided an ECM? Arggghhh. An ECM I just created works just fine. There's obviously something obscurely wrong in my long document that prevents drawers from being exported. I will play around more... sorry for the noise. thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.1-60-gcb6284
Re: [O] [new exporter] how can I export drawers?
Nicolas, further on this: I got my original document working. I had a d:nil line hidden away in the document which took precedence over my other attempts to ask for drawers to be exported. Sorry about bothering everybody with this. However, I am still having some strange random behaviour to do with BIND and multiple invocations of export. I use BIND to change the formatting for active and inactive time stamps on latex export and it works sometimes but is ignored other times. I've not figured out a deterministic recipe to have this consistently repeatable yet but, if and when I do, I will post here. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0-alpha-307-g3a0e55.dirty
Re: [O] [new exporter] how can I export drawers?
Hi Eric, I haven't been following closely, so I'm just checking that you're aware of a new variable org-export-allow-bind-keywords, which could play a role in the behavior you are seeing. hth, Tom Eric S Fraga e.fr...@ucl.ac.uk writes: Nicolas, further on this: I got my original document working. I had a d:nil line hidden away in the document which took precedence over my other attempts to ask for drawers to be exported. Sorry about bothering everybody with this. However, I am still having some strange random behaviour to do with BIND and multiple invocations of export. I use BIND to change the formatting for active and inactive time stamps on latex export and it works sometimes but is ignored other times. I've not figured out a deterministic recipe to have this consistently repeatable yet but, if and when I do, I will post here. Thanks again, eric -- Thomas S. Dye http://www.tsdye.com
[O] [New Exporter] org-export-latex-after-initial-vars-hook
Hello, I have just upgraded to the Org 8.0. Nice work! :) But I have a problem with the exporter: I have modified by org-exporter to export latex-files with the xelatex compiler. The implementation uses the org-export-latex-after-initial-vars-hook-hook to reconfigure the default process, however, this hook seems to be deleted and I'm not able to find equivalent hook. Cheers, Søren
Re: [O] [New Exporter] org-export-latex-after-initial-vars-hook
Hello, Søren Mikkelsen so...@aamikkelsen.dk writes: But I have a problem with the exporter: I have modified by org-exporter to export latex-files with the xelatex compiler. The implementation uses the org-export-latex-after-initial-vars-hook-hook to reconfigure the default process, however, this hook seems to be deleted and I'm not able to find equivalent hook. Isn't it sufficient to customize `org-latex-pdf-process' so it uses xelatex? Regards, -- Nicolas Goaziou
[O] [new exporter] how can I export drawers?
Hello, I am going a little crazy here! I have an org document which I need to export to PDF using latex. Everything works just fine with the new exporter except for one thing: I cannot get it to export drawers. I have set org-export-with-drawers to t, I have set d:t in the OPTIONS line, I have defined org-latex-format-drawer-function as described in the documentation. None of this has made any difference. Now, having looked at the code, it almost seems that there is no such functionality? Grepping for org-export-with-drawers only brings up three lines in all of lisp/*.el, none of which does anything with this variable. Is there any way to export drawers (LOGBOOK in my case)? Many thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-56-g09167e
Re: [O] [new exporter] how can I export drawers?
Eric S Fraga e.fr...@ucl.ac.uk writes: I am going a little crazy here! I have an org document which I need to export to PDF using latex. [not an answer, but rather a feature request] I would like to be able to export drawers to ASCII too, although, as Nicolas mentioned in an earlier thread, the ascii exporter currently does not handle this. IMO, every exporter should offer the option to export _all_ the info in an Org file (the backend might possibly able to digest). At the moment, when I want to share an Org-file as text with non Org-users, all I can do is save it as .txt file, which results in a complete, but rather unreadable output, expecially when there are many timestamps, tags and drawers involved. -- cheers, Thorsten
Re: [O] New exporter - publishing org files doesn't include :tangle
Hello, Bernt Hansen be...@norang.ca writes: So far my attempts using this workaround have failed and I can't get :tangle in my exported org file. I think I also would prefer to have the :exports value in the .org source as well so it's a true representation of the source. There was a bug in org back-end: affiliated keywords were removed. I fixed it. Does it solve your problem (using the workaround)? Regards, -- Nicolas Goaziou
Re: [O] New exporter - publishing org files doesn't include :tangle
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: So far my attempts using this workaround have failed and I can't get :tangle in my exported org file. I think I also would prefer to have the :exports value in the .org source as well so it's a true representation of the source. There was a bug in org back-end: affiliated keywords were removed. I fixed it. Does it solve your problem (using the workaround)? Thanks! I'll try again tonight and let you know. -Bernt
Re: [O] New exporter - publishing org files doesn't include :tangle
Bernt Hansen be...@norang.ca writes: Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: So far my attempts using this workaround have failed and I can't get :tangle in my exported org file. I think I also would prefer to have the :exports value in the .org source as well so it's a true representation of the source. There was a bug in org back-end: affiliated keywords were removed. I fixed it. Does it solve your problem (using the workaround)? Thanks! I'll try again tonight and let you know. -Bernt Yes I think this now works. The :exports details are missing but it's usable for generating a emacs.el file now from the document. Thanks! Bernt
Re: [O] New exporter - publishing org files doesn't include :tangle
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: James Yuan noticed that the .org file that is published with my document (http://doc.norang.ca/org-mode.org does not contain :tangle on any of the source blocks. One of the uses of this document is to pull up the file and tangle it to create an emacs configuration but this seems to be broken in 8.0. This is not directly related to the export framework. For some reason, Babel removes all properties from the opening string of a block when evaluated. IOW #+BEGIN_SRC emacs-lisp :exports code :tangle yes (+ 1 1) #+END_SRC becomes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC One workaround is to add Babel properties on a #+header: affiliated keyword instead as #+header: :tangle yes #+BEGIN_SRC emacs-lisp :exports code (+ 1 1) #+END_SRC becomes #+header: :tangle yes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC Regards, Hi Nick, So far my attempts using this workaround have failed and I can't get :tangle in my exported org file. I think I also would prefer to have the :exports value in the .org source as well so it's a true representation of the source. I'll give this another try again later. Regards, Bernt
[O] New exporter - publishing org files doesn't include :tangle
Hi Nicolas, James Yuan noticed that the .org file that is published with my document (http://doc.norang.ca/org-mode.org does not contain :tangle on any of the source blocks. One of the uses of this document is to pull up the file and tangle it to create an emacs configuration but this seems to be broken in 8.0. I'm using --8---cut here---start-8--- :publishing-function (org-html-publish-to-html org-org-publish-to-org) --8---cut here---end---8--- Regards, Bernt
Re: [O] New exporter - publishing org files doesn't include :tangle
Hello, Bernt Hansen be...@norang.ca writes: James Yuan noticed that the .org file that is published with my document (http://doc.norang.ca/org-mode.org does not contain :tangle on any of the source blocks. One of the uses of this document is to pull up the file and tangle it to create an emacs configuration but this seems to be broken in 8.0. This is not directly related to the export framework. For some reason, Babel removes all properties from the opening string of a block when evaluated. IOW #+BEGIN_SRC emacs-lisp :exports code :tangle yes (+ 1 1) #+END_SRC becomes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC One workaround is to add Babel properties on a #+header: affiliated keyword instead as #+header: :tangle yes #+BEGIN_SRC emacs-lisp :exports code (+ 1 1) #+END_SRC becomes #+header: :tangle yes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC Regards, -- Nicolas Goaziou
Re: [O] New exporter - publishing org files doesn't include :tangle
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: James Yuan noticed that the .org file that is published with my document (http://doc.norang.ca/org-mode.org does not contain :tangle on any of the source blocks. One of the uses of this document is to pull up the file and tangle it to create an emacs configuration but this seems to be broken in 8.0. This is not directly related to the export framework. For some reason, Babel removes all properties from the opening string of a block when evaluated. IOW #+BEGIN_SRC emacs-lisp :exports code :tangle yes (+ 1 1) #+END_SRC becomes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC One workaround is to add Babel properties on a #+header: affiliated keyword instead as #+header: :tangle yes #+BEGIN_SRC emacs-lisp :exports code (+ 1 1) #+END_SRC becomes #+header: :tangle yes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC Regards,
Re: [O] New exporter - publishing org files doesn't include :tangle
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: James Yuan noticed that the .org file that is published with my document (http://doc.norang.ca/org-mode.org does not contain :tangle on any of the source blocks. One of the uses of this document is to pull up the file and tangle it to create an emacs configuration but this seems to be broken in 8.0. This is not directly related to the export framework. For some reason, Babel removes all properties from the opening string of a block when evaluated. IOW #+BEGIN_SRC emacs-lisp :exports code :tangle yes (+ 1 1) #+END_SRC becomes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC One workaround is to add Babel properties on a #+header: affiliated keyword instead as #+header: :tangle yes #+BEGIN_SRC emacs-lisp :exports code (+ 1 1) #+END_SRC becomes #+header: :tangle yes #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC Thanks, I'll give that a try. I think this used to work but as long as I can get the same behaviour with your workaround that's fine with me. Regards, Bernt
Re: [O] New Exporter: plain list depth
Hi, At Mon, 22 Apr 2013 00:10:25 +0200, Nicolas Goaziou wrote: Yasushi SHOJI ya...@atmark-techno.com writes: To generate -- at the list 2.1, I'd like to find out the list 2.1 is at depth 2, so that I can use (make-string 2 ?-) for my bullet. Something like the following should work, assuming ITEM is the item element you have to transcode: #+begin_src emacs-lisp (let ((parent item) (depth 0)) (while (and (setq parent (org-export-get-parent parent)) (case (org-element-type parent) (item t) (plain-list (incf depth) depth) #+end_src Thanks! will try based on your advice. Does org-list-to-generic work in this situation? As a good rule of thumb, it's best to rely on tools provided in ox.el. ok. regards, -- yashi
[O] New Exporter: plain list depth
Hi, What is the best way to know the depth of list entries when I writing an exporter back-end? let's say I have: #+BEGIN_SRC org * headline 1 - list 1 - list 2 - list 2.1 #+END_SRC I'd like to convert it to: #+BEGIN_EXAMPLE * headline 1 - list 1 - list 2 -- list 2.1 #+END_EXAMPLE To generate -- at the list 2.1, I'd like to find out the list 2.1 is at depth 2, so that I can use (make-string 2 ?-) for my bullet. What I came up with instead was to 1) mark each item in item handler with - 2) add a - in each plain-list handler 3) remove one - from all list entries at final-function it works, but it doesn't look good to me (tm). I've checked a few exporters, including ox-html and ox-md but couldn't find a function like org-export-get-relative-level for headline. Does org-list-to-generic work in this situation? Thanks, -- yashi
Re: [O] New Exporter: plain list depth
Hello, Yasushi SHOJI ya...@atmark-techno.com writes: What is the best way to know the depth of list entries when I writing an exporter back-end? let's say I have: #+BEGIN_SRC org * headline 1 - list 1 - list 2 - list 2.1 #+END_SRC I'd like to convert it to: #+BEGIN_EXAMPLE * headline 1 - list 1 - list 2 -- list 2.1 #+END_EXAMPLE To generate -- at the list 2.1, I'd like to find out the list 2.1 is at depth 2, so that I can use (make-string 2 ?-) for my bullet. Something like the following should work, assuming ITEM is the item element you have to transcode: #+begin_src emacs-lisp (let ((parent item) (depth 0)) (while (and (setq parent (org-export-get-parent parent)) (case (org-element-type parent) (item t) (plain-list (incf depth) depth) #+end_src Does org-list-to-generic work in this situation? As a good rule of thumb, it's best to rely on tools provided in ox.el. Regards, -- Nicolas Goaziou
Re: [O] New exporter and defgroup
Hi, yes, this *is* a problem. Suvayu Ali fatkasuvayu+li...@gmail.com writes: Can we have some sort of a check while loading Org that picks up these shadowed variables and deletes them? I think Achim has been thinking about some incantation for this (at install time). Maybe if this can be done after installation, we could document it somewhere... not really sure. I didn't want to change defgroup, it would have been confusing to have to groups for the same purpose -- with no real clue on which one was the most recent one. -- Bastien
Re: [O] New exporter and defgroup
Bastien writes: Can we have some sort of a check while loading Org that picks up these shadowed variables and deletes them? I think Achim has been thinking about some incantation for this (at install time). Maybe if this can be done after installation, we could document it somewhere... not really sure. It would have to be done each time Org is loaded. Unfortunately Emacs doesn't provide an interface for removing such definitions, so you'd have to traverse a number of not-too-well documented data structures to get rid of them. I'm still not sure I found all of these nor if there are adverse effects of doing that. Eric Frage (IIRC) was testing a rough version of what I was trying to do, he reported he was seeing problems that he wanted to investigate further. Now, with the dust from all the other changes settling, we might pick up where we left before: --8---cut here---start-8--- ;; ;; Kill our ancestors ;; ;; clean load-path (setq load-path (delq nil (mapcar (function (lambda (p) (unless (string-match lisp/org$ p) p)) load-path))) ;; remove property list to defeat cus-load and remove autoloads (mapatoms (function (lambda (s) (let ((sn (symbol-name s))) (when (string-match ^\\(org\\|ob\\|ox\\)-? sn) (setplist s nil) (when (autoloadp s) (unintern s))) (add-to-list 'load-path /path/to/org) (load org-loaddefs.el nil nil 'nosuffix) --8---cut here---end---8--- This assumes it is run before any Org functions have been used and makes no attempt to check if that's true. Another unverified assumption is that nothing has polluted the namespaces that Org uses. 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
[O] New exporter and defgroup
Hi all The new exporter engine has changed the defcustom names but seems to have kept the names of the defgroups (at least in the case of taskjuggler). This is good as it allowed me to make some backward-incompatible changes. On the other hand when I do a M-x customize-group RET org-export-taskjuggler I get a list of both the old defcustom vars and the new ones. This is very confusing to the user as you appear to have the same cutomizable var twice in the group. Is this a problem with my setup or is this inherent in the new exporter. If the latter how can we deal with this? Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] New exporter and defgroup
Hi Christian, On Fri, Apr 19, 2013 at 02:52:46PM +0200, Christian Egli wrote: Hi all The new exporter engine has changed the defcustom names but seems to have kept the names of the defgroups (at least in the case of taskjuggler). This is good as it allowed me to make some backward-incompatible changes. On the other hand when I do a M-x customize-group RET org-export-taskjuggler I get a list of both the old defcustom vars and the new ones. This is very confusing to the user as you appear to have the same cutomizable var twice in the group. Is this a problem with my setup or is this inherent in the new exporter. If the latter how can we deal with this? I think I have seen this before. Those old variables come from the shadowed older version of Org bundled with Emacs. Not sure if this can be avoided. Can we have some sort of a check while loading Org that picks up these shadowed variables and deletes them? My lisp foo is too bad to know if this is even possible. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] New exporter and dates in tables
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: We can widen the definition of `standalone': a standalone timestamp is a timestamp belonging to a paragraph that contains only timestamps objects. Great. If that's possible, then I think that's the best solution. The following patch should do that. It comes with tests, but it should be tested extensively, if only to know if this feature is as useful as it seems. I think I nailed down the root of the confusion. org-export-with-planning does the job that org-export-with-timestamps used to do. So first of all, org-export-with-timestamps should be an alias to org-export-with-planning so that users who customized org-export-with-timestamps don't have to change their customization: (define-obsolete-variable-alias 'org-export-with-timestamps 'org-export-with-planning 24.4) Today, org-export-with-timestamps does a completely different job, more fine-grained than the old org-export-with-timestamps. I suggest to rename it to org-export-with-individual-timestamps and to use the latest patch you sent, with a default value of t. I expect the next useful value is 'not-standalone. But if someone wants to get rid of time-stamps in tables or in lists, he now can. Note that another option is to allow all timestamps, put timestamps you don't want to export in a specific drawer (e.g. TIME), and ignore this drawer during export. Yes, but that requires educating users, which I don't really like. Thanks, -- Bastien
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: The following patch should do that. It comes with tests, but it should be tested extensively, if only to know if this feature is as useful as it seems. Thanks a lot. I will not be online for the next 5 hours, but I'll think about this. -- Bastien
Re: [O] New exporter and dates in tables
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: I would find it both cleaner and more useful for users to extend `org-export-with-timestamps' with three choices: 'inactive-not-standalone 'active-not-standalone 'not-standalone This is a different idea. The change would happen at the exporter level, not at parser's. Yes. If we agree to the alone in a paragraph part, I can implement it. But we still need exceptions for clocks and timestamps (i.e., ignore `org-export-with-timestamps' value when `org-export-with-planning' or `org-export-with-clocks' is non-nil). Let's not implement my proposal and stick to your implementation of the exceptions you first proposed. I expect users will want a way to get rid of time-stamp in * Task time-stamp without getting rid of time-stamps in paragraphs, but this can be tackled later on I guess. Thanks, -- Bastien
Re: [O] New exporter and dates in tables
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Wouldn't it be a good moment to introduce APPT: 2013-04-13 Sat or maybe better named EVENT: 2013-04-13 Sat for things that only apply for today? In master, there is the new agenda entry type :scheduled* and the new agenda type agenda*. So you can have an agenda* view with a local value of `org-scheduled-past-days' set to 0: this will list appointments (i.e. a scheduled item with an hour) only on the date they are set. PS: Wrt the good moment pattern, I think we abused it already too much: just because there is a big release to come does not mean we should include more big changes. I'm guilty of indulging too much in this direction... so I'm now more cautious. Especially when the change is quite orthogonal to other features, in which case there is no problem for waiting another release. -- Bastien
Re: [O] New exporter and dates in tables
Hello, Bastien b...@gnu.org writes: Let's not implement my proposal and stick to your implementation of the exceptions you first proposed. Before we throw the baby out with the bath water, I want to make sure we are understanding each other. I expect users will want a way to get rid of time-stamp in * Task time-stamp without getting rid of time-stamps in paragraphs, but this can be tackled later on I guess. According to your suggestion, with `org-export-with-timestamps' set to `not-standalone', in the following example: --8---cut here---start-8--- * Task timestamp At timestamp, I must do that. --8---cut here---end---8--- the first timestamp would be ignored, not the second one. Isn't it what you want? Also, we can do it the TDD way: just throw in a bunch of examples and we'll come up with an implementation that conforms to all of them (if they are reasonable enough). Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: According to your suggestion, with `org-export-with-timestamps' set to `not-standalone', in the following example: * Task timestamp At timestamp, I must do that. the first timestamp would be ignored, not the second one. Isn't it what you want? Yes, exactly. -- Bastien
Re: [O] New exporter and dates in tables
Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: According to your suggestion, with `org-export-with-timestamps' set to `not-standalone', in the following example: * Task timestamp At timestamp, I must do that. the first timestamp would be ignored, not the second one. Isn't it what you want? Yes, exactly. Then why do you suggest to drop the idea (for now)? Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: Then why do you suggest to drop the idea (for now)? Because IIUC, the time-stamps would not be ignored here * Task 2013-04-14 dim. 2013-04-16 dim. because 2013-04-14 dim. 2013-04-16 dim. is a paragraph. (The agenda takes both time-stamps into account in a simple `org-agenda-list'.) If we can remove the one-time-stamp only case, but not the case with two, it is too confusing IMHO. What do you think? -- Bastien
Re: [O] New exporter and dates in tables
Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: Then why do you suggest to drop the idea (for now)? Because IIUC, the time-stamps would not be ignored here * Task 2013-04-14 dim. 2013-04-16 dim. because 2013-04-14 dim. 2013-04-16 dim. is a paragraph. (The agenda takes both time-stamps into account in a simple `org-agenda-list'.) If we can remove the one-time-stamp only case, but not the case with two, it is too confusing IMHO. Correct. What do you think? We can widen the definition of `standalone': a standalone timestamp is a timestamp belonging to a paragraph that contains only timestamps objects. Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: We can widen the definition of `standalone': a standalone timestamp is a timestamp belonging to a paragraph that contains only timestamps objects. Great. If that's possible, then I think that's the best solution. -- Bastien
Re: [O] New exporter and dates in tables
Nicolas You may want to extract the below function as a useful API. You can then plug that in into `org-odt--standalone-link-p' and it's counterpart in ox-html.el. I am not closely tracking changes in ox-html.el, so things might have moved since. Jambunathan K. Nicolas Goaziou n.goaz...@gmail.com writes: + (lambda (ts) + ;; Return a non-nil value when TS is a timestamp object + ;; in a paragraph with only timestamps and whitespaces. + (let ((parent (org-export-get-parent-element ts))) + (when (memq (org-element-type parent) '(paragraph verse-block)) + (not +(org-element-map parent +(cons 'plain-text + (remq 'timestamp org-element-all-objects)) + (lambda (obj) +(or (not (stringp obj)) (org-string-nw-p obj))) + options t)
Re: [O] New exporter and dates in tables
Hello, Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: Thinking more about it, I think I need to make some more exceptions anyway. For example timestamps in clock lines and in planning info shouldn't react to `org-export-with-timestamps' (it would be silly to have `org-export-with-planning' set to t and still see nothing because `org-export-with-timestamps' is nil). Indeed :) Thinking again about Bernt's use-case and Carsten's feedback, I suggest making rules for planning instead of exceptions for time-stamps. - planning information is - SCHEDULED: time-stamp - DEADLINE: time-stamp - CLOSED: time-stamp - one or more time-stamps (active or inactive) alone on a line - a non-planning time-stamp is any time-stamp that does not fall into the categories above, i.e. if it is inlined in an element (usually a paragraph or a table). SCHEDULED and friends define a property in the associated headline. Generic timestamps don't (excepted for the first one, but it's arbitrary and the parser ignores it anyway). Also, there can be as many active timestamps in a section, but there can be only one planning info element. Therefore, I don't think they belong to the same category. We ought to treat them differently, like we do at the moment. The inactive/active time-stamp in a table is handled. And so is another corner case that we did not discussed yet: people using active time-stamps right below a headline, with the expectation that this time-stamp will bring the entry up in the agenda -- such time-stamp is now considered a time-stamp while it is really some planning info. This is obviously some planning info, but not a planning-info element. Any active timestamp is a planning info by the way. The planning-info term just defines the line with SCHEDULED, DEADLINE, CLOSED keyword. It may be silly, be a name had to be chosen. Anyway, I don't think it's a corner case. I guess this is cleaner than creating exceptions. What about it? I'd rather create the aforementioned exceptions (in tables but more importantly in planning info and clocks): it is important to distinguish planning-info from a mere timestamp. We can change the name if it's confusing, though. Is that OK with you? Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: Is that OK with you? I still resist this idea. I would find it both cleaner and more useful for users to extend `org-export-with-timestamps' with three choices: 'inactive-not-standalone 'active-not-standalone 'not-standalone When set to 'not-standalone, it means export time-stamps except standone time-stamps, i.e. those who are alone on a line. That's the set-up most users will want after t, it fits the habits that Bernt has been describing, and it's useful for users who wants to get rid of the planning-like active time-stamp right below the headline. Also, it's easier to explain users how to set this up (through the docstring) than to explain why time-stamps are not removed in tables with (setq org-export-with-timestamps nil). -- Bastien
Re: [O] New exporter and dates in tables
Bastien b...@gnu.org writes: I would find it both cleaner and more useful for users to extend `org-export-with-timestamps' with three choices: 'inactive-not-standalone 'active-not-standalone 'not-standalone This is a different idea. The change would happen at the exporter level, not at parser's. When set to 'not-standalone, it means export time-stamps except standone time-stamps, i.e. those who are alone on a line. Well, parsing is not line based, and a timestamp alone on a line doesn't mean much. Though, a timestamp alone in a paragraph is much easier to translate. IOW: 2013-04-13 Sat is not a standalone timestamp (use M-q). but, 2013-04-13 Sat is a standalone timestamp. That's the set-up most users will want after t, it fits the habits that Bernt has been describing, and it's useful for users who wants to get rid of the planning-like active time-stamp right below the headline. Also, it's easier to explain users how to set this up (through the docstring) than to explain why time-stamps are not removed in tables with (setq org-export-with-timestamps nil). If we agree to the alone in a paragraph part, I can implement it. But we still need exceptions for clocks and timestamps (i.e., ignore `org-export-with-timestamps' value when `org-export-with-planning' or `org-export-with-clocks' is non-nil). Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Hello, Nicolas Goaziou wrote: Bastien b...@gnu.org writes: I would find it both cleaner and more useful for users to extend `org-export-with-timestamps' with three choices: 'inactive-not-standalone 'active-not-standalone 'not-standalone This is a different idea. The change would happen at the exporter level, not at parser's. When set to 'not-standalone, it means export time-stamps except standone time-stamps, i.e. those who are alone on a line. Well, parsing is not line based, and a timestamp alone on a line doesn't mean much. Though, a timestamp alone in a paragraph is much easier to translate. IOW: 2013-04-13 Sat is not a standalone timestamp (use M-q). but, 2013-04-13 Sat is a standalone timestamp. Wouldn't it be a good moment to introduce APPT: 2013-04-13 Sat or maybe better named EVENT: 2013-04-13 Sat for things that only apply for today? Best regards, Seb -- Sebastien Vauban
Re: [O] New exporter and dates in tables
Hello, Bastien b...@gnu.org writes: Note that Org 8.0-pre comes with a new export option `org-export-with-planning' which handles the export of SCHEDULED / DEADLINE / CLOSED time-stamps. This used to be the job of org-export-with-timestamps. I guess many people who used (setq org-export-with-timestamps nil) now want (setq org-export-with-planning nil) and which works well with (setq org-export-with-timestamps 'inactive). So I'm wondering: would the setup above spare us with this exception? I know people sometimes throw inactive time-stamps, but those small indications would better fit in a commented line. WDYT? Thinking more about it, I think I need to make some more exceptions anyway. For example timestamps in clock lines and in planning info shouldn't react to `org-export-with-timestamps' (it would be silly to have `org-export-with-planning' set to t and still see nothing because `org-export-with-timestamps' is nil). After all, this exception may not be that exceptional. Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Hello, Nicolas Goaziou n.goaz...@gmail.com writes: Thinking more about it, I think I need to make some more exceptions anyway. For example timestamps in clock lines and in planning info shouldn't react to `org-export-with-timestamps' (it would be silly to have `org-export-with-planning' set to t and still see nothing because `org-export-with-timestamps' is nil). Indeed :) Thinking again about Bernt's use-case and Carsten's feedback, I suggest making rules for planning instead of exceptions for time-stamps. - planning information is - SCHEDULED: time-stamp - DEADLINE: time-stamp - CLOSED: time-stamp - one or more time-stamps (active or inactive) alone on a line - a non-planning time-stamp is any time-stamp that does not fall into the categories above, i.e. if it is inlined in an element (usually a paragraph or a table). The inactive/active time-stamp in a table is handled. And so is another corner case that we did not discussed yet: people using active time-stamps right below a headline, with the expectation that this time-stamp will bring the entry up in the agenda -- such time-stamp is now considered a time-stamp while it is really some planning info. I guess this is cleaner than creating exceptions. What about it? -- Bastien
Re: [O] New exporter and dates in tables
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
Some people throw in time stamps often while they work, just
as a little label, indicating that they were working on this
at a specific date, or that the entry was created on a specific
date. Many people I know have a hook that throws in such a
time stamp in each new entry created. This creates a lot of
clutter when you print it, which is why you can turn off
export of timestamps.
That option was not meant for a contextual line like your
first example. If you use the time stamps in this way, you
probably will not turn off timestamp export at all, you
will just leave it on. If you mix both ways of using
time stamps - well, too bad.
Tabular data is different because you certainly wanted
that data in the table, so removing it will be confusing.
Anyway, there's still another thing to ponder. Since everything in
a table is data, what happens with tex:nil (LaTeX snippets)? Should
this option also be ignored within a table? If not, how can we explain
the difference with :nil?
Tex macros are different. This is an internal way of
inserting special characters, and that syntax may get into
your way in some specific projects. Just like the fact
that _ creates a subscript. If you have to write text
with lots of _ but you never mean a subscript, this can
be really annoying. So you can turn off subscripts as you
can turn off interpretation of tex macros, as a convenience
if the syntax gets in your way. Then it should be turned
off anywhere, table or not.
Fair enough. The following patch should do as decided in this thread.
WDYT?
Regards,
--
Nicolas Goaziou
From a2b4ef1ad24cbd816491122d0e969fecc6739377 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Wed, 10 Apr 2013 14:38:13 +0200
Subject: [PATCH] ox: Don't skip timestamps within tables
* lisp/ox.el (org-export--skip-p): Never skip a timestamp within
a table.
(org-export-with-timestamps): Update docstring accordingly.
* testing/lisp/test-ox.el: Add test.
---
lisp/ox.el | 32 +++-
testing/lisp/test-ox.el | 7 ++-
2 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 7f33755..a9667d9 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -721,6 +721,9 @@ It can be set to `active', `inactive', t or nil, in order to
export, respectively, only active timestamps, only inactive ones,
all of them or none.
+This variable has no effect on timestamps within tables, which
+will always be exported.
+
This option can also be set with the OPTIONS keyword, e.g.
\:nil\.
:group 'org-export-general
@@ -2013,19 +2016,22 @@ a tree with a select tag.
(not (org-export-get-previous-element blob options
(table-row (org-export-table-row-is-special-p blob options))
(timestamp
- (case (plist-get options :with-timestamps)
- ;; No timestamp allowed.
- ('nil t)
- ;; Only active timestamps allowed and the current one isn't
- ;; active.
- (active
- (not (memq (org-element-property :type blob)
- '(active active-range
- ;; Only inactive timestamps allowed and the current one isn't
- ;; inactive.
- (inactive
- (not (memq (org-element-property :type blob)
- '(inactive inactive-range
+ ;; Timestamps in tables are not affected by `:with-timestamps'.
+ (unless (eq (org-element-type (org-export-get-parent-element blob))
+ 'table-row)
+ (case (plist-get options :with-timestamps)
+ ;; No timestamp allowed.
+ ('nil t)
+ ;; Only active timestamps allowed and the current one isn't
+ ;; active.
+ (active
+ (not (memq (org-element-property :type blob)
+ '(active active-range
+ ;; Only inactive timestamps allowed and the current one isn't
+ ;; inactive.
+ (inactive
+ (not (memq (org-element-property :type blob)
+ '(inactive inactive-range)
;;; The Transcoder
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 6203f8b..0900037 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -408,7 +408,12 @@ Paragraph
2012-04-29 sun. 10:45\n))
(should
(equal (org-export-as 'test nil nil nil '(:with-timestamps inactive))
- [2012-04-29 sun. 10:45]\n)
+ [2012-04-29 sun. 10:45]\n
+ (should
+ (equal | [2012-03-29 Thu] |\n
+ (org-test-with-temp-text | [2012-03-29 Thu] |
+ (org-test-with-backend test
+ (org-export-as 'test nil nil nil '(:with-timestamps nil)))
(ert-deftest test-org-export/comment-tree ()
Test if export process ignores commented trees.
--
1.8.2.1
Re: [O] New exporter and dates in tables
This looks good to me - with my limited understanding of the exporter lingo.
Thanks!
- Carsten
On 10 apr. 2013, at 14:43, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
Some people throw in time stamps often while they work, just
as a little label, indicating that they were working on this
at a specific date, or that the entry was created on a specific
date. Many people I know have a hook that throws in such a
time stamp in each new entry created. This creates a lot of
clutter when you print it, which is why you can turn off
export of timestamps.
That option was not meant for a contextual line like your
first example. If you use the time stamps in this way, you
probably will not turn off timestamp export at all, you
will just leave it on. If you mix both ways of using
time stamps - well, too bad.
Tabular data is different because you certainly wanted
that data in the table, so removing it will be confusing.
Anyway, there's still another thing to ponder. Since everything in
a table is data, what happens with tex:nil (LaTeX snippets)? Should
this option also be ignored within a table? If not, how can we explain
the difference with :nil?
Tex macros are different. This is an internal way of
inserting special characters, and that syntax may get into
your way in some specific projects. Just like the fact
that _ creates a subscript. If you have to write text
with lots of _ but you never mean a subscript, this can
be really annoying. So you can turn off subscripts as you
can turn off interpretation of tex macros, as a convenience
if the syntax gets in your way. Then it should be turned
off anywhere, table or not.
Fair enough. The following patch should do as decided in this thread.
WDYT?
Regards,
--
Nicolas Goaziou
From a2b4ef1ad24cbd816491122d0e969fecc6739377 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Wed, 10 Apr 2013 14:38:13 +0200
Subject: [PATCH] ox: Don't skip timestamps within tables
* lisp/ox.el (org-export--skip-p): Never skip a timestamp within
a table.
(org-export-with-timestamps): Update docstring accordingly.
* testing/lisp/test-ox.el: Add test.
---
lisp/ox.el | 32 +++-
testing/lisp/test-ox.el | 7 ++-
2 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 7f33755..a9667d9 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -721,6 +721,9 @@ It can be set to `active', `inactive', t or nil, in order
to
export, respectively, only active timestamps, only inactive ones,
all of them or none.
+This variable has no effect on timestamps within tables, which
+will always be exported.
+
This option can also be set with the OPTIONS keyword, e.g.
\:nil\.
:group 'org-export-general
@@ -2013,19 +2016,22 @@ a tree with a select tag.
(not (org-export-get-previous-element blob options
(table-row (org-export-table-row-is-special-p blob options))
(timestamp
- (case (plist-get options :with-timestamps)
- ;; No timestamp allowed.
- ('nil t)
- ;; Only active timestamps allowed and the current one isn't
- ;; active.
- (active
- (not (memq (org-element-property :type blob)
-'(active active-range
- ;; Only inactive timestamps allowed and the current one isn't
- ;; inactive.
- (inactive
- (not (memq (org-element-property :type blob)
-'(inactive inactive-range
+ ;; Timestamps in tables are not affected by `:with-timestamps'.
+ (unless (eq (org-element-type (org-export-get-parent-element blob))
+ 'table-row)
+ (case (plist-get options :with-timestamps)
+ ;; No timestamp allowed.
+ ('nil t)
+ ;; Only active timestamps allowed and the current one isn't
+ ;; active.
+ (active
+ (not (memq (org-element-property :type blob)
+ '(active active-range
+ ;; Only inactive timestamps allowed and the current one isn't
+ ;; inactive.
+ (inactive
+ (not (memq (org-element-property :type blob)
+ '(inactive inactive-range)
;;; The Transcoder
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 6203f8b..0900037 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -408,7 +408,12 @@ Paragraph
2012-04-29 sun. 10:45\n))
(should
(equal (org-export-as 'test nil nil nil '(:with-timestamps inactive))
- [2012-04-29 sun. 10:45]\n)
+ [2012-04-29 sun. 10:45]\n
+ (should
+ (equal | [2012-03-29 Thu] |\n
+ (org-test-with-temp-text | [2012-03-29 Thu] |
+ (org-test-with-backend test
+ (org-export-as 'test nil nil nil '(:with-timestamps nil)))
(ert-deftest test-org-export/comment-tree ()
Re: [O] New exporter and dates in tables
Hi all, Note that Org 8.0-pre comes with a new export option `org-export-with-planning' which handles the export of SCHEDULED / DEADLINE / CLOSED time-stamps. This used to be the job of org-export-with-timestamps. I guess many people who used (setq org-export-with-timestamps nil) now want (setq org-export-with-planning nil) and which works well with (setq org-export-with-timestamps 'inactive). So I'm wondering: would the setup above spare us with this exception? I know people sometimes throw inactive time-stamps, but those small indications would better fit in a commented line. WDYT? Best, -- Bastien
[O] New exporter and latex table export with floats in engineering notation
Hi (), with 8.0pre I'm currently getting strange results when exporting to latex a table with the following notations | -7.8E-2 | \(-7.8e-2\)| what shall I do? The only thing I manage in this situation is | -7.8 10^-2 | but this is unhandy especially when importing floats... -- Best wishes H. Dieter Wilhelm Darmstadt Germany
Re: [O] New exporter and latex table export with floats in engineering notation
Hi Dieter, Dieter Wilhelm, H. die...@duenenhof-wilhelm.de writes: with 8.0pre I'm currently getting strange results when exporting to latex a table with the following notations | -7.8E-2 | \(-7.8e-2\)| Please let us know what is the result, otherwise we cannot see what is strange. Thanks! PS: http://orgmode.org/org.html#Feedback -- Bastien
[O] new exporter and plain text table export alignment
Hi all I use org tables to estimate construction projects. I frequently use simple math within a table cell to help me remember what I was thinking when I entered the data. It seems that the new exporter does not align plain text exports in some of these situations. I only use plain text and html exports; html is working perfectly. example tables and the results I see. * table I - good | | || | |-+-++---| | apples | 3 | 8 | 24.0 | | oranges | 1.2+2.8 | 9 | 36.0 | | plums | 5 | 10 | 50.0 | |-+-++---| | | || 110.0 | #+TBLFM: $4=$2*$3;%.1f::@5$4=vsum(@-I..@-II);%.1f table I - good === - apples 3 8 24.0 oranges 1.2+2.8 9 36.0 plums 5 10 50.0 - 110.0 * table II | | || | |-+-++---| | apples | 3 | 8 | 24.0 | | oranges | 1.1+1.2+1.7 | 9 | 36.0 | | plums | 5 | 10 | 50.0 | |-+-++---| | | || 110.0 | #+TBLFM: $4=$2*$3;%.1f::@5$4=vsum(@-I..@-II);%.1f table II - apples 3 8 24.0 oranges 1.1+1.2+1.7 9 36.0 plums 5 10 50.0 - 110.0 * table III || | | | |+--+-+--| | apples |3 | 8 | 24.0 | | are|4 | 9 | 36.0 | | good | 1.87995654654654 | 10 | 18.8 | |+--+-+--| || | | 78.8 | #+TBLFM: $4=$2*$3;%.1f::@5$4=vsum(@-I..@-II);%.1f table III = apples 3 8 24.0 are 4 9 36.0 good1.87995654654654 10 18.8 78.8 thanks Tracy Helms
Re: [O] New exporter and dates in tables
On 8 apr. 2013, at 21:49, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 8 apr. 2013, at 13:27, Bernt Hansen be...@norang.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@norang.ca writes: I have subtrees with inactive timestamps in the text indicating when something occurred. I normally don't want to export these. But I think any table data that includes inactive timestamps should be an exception to this ... otherwise you get output tables with blank cells where the meaningful timestamp data would be. I understand. So what exactly should be this exception? Should export ignore :nil option in a whole table, or only when a table cell contains a single timestamp? IOW, how would it behaves in the following table: | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] | when `org-export-with-timestamps' is either nil or `active'? I think keeping it simple is best. If there is an inactive timestamp in a table then it should be exported (I consider everything in a table as data). I think this is the right way to look at this. I still find it surprising that :nil will remove the timestamp in: Lunch at [2013-04-04 Thu] but not in | Lunch at [2013-04-04 Thu] | I suppose I'll eventually get it. Yes, I agree that it is hard to nail the exact reasons. The reasoning for me goes like this: Some people throw in time stamps often while they work, just as a little label, indicating that they were working on this at a specific date, or that the entry was created on a specific date. Many people I know have a hook that throws in such a time stamp in each new entry created. This creates a lot of clutter when you print it, which is why you can turn off export of timestamps. That option was not meant for a contextual line like your first example. If you use the time stamps in this way, you probably will not turn off timestamp export at all, you will just leave it on. If you mix both ways of using time stamps - well, too bad. Tabular data is different because you certainly wanted that data in the table, so removing it will be confusing. Anyway, there's still another thing to ponder. Since everything in a table is data, what happens with tex:nil (LaTeX snippets)? Should this option also be ignored within a table? If not, how can we explain the difference with :nil? Tex macros are different. This is an internal way of inserting special characters, and that syntax may get into your way in some specific projects. Just like the fact that _ creates a subscript. If you have to write text with lots of _ but you never mean a subscript, this can be really annoying. So you can turn off subscripts as you can turn off interpretation of tex macros, as a convenience if the syntax gets in your way. Then it should be turned off anywhere, table or not. Regards - Carsten Regards, -- Nicolas Goaziou
Re: [O] new exporter and plain text table export alignment
Hello, maxco...@gmail.com writes: I use org tables to estimate construction projects. I frequently use simple math within a table cell to help me remember what I was thinking when I entered the data. It seems that the new exporter does not align plain text exports in some of these situations. I only use plain text and html exports; html is working perfectly. example tables and the results I see. Thank you for the detailed report. Unfortunately (or fortunately), I cannot reproduce it with Org-mode version 8.0-pre (release_8.0-pre-333-g728c69). What version do you use? Regards, -- Nicolas Goaziou
Re: [O] new exporter and plain text table export alignment
Nicolas Goaziou n.goaz...@gmail.com writes: Thank you for the detailed report. Unfortunately (or fortunately), I cannot reproduce it with Org-mode version 8.0-pre (release_8.0-pre-333-g728c69). What version do you use? Regards, the same, (release_8.0-pre-333-g728c69) I was afraid of that. Thanks for your help, I'll investigate my setup.
Re: [O] new exporter and plain text table export alignment
maxco...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Thank you for the detailed report. Unfortunately (or fortunately), I cannot reproduce it with Org-mode version 8.0-pre (release_8.0-pre-333-g728c69). What version do you use? Regards, the same, (release_8.0-pre-333-g728c69) I was afraid of that. Thanks for your help, I'll investigate my setup. I had '(org-startup-indented t) removing that and plain text table exports are back to normal. thanks again for the help.
Re: [O] New exporter and dates in tables
Hello, Bernt Hansen be...@norang.ca writes: I have subtrees with inactive timestamps in the text indicating when something occurred. I normally don't want to export these. But I think any table data that includes inactive timestamps should be an exception to this ... otherwise you get output tables with blank cells where the meaningful timestamp data would be. I understand. So what exactly should be this exception? Should export ignore :nil option in a whole table, or only when a table cell contains a single timestamp? IOW, how would it behaves in the following table: | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] | when `org-export-with-timestamps' is either nil or `active'? Also, this must be documented. Exceptions tend to accumulate a lot and make the global behaviour unpredictable. Would you mind providing an explanation to this, which would fit in `org-export-with-timestamps' docstring? Regards, -- Nicolas Goaziou
Re: [O] New exporter problem with #+AUTHOR
Hello, Bernt Hansen be...@norang.ca writes: I have the following line in my org-mode document #+AUTHOR: Bernt Hansen (IRC:BerntH on freenode) On the old exporter this became meta name=author content=Bernt Hansen (IRC:BerntH on freenode)/ I just tried exporting this with the new exporter and I get this meta name=author content=Bernt Hansen (a href=BerntHBerntH/a on freenode)/ which isn't legal HTML. The quotes on the href=BerntH close the previous context= quote. Adding a space after IRC: seems to work meta name=author content=Bernt Hansen (IRC: BerntH on freenode)/ Well, technically, irc:BerntH is a plain link, like http://orgmode.org, since irc: is a valid protocol. That may bite you in other parts of the document. Of course, the anchor shouldn't appear in the attribute. I'll have a look at it. Thanks for reporting it. Regards, -- Nicolas Goaziou
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@norang.ca writes: I have subtrees with inactive timestamps in the text indicating when something occurred. I normally don't want to export these. But I think any table data that includes inactive timestamps should be an exception to this ... otherwise you get output tables with blank cells where the meaningful timestamp data would be. I understand. So what exactly should be this exception? Should export ignore :nil option in a whole table, or only when a table cell contains a single timestamp? IOW, how would it behaves in the following table: | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] | when `org-export-with-timestamps' is either nil or `active'? I think keeping it simple is best. If there is an inactive timestamp in a table then it should be exported (I consider everything in a table as data). Also, this must be documented. Exceptions tend to accumulate a lot and make the global behaviour unpredictable. Would you mind providing an explanation to this, which would fit in `org-export-with-timestamps' docstring? Sure I can do that. I will follow up with a patch in this thread this week after the behaviour has been determined. Regards, Bernt
Re: [O] New exporter and dates in tables
On 8 apr. 2013, at 13:27, Bernt Hansen be...@norang.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@norang.ca writes: I have subtrees with inactive timestamps in the text indicating when something occurred. I normally don't want to export these. But I think any table data that includes inactive timestamps should be an exception to this ... otherwise you get output tables with blank cells where the meaningful timestamp data would be. I understand. So what exactly should be this exception? Should export ignore :nil option in a whole table, or only when a table cell contains a single timestamp? IOW, how would it behaves in the following table: | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] | when `org-export-with-timestamps' is either nil or `active'? I think keeping it simple is best. If there is an inactive timestamp in a table then it should be exported (I consider everything in a table as data). I think this is the right way to look at this. - Carsten Also, this must be documented. Exceptions tend to accumulate a lot and make the global behaviour unpredictable. Would you mind providing an explanation to this, which would fit in `org-export-with-timestamps' docstring? Sure I can do that. I will follow up with a patch in this thread this week after the behaviour has been determined. Regards, Bernt
Re: [O] New exporter problem with #+AUTHOR
Hi Bernt, Nicolas Goaziou n.goaz...@gmail.com writes: Well, technically, irc:BerntH is a plain link, like http://orgmode.org, since irc: is a valid protocol. That may bite you in other parts of the document. As a workaround, you can also remove org-irc.el from `org-modules' so that irc:... is not recognized as a link protocol. HTH, -- Bastien
Re: [O] New exporter and dates in tables
Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 8 apr. 2013, at 13:27, Bernt Hansen be...@norang.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@norang.ca writes: I have subtrees with inactive timestamps in the text indicating when something occurred. I normally don't want to export these. But I think any table data that includes inactive timestamps should be an exception to this ... otherwise you get output tables with blank cells where the meaningful timestamp data would be. I understand. So what exactly should be this exception? Should export ignore :nil option in a whole table, or only when a table cell contains a single timestamp? IOW, how would it behaves in the following table: | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] | when `org-export-with-timestamps' is either nil or `active'? I think keeping it simple is best. If there is an inactive timestamp in a table then it should be exported (I consider everything in a table as data). I think this is the right way to look at this. I still find it surprising that :nil will remove the timestamp in: Lunch at [2013-04-04 Thu] but not in | Lunch at [2013-04-04 Thu] | I suppose I'll eventually get it. Anyway, there's still another thing to ponder. Since everything in a table is data, what happens with tex:nil (LaTeX snippets)? Should this option also be ignored within a table? If not, how can we explain the difference with :nil? Regards, -- Nicolas Goaziou
[O] New exporter problem with #+AUTHOR
Hi Nicolas, I have the following line in my org-mode document #+AUTHOR: Bernt Hansen (IRC:BerntH on freenode) On the old exporter this became meta name=author content=Bernt Hansen (IRC:BerntH on freenode)/ I just tried exporting this with the new exporter and I get this meta name=author content=Bernt Hansen (a href=BerntHBerntH/a on freenode)/ which isn't legal HTML. The quotes on the href=BerntH close the previous context= quote. Adding a space after IRC: seems to work meta name=author content=Bernt Hansen (IRC: BerntH on freenode)/ Regards, Bernt
[O] New exporter and publishing to HTML with styles
Hi Nicolas, I'm playing with the new exporter and publishing. Everything seems to be good except my style sheet details are missing. There are :style entries in my org-publish-project-alist which seem to be ignored -- there are no style details in the published HTML file (see http://norang.ca/tmp/org-mode.html) I'm publishing my org-mode.org page to a temporary location to see if it is working as expected before updating the main site. The stylesheet I want is specified with :style link rel=\stylesheet\ href=\http://doc.norang.ca/org.css\; type=\text/css\ / but I don't get any style information in the resulting published file. Is this supposed to work or do I need to add #+HTML_HEAD to each file with the stylesheet information? I'd prefer to set it only once for the publishing location if possible (as it worked with the old publishing system) Thanks, Bernt The following was shortened to only the tmp publishing location settings. --8---cut here---start-8--- (setq org-publish-project-alist ; ; http://www.norang.ca/ (norang website) ; norang-org are the org-files that generate the content ; norang-extra are images and css files that need to be included ; norang is the top-level project that gets published (quote ((tmp-org :base-directory /tmp/publish/ :publishing-directory /ssh:www-data@www:~/www.norang.ca/htdocs/tmp :recursive t :section-numbers nil :table-of-contents nil :base-extension org :publishing-function (org-html-publish-to-html org-org-publish-to-org) :style link rel=\stylesheet\ href=\http://doc.norang.ca/org.css\; type=\text/css\ / :plain-source t :htmlized-source t :style-include-default nil :auto-sitemap t :sitemap-filename index.html :sitemap-title Test Publishing Area :sitemap-style tree :author-info t :creator-info t) (tmp-extra :base-directory /tmp/publish/ :publishing-directory /ssh:www-data@www:~/www.norang.ca/htdocs/tmp :base-extension css\\|pdf\\|png\\|jpg\\|gif :publishing-function org-publish-attachment :recursive t :author nil) (tmp :components (tmp-org tmp-extra)--8---cut here---end---8---
Re: [O] New exporter and publishing to HTML with styles
Hello, Bernt Hansen be...@norang.ca writes: I'm playing with the new exporter and publishing. Everything seems to be good Nice. except my style sheet details are missing. Not nice. ;) There are :style entries in my org-publish-project-alist which seem to be ignored -- there are no style details in the published HTML file (see http://norang.ca/tmp/org-mode.html) I'm publishing my org-mode.org page to a temporary location to see if it is working as expected before updating the main site. The stylesheet I want is specified with :style link rel=\stylesheet\ href=\http://doc.norang.ca/org.css\; type=\text/css\ / but I don't get any style information in the resulting published file. Is this supposed to work or do I need to add #+HTML_HEAD to each file with the stylesheet information? I'd prefer to set it only once for the publishing location if possible (as it worked with the old publishing system) See `org-html-head' docstring. It should be :html-head property, not :style. Regards, -- Nicolas Goaziou
Re: [O] New exporter and publishing to HTML with styles
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: I'm playing with the new exporter and publishing. Everything seems to be good Nice. except my style sheet details are missing. Not nice. ;) There are :style entries in my org-publish-project-alist which seem to be ignored -- there are no style details in the published HTML file (see http://norang.ca/tmp/org-mode.html) I'm publishing my org-mode.org page to a temporary location to see if it is working as expected before updating the main site. The stylesheet I want is specified with :style link rel=\stylesheet\ href=\http://doc.norang.ca/org.css\; type=\text/css\ / but I don't get any style information in the resulting published file. Is this supposed to work or do I need to add #+HTML_HEAD to each file with the stylesheet information? I'd prefer to set it only once for the publishing location if possible (as it worked with the old publishing system) See `org-html-head' docstring. It should be :html-head property, not :style. OK :) I looked at the texinfo documentation that still specifies :style. I added these details to the worg 8.0 page. Thanks! Bernt
[O] New exporter and dates in tables
Hi Nicolas, I just noticed that the new exporter does not export inactive timestamps in table columns. This is now controlled by the option :t I think this is a change from the old exporter (but I'm not sure it's really wrong). I have subtrees with inactive timestamps in the text indicating when something occurred. I normally don't want to export these. But I think any table data that includes inactive timestamps should be an exception to this ... otherwise you get output tables with blank cells where the meaningful timestamp data would be. Exporting part of a data table doesn't really make a lot of sense. For now I need to delete the inactive timestamps in my running text and enable export of inactive timestamps to get the same result I did with the old exporter -- but I lose some of my meta data about when tasks were created in this case. ie. | Date | Amount | Item | |--++---| | [2013-04-04 Thu] | Lunch | 12.50 | | [2013-04-06 Sat] | Parking| 6.00 | | [2013-04-07 Sun] | Train Fair | 14.30 | exports with no data in column 1 when I have :PROPERTIES: :EXPORT_OPTIONS: toc:nil :nil :END: Thanks, Bernt
Re: [O] New exporter and dates in tables
On Apr 7, 2013, at 8:05 PM, Bernt Hansen be...@norang.ca wrote: Hi Nicolas, I just noticed that the new exporter does not export inactive timestamps in table columns. This is now controlled by the option :t I think this is a change from the old exporter (but I'm not sure it's really wrong). Timing is everything. I just noticed the same thing today. I also don't know if it is “wrong” or not, but it is different than the old exporter. In my case I used org-collector to generate the tables, so my workaround was an ugly hack around the property selector in my dynamic block line. #+begin_example #+begin: other org collector options :cols ( (replace-regexp-in-string .*\] (replace-regexp-in-string ^\\[ (format %s ops-meeting-date))) …) #+end_example Where ~ops-meeting-date~ is a property on some of my headlines that in turn is an inactive timestamp.
Re: [O] New Exporter BUG/Change in behaviour
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, The new exporter distinguishes between subtree export (toggled with C-s key within the dispatcher) and region export. In the old exporter, C-c @ + export command would give you a subtree export. This is not the case in the new exporter. You have to explicitly mention you want a subtree export. On the other hand, you don't need to select a region beforehand. In other words, you don't trigger a subtree export anymore with C-c @ (but it triggers a region export). If you export a subtree in the new exporter jargon, you can override locally #+options: line by setting top headline's :EXPORT_OPTIONS: property to an appropriate value, e. g. :EXPORT_OPTIONS: tasks:t. Shouldn't the ,- | :EXPORT_OPTIONS: d:t `- setting in the following minimal org-file export the property-drawer for this subtree too? ,--- | * header1 | :PROPERTIES: | :EXPORT_OPTIONS: d:t | :END: | | hello world | | |hello| table| | `--- Exporting to an ASCII buffer: , | C-c C-e t A ` gives ,-- | Thorsten Jolitz | | | Table of Contents | _ | | 1 header1 | | | 1 header1 | = | | hello world | | hello| table| `-- -- cheers, Thorsten
Re: [O] New Exporter BUG/Change in behaviour
Hello, Thorsten Jolitz tjol...@gmail.com writes: Shouldn't the ,- | :EXPORT_OPTIONS: d:t `- setting in the following minimal org-file export the property-drawer for this subtree too? ,--- | * header1 | :PROPERTIES: | :EXPORT_OPTIONS: d:t | :END: | | hello world | | |hello| table| | `--- No. The d: item only applies to regular drawers. `property-drawer' elements are not among them. Back-ends handle these beasts as they see fit (they usually ignore them, as you can tell). Regards, -- Nicolas Goaziou
Re: [O] New Exporter BUG/Change in behaviour
Nicolas Goaziou n.goaz...@gmail.com writes: No. The d: item only applies to regular drawers. `property-drawer' elements are not among them. Back-ends handle these beasts as they see fit (they usually ignore them, as you can tell). I actually have a use-case where I would like to export the property-drawer to ASCII, but that would involve writing new code - no way to configure it, right? -- cheers, Thorsten
[O] New Exporter BUG/Change in behaviour
Hi Nicolas, I finally updated to the latest master branch at work yesterday to move to the new exporter and found the following change I don't know how to deal with. My org file has #+OPTIONS: tasks:todo This globally skips DONE tasks in my exports when I export the entire file in both the old and new exporter. If I select a task with C-c @ that is DONE (or any done state) and try to export that in the new exporter I get nothing (except an empty table of contents) -- even if the Org buffer is narrowed to only that task. The old exporter would export this anyway but it seems the new exporter is honouring the global #+OPTIONS: task:todo even when it is outside the currently narrowed buffer range. There is no local property that I am aware of to say export all todo states. I have to list them individually which isn't user-friendly so I can't reverse the global setting with a local property in my task/subtree. Having to add a property for my exports for email just to get it to override global options really isn't user-friendly since the options per file are different and the user has to know exactly what to undo (and future changes to the global options makes this a moving target) Is this a bug? My current workaround is to delete the global #+OPTIONS line (but that doesn't feel right since I have to add it back to export what is left to do for the entire file when sharing it with others). I regularly export small subtrees (with C-c @) to copy ASCII / HTML export results to emails so the old exporter behaviour was much more predictable in the results I would get when using C-c @. So far the move to the next exporter has been very easy. Great job! Regards, Bernt
Re: [O] New Exporter BUG/Change in behaviour
Hello, Bernt Hansen be...@norang.ca writes: My org file has #+OPTIONS: tasks:todo This globally skips DONE tasks in my exports when I export the entire file in both the old and new exporter. If I select a task with C-c @ that is DONE (or any done state) and try to export that in the new exporter I get nothing (except an empty table of contents) -- even if the Org buffer is narrowed to only that task. The old exporter would export this anyway but it seems the new exporter is honouring the global #+OPTIONS: task:todo even when it is outside the currently narrowed buffer range. Indeed. OPTIONS is a buffer-wide keyword. There is no local property that I am aware of to say export all todo states. I have to list them individually which isn't user-friendly so I can't reverse the global setting with a local property in my task/subtree. Having to add a property for my exports for email just to get it to override global options really isn't user-friendly since the options per file are different and the user has to know exactly what to undo (and future changes to the global options makes this a moving target) Is this a bug? No, it isn't. My current workaround is to delete the global #+OPTIONS line (but that doesn't feel right since I have to add it back to export what is left to do for the entire file when sharing it with others). I regularly export small subtrees (with C-c @) to copy ASCII / HTML export results to emails so the old exporter behaviour was much more predictable in the results I would get when using C-c @. The new exporter distinguishes between subtree export (toggled with C-s key within the dispatcher) and region export. In the old exporter, C-c @ + export command would give you a subtree export. This is not the case in the new exporter. You have to explicitly mention you want a subtree export. On the other hand, you don't need to select a region beforehand. In other words, you don't trigger a subtree export anymore with C-c @ (but it triggers a region export). If you export a subtree in the new exporter jargon, you can override locally #+options: line by setting top headline's :EXPORT_OPTIONS: property to an appropriate value, e. g. :EXPORT_OPTIONS: tasks:t. There is no such mechanism for a region export. But you can implement a function that will remove the OPTIONS line when buffer is narrowed: (when (buffer-narrowed-p) (org-with-wide-buffer (goto-char (point-min)) (let ((case-fold-search t)) (while (re-search-forward ^[ \t]*#\\+options: nil t) (when (eq (org-element-type (org-element-at-point)) 'keyword) (delete-region (line-beginning-position) (progn (forward-line) (point Then add it to `org-export-before-parsing-hook'. Regards, -- Nicolas Goaziou
Re: [O] New Exporter BUG/Change in behaviour
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Bernt Hansen be...@norang.ca writes: Is this a bug? No, it isn't. My current workaround is to delete the global #+OPTIONS line (but that doesn't feel right since I have to add it back to export what is left to do for the entire file when sharing it with others). I regularly export small subtrees (with C-c @) to copy ASCII / HTML export results to emails so the old exporter behaviour was much more predictable in the results I would get when using C-c @. The new exporter distinguishes between subtree export (toggled with C-s key within the dispatcher) and region export. In the old exporter, C-c @ + export command would give you a subtree export. This is not the case in the new exporter. You have to explicitly mention you want a subtree export. On the other hand, you don't need to select a region beforehand. In other words, you don't trigger a subtree export anymore with C-c @ (but it triggers a region export). If you export a subtree in the new exporter jargon, you can override locally #+options: line by setting top headline's :EXPORT_OPTIONS: property to an appropriate value, e. g. :EXPORT_OPTIONS: tasks:t. Thanks for the clarification! I'll give it a whirl :) Regards, Bernt
Re: [O] New Exporter html - latex - beamer
Charles Berry ccbe...@ucsd.edu writes:
cberry at ucsd.edu writes:
Robert Eckl eckl.r at gmx.de writes:
[snip]
I said
You might be able to do what you want with filter functions.
You can do that with this filter:
But you will want to add something to it to treat links without the
:windowenv:
tag in the normal way
,
| #+BEGIN_SRC emacs-lisp
| (defun filter-links-windowized (link backend info)
| Rid :windowenv: from LINK desc and format per BACKEND. Ignore INFO.
| (let ((clean-string (replace-regexp-in-string :windowenv: link)))
Replace this line:
| (if (eq backend 'latex)
with these:
(if (and
(eq backend 'latex)
(string-match :windowenv: link))
| (let ((wprefix \\begin{window}[0,r,)
| (wpostfix}},{}]\n\\parbox{0.7\\textwidth}{)
| (repstrng
| \\1{includegraphics[width=0.28textwidth]\\2}))
| (concat wprefix
| (file-name-sans-extension
| (replace-regexp-in-string
| \\([^}]*}\\)\\({.*}\\)
| repstrng
| clean-string))
| wpostfix))
| clean-string)))
| #+end_src
`
then ordinary links like
[[http://good.place.com][See good place]]
will be handled in the usual manner by the latex backend
My response is very late, sorry.
Thank you for your effort and the code. I'll try to use it, sounds good.
Reading from filters on worg didn't give me any idea how to use it,
but your code and explanations seems a good entry.
Perhaps later i'll try to adapt that functionality to the parallel
beamer/html-export.
Cu,
Robert
Re: [O] New Exporter html - latex - beamer
cberry at ucsd.edu writes:
Robert Eckl eckl.r at gmx.de writes:
[snip]
I said
You might be able to do what you want with filter functions.
You can do that with this filter:
But you will want to add something to it to treat links without the :windowenv:
tag in the normal way
,
| #+BEGIN_SRC emacs-lisp
| (defun filter-links-windowized (link backend info)
| Rid :windowenv: from LINK desc and format per BACKEND. Ignore INFO.
| (let ((clean-string (replace-regexp-in-string :windowenv: link)))
Replace this line:
| (if (eq backend 'latex)
with these:
(if (and
(eq backend 'latex)
(string-match :windowenv: link))
| (let ((wprefix \\begin{window}[0,r,)
| (wpostfix}},{}]\n\\parbox{0.7\\textwidth}{)
| (repstrng
| \\1{includegraphics[width=0.28textwidth]\\2}))
| (concat wprefix
| (file-name-sans-extension
| (replace-regexp-in-string
| \\([^}]*}\\)\\({.*}\\)
| repstrng
| clean-string))
| wpostfix))
| clean-string)))
| #+end_src
`
then ordinary links like
[[http://good.place.com][See good place]]
will be handled in the usual manner by the latex backend
Chuck
Re: [O] [New exporter] Org LaTeX markup
Charles Berry ccberry at ucsd.edu writes: [snip] Can you give me a hint? M-x customize-variable RET org-latex-format-headline-function RET then copy and paste the last part of the docstring into the window - add a closing parenthesis at the end - and then modify it to your taste. UPDATE: See http://thread.gmane.org/gmane.emacs.orgmode/68691/focus=68713 for advice on this matter as this behavior was changed around Feb 23, 2013 HTH, Chuck
Re: [O] [new-exporter] org-export-before-parsing-hook GOTCHA
Hi Charles, Charles Berry ccbe...@ucsd.edu writes: Is this a feature or a bug? A bug: the user is not supposed to be so careful. This should be fixed now, thanks! -- Bastien
Re: [O] New Exporter html - latex - beamer
Eric S Fraga e.fr...@ucl.ac.uk writes: Robert Eckl eck...@gmx.de writes: I have to provide weekly newsletters in the format pdf and html. Up to now i did this with exporting to scrartcl, known as koma-script. Including images is a bit booring because i handle two formats, for example I am not sure what your latex bits are trying to accomplish so it's difficult to advise on how to achieve what you want. Maybe wrapfigure, which org export supports (float option, I believe, but I am not sure), is what you need instead of window? The latex bits are doing what they should. |-| I don't want the image floating, because | | the text regularly is small. The image | | will be placed how you can see here. |-| Here the text goes over the complete line - If I'm using a list i have to put it in a parbox. The environment window is provided by package picinpar, seems that it not works within beamer. Perhaps for this yasnippet as recommended from Marcin would be usefull. OTOH i would like to use beamer in future, Beamer_Col does a similar job, except of surrounding the image with text. Does Beamer provide something like this? But, if i write the text for Beamer-Output, i have to handle html-output extra. The LaTeX-package comment isn't provided by beamer, I don't know neither how to comment out the HTML-Code for LaTeX-Beamer-fragments nor how to comment out Beamer-Fragments für HTML-Export. Seems, Beamer+html is much more complicate than Beamer+scrartcl/article. Thanks, Robert
Re: [O] New Exporter html - latex - beamer
Robert Eckl eck...@gmx.de writes:
Eric S Fraga e.fr...@ucl.ac.uk writes:
Robert Eckl eck...@gmx.de writes:
I have to provide weekly newsletters in the format pdf and html. Up to
now i did this with exporting to scrartcl, known as koma-script.
Including images is a bit booring because i handle two formats, for example
I am not sure what your latex bits are trying to accomplish so it's
difficult to advise on how to achieve what you want. Maybe wrapfigure,
which org export supports (float option, I believe, but I am not sure),
is what you need instead of window?
The latex bits are doing what they should. |-|
I don't want the image floating, because | |
the text regularly is small. The image | |
will be placed how you can see here. |-|
Here the text goes over the complete line - If I'm using a list i have
to put it in a parbox. The environment window is provided by package
picinpar, seems that it not works within beamer.
Perhaps for this yasnippet as recommended from Marcin would be usefull.
OTOH i would like to use beamer in future, Beamer_Col does a similar
job, except of surrounding the image with text. Does Beamer provide
something like this?
But, if i write the text for Beamer-Output, i have to handle html-output
extra. The LaTeX-package comment isn't provided by beamer, I don't
know neither how to comment out the HTML-Code for LaTeX-Beamer-fragments
nor how to comment out Beamer-Fragments für HTML-Export.
Seems, Beamer+html is much more complicate than Beamer+scrartcl/article.
You might be able to do what you want with filter functions.
Suppose you start with this:
(Note: long lines might have been wrapped.)
,
| #+ATTR_HTML: alt=my altname title=my full title align=right width=30%
padding=0em padding-top=0em
|[[http://my.com][my place.jpg:windowenv:]]
| More stuff
| - item 1
| - item 1.1
| - item 1.2
| #+LATEX: } \end(window}
`
and want to get this from latex export:
,
|
\begin{window}[0,r,\href{http://my.com}{\includegraphics[width=0.28\textwidth]{my
place}},{}]
| \parbox{0.7\textwidth}{
| More stuff
| \begin{itemize}
| \item item 1
| \begin{itemize}
| \item item 1.1
| \item item 1.2
| \end{itemize}
| \end{itemize}
| } \end(window}
`
and this from html
,
| p
| a href=http://my.com; alt=my altname title=my full title align=right
width=30% padding=0em padding-top=0emmy place.jpg/a
| More stuff
| /p
| ul class=org-ul
| liitem 1
| ul class=org-ul
| liitem 1.1
| /li
| liitem 1.2
| /li
| /ul
| /li
| /ul
`
You can do that with this filter:
,
| #+BEGIN_SRC emacs-lisp
| (defun filter-links-windowized (link backend info)
| Rid :windowenv: from LINK desc and format per BACKEND. Ignore INFO.
| (let ((clean-string (replace-regexp-in-string :windowenv: link)))
| (if (eq backend 'latex)
| (let ((wprefix \\begin{window}[0,r,)
| (wpostfix}},{}]\n\\parbox{0.7\\textwidth}{)
| (repstrng
| \\1{includegraphics[width=0.28textwidth]\\2}))
| (concat wprefix
| (file-name-sans-extension
| (replace-regexp-in-string
| \\([^}]*}\\)\\({.*}\\)
| repstrng
| clean-string))
| wpostfix))
| clean-string)))
| #+end_src
`
which you install with this line:
,
| #+begin_src emacs-lisp :eval never
| (add-to-list 'org-export-filter-link-functions
'filter-links-windowized)
| #+END_SRC
`
Then run the new exporter.
What you want yas to provide is something like
,
| #+ATTR_HTML: alt= title= align= ...
|
| #+LATEX: } \end(window}
`
if you like to use C-c C-l to enter the link - just remember to add the
:windowenv: after the link description.
or
,
| #+ATTR_HTML: alt=my altname title=my full title align= ...
| [[ ][ :windowenv:]]
|
| #+LATEX: } \end(window}
`
if you don't use C-c C-l.
HTH,
Chuck
Re: [O] New Exporter html - latex - beamer
Robert Eckl eck...@gmx.de writes: I have to provide weekly newsletters in the format pdf and html. Up to now i did this with exporting to scrartcl, known as koma-script. Including images is a bit booring because i handle two formats, for example I am not sure what your latex bits are trying to accomplish so it's difficult to advise on how to achieve what you want. Maybe wrapfigure, which org export supports (float option, I believe, but I am not sure), is what you need instead of window? -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0-pre-107-g91a6ca
Re: [O] [new-exporter] Beamer color theme
Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Wed, Mar 13, 2013 at 07:11:09AM +0530, Vikas Rawal wrote: How do I change beamer color theme in the new exporter. I updated the tutorial. Suvayu, thanks for this. I have updated, on Worg, the example presentation to work with the new exporter. It is at http://orgmode.org/worg/exporters/beamer/presentation.org Can you put a link to it from the tutorial maybe? Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0-pre-72-gc66641
Re: [O] [new-exporter] Beamer color theme
On Fri, Mar 15, 2013 at 01:57:26PM +, Eric S Fraga wrote: I have updated, on Worg, the example presentation to work with the new exporter. It is at http://orgmode.org/worg/exporters/beamer/presentation.org Can you put a link to it from the tutorial maybe? Done :). http://orgmode.org/cgit.cgi/worg.git/commit/?id=b682c0e1b5958d985c1f96258479dd5523764a43 -- Suvayu Open source is the future. It sets us free.
Re: [O] [New Exporter] deriving from derived backends?
Hello, Rick Frankel r...@rickster.com writes: I am trying to derive a backend from another derived backend (i want to override certain entries in the options-alist), but it does not seem to work. The menu entries are created, but the in the second-level derived backend are not being picked up. Should this work? Or do i need a different approach? here's abbreviated code: (org-export-define-derived-backend s5 html :menu-entry (?s Export to S5 HTML Presentation ((?H To temporary buffer org-s5-export-as-html) (?h To file org-s5-export-to-html) (?o To file and open (lambda (a s v b) (if a (org-s5-export-to-html t s v b) (org-open-file (org-s5-export-to-html nil s v b))) :options-alist [...] ;; this is the full exporter definition (org-export-define-derived-backend s5-xoxo s5 :menu-entry (?s Export to S5 HTML Presentation ((?X To temporary buffer (XOXO) org-s5-export-as-html) (?x To file (XOXO) org-s5-export-to-html) (?O To file and open (XOXO) (lambda (a s v b) (if a (org-s5-export-to-html t s v b) (org-open-file (org-s5-export-to-html nil s v b))) :options-alist ((:html-container nil nil li) ;; this is defined in the html backend ;; this is new to this backend (:s5-xoxo-root S5_XOXO_ROOT nil org-s5-xoxo-root-element))) If i use e.g., s-X or s-x in the exporter menu, in exporter functions, :html-container == div (which is set in the html exporter), and :s5-xoxo-root is nil. You are using the same key: ?s for both back-ends in the menu. You need to use different keys, or install one of them as a sub-menu of the previous one (notice the 1 instead of the description): (org-export-define-derived-backend s5-xoxo s5 :menu-entry (?s 1 ((?X To temporary buffer (XOXO) org-s5-export-as-html) (?x To file (XOXO) org-s5-export-to-html) (?O To file and open (XOXO) (lambda (a s v b) (if a (org-s5-export-to-html t s v b) (org-open-file (org-s5-export-to-html nil s v b))) :options-alist ((:html-container nil nil li) ;; this is defined in the html backend ;; this is new to this backend (:s5-xoxo-root S5_XOXO_ROOT nil org-s5-xoxo-root-element))) Regards, -- Nicolas Goaziou
[O] New Exporter html - latex - beamer
Both, the old and the new Exporter are brilliant tools, migration to the
new exporter didn't make great issues.
I have to provide weekly newsletters in the format pdf and html. Up to
now i did this with exporting to scrartcl, known as koma-script.
Including images is a bit booring because i handle two formats, for example
#+BEGIN_SRC Org
#+BEGIN_LaTeX
\begin{window}[0,r,\href{http://www.link.de}{\includegraphics[width=0.28\textwidth]{path/picture}},{}]
\begin{comment}
#+END_LaTeX
#+ATTR_HTML: alt=Objekt title=Objektansicht align=right width=30%
padding=0em padding-top=0em
[[http://www.link.de/][http://www.link.de/path/images/picture.jpg]]
#+BEGIN_LaTeX
\end{comment}
\parbox{0.7\textwidth}{
#+END_LaTeX
Any Text
- item 1
- item 2
- item 3
#+BEGIN_LaTeX
}
\end{window}
#+END_LaTeX
#+END_SRC
It works, but it's a bit boring. The parbox only is required with
lists.
Now i plan to use Beamer, possible instead of scrarctl.
If I use BEAMER_col the titles ignored by beamer will exported in html -
format.
Perhaps someone can give me a hint how to deal with this, perhaps
- a comment-environment for HTML how i used for LaTeX or
- write the BMCOL-Environment manually in an LaTeX-Block?
TIA,
Robert
Re: [O] New Exporter html - latex - beamer
Dnia 2013-03-15, o godz. 21:55:42
Robert Eckl eck...@gmx.de napisał(a):
Both, the old and the new Exporter are brilliant tools, migration to
the new exporter didn't make great issues.
I have to provide weekly newsletters in the format pdf and html. Up to
now i did this with exporting to scrartcl, known as koma-script.
Including images is a bit booring because i handle two formats, for
example
#+BEGIN_SRC Org
#+BEGIN_LaTeX
\begin{window}[0,r,\href{http://www.link.de}{\includegraphics[width=0.28\textwidth]{path/picture}},{}]
\begin{comment}
#+END_LaTeX
#+ATTR_HTML: alt=Objekt title=Objektansicht align=right
width=30% padding=0em
padding-top=0em
[[http://www.link.de/][http://www.link.de/path/images/picture.jpg]]
#+BEGIN_LaTeX \end{comment}
\parbox{0.7\textwidth}{
#+END_LaTeX
Any Text
- item 1
- item 2
- item 3
#+BEGIN_LaTeX
}
\end{window}
#+END_LaTeX
#+END_SRC
It works, but it's a bit boring. The parbox only is required with
lists.
Now i plan to use Beamer, possible instead of scrarctl.
If I use BEAMER_col the titles ignored by beamer will exported in
html - format.
Perhaps someone can give me a hint how to deal with this, perhaps
- a comment-environment for HTML how i used for LaTeX or
- write the BMCOL-Environment manually in an LaTeX-Block?
This is not even a decent answer, but in a pinch you might define a
yasnippet for this. (A decent answer would be to use some kind of a
preprocessor, a good answer would be to use a preprocessor in Elisp,
and the best answer would include its code;).)
TIA,
Robert
Regards,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
[O] [new-exporter] org-export-before-parsing-hook GOTCHA
Is this a feature or a bug? in org-export-as, there are these lines , | (goto-char (point-min)) | (run-hook-with-args 'org-export-before-parsing-hook backend) ` For some time, I used hook functions that usually reset the position of *point*. They worked fine. Recently, they produced strange results in subtree exports - a later headline was used as the title even when :EXPORT_TITLE: was set. Other properties like :EXPORT_FILE_NAME: seemed unaffected (OK). I have put `save-excursion' in my code, and all seems to be well. But I wonder if it is understood in defun'ing hooks that it is up to the coder to make sure that *point* gets put back where it needs to be. Or should there be another (goto-char (point-min)) after the lines above.
Re: [O] [New Exporter] deriving from derived backends?
Hi Rick, Rick Frankel r...@rickster.com writes: If i use e.g., s-X or s-x in the exporter menu, in exporter functions, :html-container == div (which is set in the html exporter), and :s5-xoxo-root is nil. Do you have `org-s5-xoxo-root-element' defined somewhere in your file? HTH, -- Bastien
Re: [O] [New Exporter] deriving from derived backends?
Yes. On Mar 12, 2013, at 9:15 AM, Bastien b...@altern.org wrote: Hi Rick, Rick Frankel r...@rickster.com writes: If i use e.g., s-X or s-x in the exporter menu, in exporter functions, :html-container == div (which is set in the html exporter), and :s5-xoxo-root is nil. Do you have `org-s5-xoxo-root-element' defined somewhere in your file? HTH, -- Bastien
[O] [new-exporter] Beamer color theme
How do I change beamer color theme in the new exporter. Vikas
Re: [O] [new-exporter] Beamer color theme
On Wed, Mar 13, 2013 at 07:11:09AM +0530, Vikas Rawal wrote: How do I change beamer color theme in the new exporter. I updated the tutorial. http://orgmode.org/worg/exporters/beamer/ox-beamer.html#config The new exporter is ... well new, when in doubt looking at the source is quite effective. Often you need minimal lisp understanding to follow what is going on. Hope this helps, -- Suvayu Open source is the future. It sets us free.
