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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Re: [O] [new exporter] [html] Tables of Contents
Hi Samuel, Samuel Wales samolog...@gmail.com writes: How do we make it a reality NOW? No, I stated my reasons here: http://article.gmane.org/gmane.emacs.orgmode/67829 -- Bastien
Re: [O] [new exporter] ignoring a headline on export to PDF?via?latex
Hi Charles, On Wed, Mar 06, 2013 at 07:11:48AM +, Charles Berry wrote: I added to org-hacks.org at the bottom of ** Exporting org files. I tried to push to worg but got a permission error - its been years since I last pushed anything, so something on my end probably needs to be updated. You probably your keys were not moved to the new machine that hosts Worg. An email to Bastien and/or Jason should fix that. I've posted the file at: https://raw.github.com/chasberry/orgmode-accessories/master/filter-markup.org If you would like to put it in org-hacks, I'd appreciate it. I had missed your email, I put your writeup with some minor formatting changes under the new exporters directory on Worg. Please have a look and let me know if they are in order. http://orgmode.org/worg/exporters/ http://orgmode.org/worg/exporters/filter-markup.html Here are the commits: http://orgmode.org/cgit.cgi/worg.git/commit/?id=0ae0f97db6ac6c3ca7cc94001a442e54c2d1d3d9 http://orgmode.org/cgit.cgi/worg.git/commit/?id=ce62735fd8298c8924f76098d768db42b53f155b Thanks a lot for your contribution. :) -- Suvayu Open source is the future. It sets us free.
Re: [O] [New Exporter] Parameterized wrapper elements
Hi Rick, besides Nicolas good suggestions regarding the code, I think the patch is good and I welcome more flexibility in the HTML exporter so that HTML5-ready derived backends can be written. I'll have a careful look next week. One thing you may double-check in the meantime is: is it compatible with the org-info.js utility? The default should be yes, even if users can replace div by something else (e.g. for the needs of specific backends.) In any case, thanks! -- Bastien
Re: [O] [new exporter] feature request: BEGIN_LATEX_HEADER
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: Prompted by Nicolas's recent addition of the LATEX_HEADER_EXTRA directive, I would like to request another related feature. Just as we have the related LATEX and BEGIN_LATEX directives, I would like to see a BEGIN_LATEX_HEADER directive for multi-line LATEX_HEADER lines: [...] Adding one more is not without consequences. For example, where should it go? After latex_header values? Before? Would the location be configurable in `org-latex-classes'? What placeholder to use? I wasn't proposing anything different other than allowing one to group a whole set of #+latex_header lines into a single begin/end block, akin to what #+begin_latex allows. Just a minor convenience feature. I admit I'm not very keen on this idea. Not because of the coding work, it would be around 10 loc, but because of syntax fester. Okay, no worries. Thanks for considering it. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-970-g728c0e
Re: [O] [new exporter] feature request: BEGIN_LATEX_HEADER
Nicolas Goaziou writes: I admit I'm not very keen on this idea. Not because of the coding work, it would be around 10 loc, but because of syntax fester. Speaking of syntax, having long blocks of #+GRMLLL_SOMETHING: lines is somewhat of an eyesore, but instead of inventing yet another type of block, what about allowing implicit naming of keywords: #+LaTeX_header: % #+: \newcommand{\Wal}{\operatorname{Wal}} #+: \newcommand{\Cal}{\operatorname{Cal}} #+: \newcommand{\Sal}{\operatorname{Sal}} #+: \newcommand{\sgn}{\operatorname{sgn}} Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [New Exporter] Parameterized wrapper elements
On Sat, Mar 09, 2013 at 01:46:37AM +0100, Nicolas Goaziou wrote: Since I don't use html back-end, it would be better to hear from actual users what they think about it. Sorry, forgot that you are not the keeper of ox-html, just the new exporter at large ;). Anyway, just a few comments: +(defcustom org-html-divs + '((preamble div) +(content div) +(postamble div)) + Alist of the main divs for HTML export. Even if this is technically an alist, you don't use it as such, because you do not treat ID as keys. Perhaps something like the following would be better: '((preamble preamble div) (content content div) (postamble postamble div)) One advantage is that you don't have to rely on order of associations. Another advantage is that you can write: (nth 1 (assq 'content org-html-divs)) I agree, but couldn't figure out a way to specify a defcustom alist that requires a fixed set of options. I'm quite new to the defcustom specification format, so maybe there is a way... Given what I see is possible w/ custom alists, the code would have to look like: (nth 1 (or (assq 'content org-html-divs) (assq 'content org-html-default-divs))) Not sure this is any better than the nth nth approach. What do you think? + (if (= 1 (org-export-get-relative-level headline info)) + (plist-get info :html-container Shouldn't you close the div when level is different from 1 here? Yes, it's a bug. Missing the else part. Will amend the patch and repost. thanx for finding this. rick
Re: [O] [New Exporter] Parameterized wrapper elements
On Sat, Mar 09, 2013 at 10:32:11AM +0100, Bastien wrote: Hi Rick, One thing you may double-check in the meantime is: is it compatible with the org-info.js utility? The default should be yes, even if users can replace div by something else (e.g. for the needs of specific backends.) Yes. Checked the code and tested the script. It works on element ids and not element types, so changing the element type from `div' has no effect. The things that will break infojs are changing the following ids: - content - postamble - footnotes - table-of-contents - text-table-of-content - text-{slidenum} Note that the current implementation of `org-html-divs' will potentially break infojs as well. Attached is a revised patch with the fixes Nicolas found for the doc-string and the missing closing element. rick From d539863475c4c1432b2b5de175d587f57b317453 Mon Sep 17 00:00:00 2001 From: Rick Frankel r...@rickster.com Date: Fri, 8 Mar 2013 19:00:21 -0500 Subject: [PATCH] Parameterize some html content containers * lisp/ox-html.el: (define-backend): Add :html-doctype and :html-container parameters. (org-html-doctype): New customization variable for doctype declaration. (org-html-container-elemnt): New customization variable for specifying wrapper container element. (org-html-div): Change to list of pairs id, element type to allow setting container element. (org-html--build-preamble): Modified to use new org-html-div settings. (org-html--build-postamble): Modified to use new org-html-div settings. (org-html-template): Modified to use doctype and container-element settings. --- lisp/ox-html.el | 77 +++-- 1 file changed, 58 insertions(+), 19 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 829fe28..b1638e6 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -113,6 +113,8 @@ (org-open-file (org-html-export-to-html nil s v b))) :options-alist ((:html-extension nil nil org-html-extension) + (:html-doctype HTML_DOCTYPE nil org-html-doctype) + (:html-container HTML_CONTAINER nil org-html-container-element) (:html-link-home HTML_LINK_HOME nil org-html-link-home) (:html-link-up HTML_LINK_UP nil org-html-link-up) (:html-mathjax HTML_MATHJAX nil space) @@ -859,19 +861,44 @@ Use utf-8 as the default value. :package-version '(Org . 8.0) :type 'coding-system) -(defcustom org-html-divs '(preamble content postamble) - The name of the main divs for HTML export. -This is a list of three strings, the first one for the preamble -DIV, the second one for the content DIV and the third one for the -postamble DIV. +(defcustom org-html-doctype + !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\ +\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\; + Document type definition to use for exported HTML files. +Can be set with the in-buffer HTML_DOCTYPE property or for +publishing, with :html-doctype. :group 'org-export-html :version 24.4 :package-version '(Org . 8.0) - :type '(list - (string :tag Div for the preamble:) - (string :tag Div for the content:) - (string :tag Div for the postamble:))) + :type 'string) + +(defcustom org-html-container-element div + Container class to use for wrapping top level sections. +Can be set with the in-buffer HTML_CONTAINER property or for +publishing, with :html-container. + :group 'org-export-html + :version 24.4 + :package-version '(Org . 8.0) + :type 'string) +(defcustom org-html-divs + '((preamble div) +(content div) +(postamble div)) + Alist of the main divs for HTML export. +This is a list of three pairs, ID and ELEMENT, the first one +for the preamble, the second one for the content and the +third one for the postamble. + :group 'org-export-html + :version 24.4 + :package-version '(Org . 8.0) + :type '(list + (list :tag Preamble + (string :tag id) (string :tag element)) + (list :tag Content + (string :tag id) (string :tag element)) + (list :tag Postamble + (string :tag id) (string :tag element Template :: Mathjax @@ -1482,9 +1509,11 @@ INFO is a plist used as a communication channel. `((?t . ,title) (?a . ,author) (?d . ,date) (?e . ,email (when (org-string-nw-p preamble-contents) - (concat (format div id=\%s\\n (nth 0 org-html-divs)) + (concat (format %s id=\%s\\n + (nth 1 (nth 0 org-html-divs)) + (nth 0 (nth 0 org-html-divs))) (org-element-normalize-string preamble-contents) - /div\n)) + (format /%s\n (nth 1 (nth 0 org-html-divs) (defun org-html--build-postamble (info) Return document postamble as a string, or nil. @@ -1534,9 +1563,11 @@ INFO is a plist used as a communication channel.
Re: [O] [New Exporter] Parameterized wrapper elements
Rick I have my reservations in applying this patch - I am not concerned about the patch, I have not looked at it. Any improvements to existing backends should invariably answer the question - Can this change improve export tools or the parse tree syntax. If such a question is never asked and a answer sought, I would blame the committer - whoever it be - in placing convenience and expediency above the correct way to do things. I have not looked at Rick's patch so my comment shouldn't be construed as disapproval of the patch. I want the patch to improve exporter tools and it has potential to improve the existing tools (maybe) in small ways - an improvement is an improvement. Jambunathan K. Rick Frankel r...@rickster.com writes: On Sat, Mar 09, 2013 at 10:32:11AM +0100, Bastien wrote: Hi Rick, One thing you may double-check in the meantime is: is it compatible with the org-info.js utility? The default should be yes, even if users can replace div by something else (e.g. for the needs of specific backends.) Yes. Checked the code and tested the script. It works on element ids and not element types, so changing the element type from `div' has no effect. The things that will break infojs are changing the following ids: - content - postamble - footnotes - table-of-contents - text-table-of-content - text-{slidenum} Note that the current implementation of `org-html-divs' will potentially break infojs as well. Attached is a revised patch with the fixes Nicolas found for the doc-string and the missing closing element. rick --
Re: [O] [new exporter] [html] Tables of Contents
On 3/6/13, Bastien b...@altern.org wrote: Hello Jambunathan, You are not welcome on this list anymore, please ban yourself. Thanks, Thank you, Bastien. This has been necessary since around May of 2011. How do we make it a reality NOW? Samuel Wales -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. It attacks MANY body systems. ANYBODY can get it. There is NO hope without activist action. This means YOU.
Re: [O] [new exporter] [html] Tables of Contents
Samuel Wales samolog...@gmail.com writes: On 3/6/13, Bastien b...@altern.org wrote: Hello Jambunathan, You are not welcome on this list anymore, please ban yourself. Thanks, Thank you, Bastien. This has been necessary since around May of 2011. How do we make it a reality NOW? I said I want to be banned. Let me suggest ways: 1. Quarantine my posts. 2. Remove ox-html.el (atleast the lines I have made substantial modifications to) and ox-odt.el from Org repo. I will move the stuff to GNU ELPA and obsolete my work if a better replacement comes along. ox-html.el and ox-odt.el is no rocket science, if Bastien or Samuel or even a college intern sits for a day, I promise you they will do a better job than I have done. Don't talk, do. Write your own exporters and then ban me from the list. Otherwise it is just childish prant. Removing me from the list, without disowning my contributions is also ethically/morally reprehensible act which elders will condemn (silently or vocally) Bottomline: Who dares, wins. Samuel Wales --
Re: [O] [new exporter] Captions for tables made by source blocks
Hello Achim, Achim Gratz wrote: Nicolas Goaziou writes: It's very easy to have a caption on the generated output: name the code. Hence, the following code block: #+NAME: calculation #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC will produce: #+RESULTS: calculation 2 If you add a caption to the results, like: #+CAPTION: Basic arithmetic #+RESULTS: calculation 2 you can update the source block without ever needing to remove the caption. Great. I could swear the last time I was trying this it would add a new result block on top of the old one, but I may have changed the name inbetween. The thing is: - you try with an unnamed block - you get an unnamed result block inserted - you name the block - you get a named result block inserted - you have to manually remove the unnamed result block It would still be nice (I think) if an unnamed source block would simply replace the next unnamed result block if there is one. I think this is a great proposition, which would make a lot of sense. Best regards, Seb -- Sebastien Vauban
Re: [O] [new exporter] blank html page with org-info.js
Hi Henry, henry atting s...@online.de writes: But the file is not displayed, as mentioned before only in text browsers. Older .html files, created before the last pull still work properly. When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Thanks! -- Bastien
Re: [O] [new exporter] blank html page with org-info.js
Bastien b...@altern.org writes: Hi Henry, henry atting s...@online.de writes: But the file is not displayed, as mentioned before only in text browsers. Older .html files, created before the last pull still work properly. When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Org-mode version 8.0-pre (release_8.0-pre-5-ga646a2) Thanks! -- henry atts, web: http://literaturlatenight.de
Re: [O] [new exporter] blank html page with org-info.js
Hi Henry, henry atting s...@online.de writes: When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Org-mode version 8.0-pre (release_8.0-pre-5-ga646a2) This is now fixed, thanks! -- Bastien