Re: [O] New exporter and dates in tables

[Carsten Dominik]

OK, thank you.

- Carsten

On 9.8.2013, at 13:02, Bernt Hansen  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  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  wrote:
>> 
>>> Hi Nicolas,
>>> 
>>> Nicolas Goaziou  writes:
>>> 
 Bastien  writes:
 
> Nicolas Goaziou  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

[Bernt Hansen]

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  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  wrote:
>
>> Hi Nicolas,
>> 
>> Nicolas Goaziou  writes:
>> 
>>> Bastien  writes:
>>> 
 Nicolas Goaziou  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

[Carsten Dominik]

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  wrote:

> Hi Nicolas,
> 
> Nicolas Goaziou  writes:
> 
>> Bastien  writes:
>> 
>>> Nicolas Goaziou  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

[Michael Bach]

> 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] org-export-latex-after-initial-vars-hook

[Michael Bach]

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  writes:

> Søren Mikkelsen  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

[Michael Bach]

Nicolas Goaziou  writes:

> Søren Mikkelsen  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] What happened to the export template

[Bastien]

Hi Robert,

Robert Goldman  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

[Robert Goldman]

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?

[Eric S Fraga]

Carsten Dominik  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?

[Carsten Dominik]

On 2.5.2013, at 21:28, Eric S Fraga  wrote:

> Carsten Dominik  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?

[Eric S Fraga]

Carsten Dominik  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?

[Carsten Dominik]

On 1.5.2013, at 14:28, Eric S Fraga  wrote:

> "Thomas S. Dye"  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?

[Eric S Fraga]

"Thomas S. Dye"  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?

[Thomas S. Dye]

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  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] how can I export drawers?

[Eric S Fraga]

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?

[Eric S Fraga]

Nicolas Goaziou  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?

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Thorsten Jolitz  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]

Hello,

Thorsten Jolitz  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]

Hello,

Eric S Fraga  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?

[Thorsten Jolitz]

Eric S Fraga  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] org-export-latex-after-initial-vars-hook

[Nicolas Goaziou]

Hello,

Søren Mikkelsen  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 - publishing org files doesn't include :tangle

[Bernt Hansen]

Bernt Hansen  writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Bernt Hansen  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

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  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

[Nicolas Goaziou]

Hello,

Bernt Hansen  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

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  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

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  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 - publishing org files doesn't include :tangle

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  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]

Hello,

Bernt Hansen  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: plain list depth

[Yasushi SHOJI]

Hi,

At Mon, 22 Apr 2013 00:10:25 +0200,
Nicolas Goaziou wrote:
> 
> Yasushi SHOJI  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

[Nicolas Goaziou]

Hello,

Yasushi SHOJI  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

[Achim Gratz]

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

[Bastien]

Hi,

yes, this *is* a problem.

Suvayu Ali  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

[Suvayu Ali]

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> Bastien  writes:
>
>> Nicolas Goaziou  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

[Bastien]

Nicolas Goaziou  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

[Jambunathan K]

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  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

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  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.

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.


Regards,

-- 
Nicolas Goaziou
>From 8faa562ce1d2a80988736e7a045b7c16aba7ebc9 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Sun, 14 Apr 2013 22:20:16 +0200
Subject: [PATCH] ox: Add more options to skip timestamps

* lisp/ox.el (org-export-with-timestamps): Allow `not-standalone',
  `active-not-standalone' and `inactive-not-standalone' values. Update
  docstring.
(org-export--skip-p): Skip timestamps according to new values.
* testing/lisp/test-ox.el: Add tests.
---
 lisp/ox.el  | 59 ++--
 testing/lisp/test-ox.el | 79 +++--
 2 files changed, 107 insertions(+), 31 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index fffb7ce..75ea25a 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -721,9 +721,19 @@ also be set with the OPTIONS keyword, e.g. \"timestamp:nil\"."
 (defcustom org-export-with-timestamps t
   "Non nil means allow timestamps in export.
 
-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.
+It can be set to any of the following values:
+t export all timestamps.
+ `active' export active timestamps only.
+  `active-not-standalone' export active timestamps which are not
+  isolated in a paragraph containing only
+  timestamps.
+   `inactive' export inactive timestamps only.
+`inactive-not-standalone' export inactive timestamps which are not
+  isolated in a paragraph containing only
+  timestamps.
+ `not-standalone' export timestamps which are not isolated
+  in a paragraph containing only timestamps.
+  nil do not export timestamps
 
 This option can also be set with the OPTIONS keyword, e.g.
 \"<:nil\"."
@@ -2017,19 +2027,36 @@ 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
+ (let ((standalonep
+	(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)))
+   (case (plist-get options :with-timestamps)
+	 ('nil t)
+	 (active
+	  (not (memq (org-element-property :type blob) '(active active-range
+	 (active-not-standalone
+	  (not (and (memq (org-element-property :type blob)
+			  '(active active-range))
+		(not (funcall standalonep blob)
+	 (inactive-not-standalone
+	  (not
+	   (and (memq (org-element-property :type blob)
+		  '(inactive inactive-range))
+		(not (funcall standalonep blob)
+	 (inactive
+	  (not (memq (org-element-property :type blob)
+		 '(inactive inactive-range
+	 (not-standalone (funcall standalonep blob)))
 
 
 ;;; The Transcoder
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 46531a1..90b4eb5 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -394,21 +394,70 @@ Paragraph"
 	  (org-test-with-temp-text "[0/0]"
 	(org-test-with-backend test
 	  (org-export-as
-	   'test nil nil nil '(:with-statistics-cookies nil))
-  ;; Timestamps.
-  (org-test-with-temp-text "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>"
-(org-test-with-backend test
-  (should
-   (equal (org-export-as 'test nil nil nil '(:with-timestamps t))
-	  "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>\n"))
-  (should
-

Re: [O] New exporter and dates in tables

[Bastien]

Nicolas Goaziou  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 Goaziou]

Bastien  writes:

> Nicolas Goaziou  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

[Bastien]

Nicolas Goaziou  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

[Nicolas Goaziou]

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> According to your suggestion, with `org-export-with-timestamps' set to
>> `not-standalone', in the following example:
>>
>> * Task
>>   
>>
>> At , I must do that.
>>
>> the first  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

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> According to your suggestion, with `org-export-with-timestamps' set to
> `not-standalone', in the following example:
>
> * Task
>   
>
> At , I must do that.
>
> the first  would be ignored, not the second one. Isn't it
> what you want?

Yes, exactly.

-- 
 Bastien

Re: [O] New exporter and dates in tables

[Nicolas Goaziou]

Hello,

Bastien  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  in
>
> * Task
>   
>
> 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
  

At , I must do that.
--8<---cut here---end--->8---

the first  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

[Bastien]

"Sebastien Vauban"
 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

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> Bastien  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  in

* Task
  

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]

Hello,

Nicolas Goaziou wrote:
> Bastien  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

[Nicolas Goaziou]

Bastien  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

[Bastien]

Nicolas Goaziou  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

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Nicolas Goaziou  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: 
>   - DEADLINE: 
>   - CLOSED: 
>   - 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

[Bastien]

Hello,

Nicolas Goaziou  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: 
  - DEADLINE: 
  - CLOSED: 
  - 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

[Nicolas Goaziou]

Hello,

Bastien  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

[Bastien]

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 dates in tables

[Carsten Dominik]

This looks good to me - with my limited understanding of the exporter lingo.

Thanks!

- Carsten

On 10 apr. 2013, at 14:43, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  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 
> 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
> +  

Re: [O] New exporter and dates in tables

[Nicolas Goaziou]

Hello,

Carsten Dominik  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 
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 plain text table export alignment

[Maxco . tr]

maxco...@gmail.com writes:

> Nicolas Goaziou  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 plain text table export alignment

[Maxco . tr]

Nicolas Goaziou  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

[Nicolas Goaziou]

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 dates in tables

[Carsten Dominik]

On 8 apr. 2013, at 21:49, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> On 8 apr. 2013, at 13:27, Bernt Hansen  wrote:
>> 
>>> Nicolas Goaziou  writes:
>>> 
 Bernt Hansen  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 latex table export with floats in engineering notation

[Bastien]

Hi Dieter,

"Dieter Wilhelm, H."  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 problem with #+AUTHOR

[Nicolas Goaziou]

Hello,

Bernt Hansen  writes:

> I have the following line in my org-mode document
>
> #+AUTHOR: Bernt Hansen (IRC:BerntH on freenode)
>
> On the old exporter this became
>
> 
>
> I just tried exporting this with the new exporter and I get this
>
> BerntH
> on freenode)"/>
>
> which isn't legal HTML.  The quotes on the href="BerntH" close the
> previous context= quote.

Here is a suggested patch to fix export of data meant to appear as an
attribute value.

WDYT?


Regards,

-- 
Nicolas Goaziou
>From 6d8c48145ffd00ce82f2f19d1fd223a6a1c13a15 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Mon, 8 Apr 2013 22:24:29 +0200
Subject: [PATCH] ox-html: Fix invalid syntax in html attributes

* lisp/ox-html.el (org-html--export-attribute): New function.
(org-html--build-meta-info): Use new function.
---
 lisp/ox-html.el | 62 -
 1 file changed, 53 insertions(+), 9 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 39b0ec9..6b964da 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1265,6 +1265,48 @@ ELEMENT is either a src block or an example block."
 	(or (plist-get attr :height) (org-count-lines code))
 	code)))
 
+(defun org-html--export-attribute (data info)
+  "Export DATA as a string suitable for an attribute value.
+
+DATA is an object, a secondary string or a string.  INFO is
+a plist used as a communication channel.
+
+To make output suitable as an attribute value, every markup is
+removed and special characters, including quotes, are escaped."
+  (replace-regexp-in-string
+   "\"" """
+   (org-export-data
+(org-export-data-with-translations
+ data
+ (append
+  (mapcar
+   (lambda (type)
+	 (cond ((eq type 'link)
+		(cons type
+		  (lambda (link contents info)
+			(or (org-string-nw-p contents)
+			(org-element-property :raw-link link)
+	   ((eq type 'subscript)
+		(cons type
+		  (lambda (super contents info) (format "_%s" contents
+	   ((eq type 'superscript)
+		(cons type
+		  (lambda (super contents info) (format "^%s" contents
+	   ((eq type 'plain-text) (cons type (lambda (text info) text)))
+	   ((memq type '(code verbatim))
+		(cons type (lambda (obj contents info)
+			 (org-element-property :value obj
+	   ((memq type org-element-recursive-objects)
+		(cons type (lambda (obj contents info) contents)))
+	   ((memq type '(export-snippet
+			 footnote-reference latex-fragment line-break
+			 statistics-cookie target))
+		(cons type 'ignore
+   org-element-all-objects)
+  (org-export-backend-translate-table 'html))
+ info)
+info)))
+
  Bibliography
 
 (defun org-html-bibliography ()
@@ -1423,12 +1465,13 @@ INFO is a plist used as a communication channel."
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((title (org-export-data (plist-get info :title) info))
-	 (author (and (plist-get info :with-author)
-		  (let ((auth (plist-get info :author)))
-			(and auth (org-export-data auth info)
-	 (description (plist-get info :description))
-	 (keywords (plist-get info :keywords)))
+  (let ((title (org-export-data (plist-get info :title) info))
+	(author (and (plist-get info :with-author)
+		 (let ((auth (plist-get info :author)))
+		   (and auth (org-html--export-attribute auth info)
+	(description (org-html--export-attribute
+		  (plist-get info :description) info))
+	(keywords (org-html--export-attribute (plist-get info :keywords) info)))
 (concat
  (format "%s\n" title)
  (format
@@ -1442,10 +1485,11 @@ INFO is a plist used as a communication channel."
 	   (coding-system-get org-html-coding-system 'mime-charset))
 	  "iso-8859-1"))
  (format "\n")
- (and author (format "\n" author))
- (and description
+ (and (org-string-nw-p author)
+	  (format "\n" author))
+ (and (org-string-nw-p description)
 	  (format "\n" description))
- (and keywords
+ (and (org-string-nw-p keywords)
 	  (format "\n" keywords)
 
 (defun org-html--build-head (info)
-- 
1.8.2.1

Re: [O] New exporter and dates in tables

[Nicolas Goaziou]

Hello,

Carsten Dominik  writes:

> On 8 apr. 2013, at 13:27, Bernt Hansen  wrote:
>
>> Nicolas Goaziou  writes:
>> 
>>> Bernt Hansen  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 problem with #+AUTHOR

[Bastien]

Hi Bernt,

Nicolas Goaziou  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

[Carsten Dominik]

On 8 apr. 2013, at 13:27, Bernt Hansen  wrote:

> Nicolas Goaziou  writes:
> 
>> Bernt Hansen  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 and dates in tables

[Bernt Hansen]

Nicolas Goaziou  writes:

> Bernt Hansen  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 problem with #+AUTHOR

[Nicolas Goaziou]

Hello,

Bernt Hansen  writes:

> I have the following line in my org-mode document
>
> #+AUTHOR: Bernt Hansen (IRC:BerntH on freenode)
>
> On the old exporter this became
>
> 
>
> I just tried exporting this with the new exporter and I get this
>
> BerntH
> 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
>
> 

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]

Hello,

Bernt Hansen  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 and dates in tables

[Mike McLean]

On Apr 7, 2013, at 8:05 PM, Bernt Hansen  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:  :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 and publishing to HTML with styles

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  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 "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 publishing to HTML with styles

[Nicolas Goaziou]

Hello,

Bernt Hansen  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 "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 BUG/Change in behaviour

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Thorsten Jolitz  writes:
>
>> Nicolas Goaziou  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?
>
> There's no direct option, if that's your question. One possibility is,
> from `org-export-before-processing-hook', to copy each property drawer
> into an example block below. But it involves writing a couple lines of
> code, indeed.

Ok, I can do that, thanks for the hint. 

-- 
cheers,
Thorsten

Re: [O] New Exporter BUG/Change in behaviour

[Nicolas Goaziou]

Thorsten Jolitz  writes:

> Nicolas Goaziou  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?

There's no direct option, if that's your question. One possibility is,
from `org-export-before-processing-hook', to copy each property drawer
into an example block below. But it involves writing a couple lines of
code, indeed.


Regards,

-- 
Nicolas Goaziou

Re: [O] New Exporter BUG/Change in behaviour

[Thorsten Jolitz]

Nicolas Goaziou  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

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  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

[Thorsten Jolitz]

Nicolas Goaziou  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

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> Bernt Hansen  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 BUG/Change in behaviour

[Nicolas Goaziou]

Hello,

Bernt Hansen  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 html - latex - beamer

[Robert Eckl]

Charles Berry  writes:

>   ucsd.edu> writes:
>
>> 
>> Robert Eckl  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

[Charles Berry]

  ucsd.edu> writes:

> 
> Robert Eckl  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 html - latex - beamer

[cberry]

Robert Eckl  writes:

> Eric S Fraga  writes:
>
>> Robert Eckl  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

,
| 
| http://my.com"; alt="my altname" title="my full title" align="right" 
width="30%" padding="0em" padding-top="0em">my place.jpg
| More stuff
| 
| 
| item 1
| 
| item 1.1
| 
| item 1.2
| 
| 
| 
| 
`

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]

Eric S Fraga  writes:

> Robert Eckl  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] org-export-before-parsing-hook GOTCHA

[Bastien]

Hi Charles,

Charles Berry  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] Org LaTeX markup

[Charles Berry]

Charles Berry  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 html - latex - beamer

[Eric S Fraga]

Robert Eckl  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 html - latex - beamer

[Marcin Borkowski]

Dnia 2013-03-15, o godz. 21:55:42
Robert Eckl  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?

[Nicolas Goaziou]

Hello,

Rick Frankel  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] Beamer color theme

[Suvayu Ali]

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 :).



-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [new-exporter] Beamer color theme

[Eric S Fraga]

Suvayu Ali  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

[Suvayu Ali]

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.



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] deriving from derived backends?

[Rick Frankel]

Yes. 

On Mar 12, 2013, at 9:15 AM, Bastien  wrote:

> Hi Rick,
> 
> Rick Frankel  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?

[Bastien]

Hi Rick,

Rick Frankel  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] ignoring a headline on export to PDF?via?latex

[Suvayu Ali]

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.




Here are the commits:




Thanks a lot for your contribution.

:)

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [new exporter] [html] Tables of Contents

[Bastien]

Hi Samuel,

Samuel Wales  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] [html] Tables of Contents

[Jambunathan K]

Samuel Wales  writes:

> On 3/6/13, Bastien  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] [html] Tables of Contents

[Samuel Wales]

On 3/6/13, Bastien  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] Parameterized wrapper elements

[Jambunathan K]

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  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] Parameterized wrapper elements

[Rick Frankel]

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 
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
+  "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 "\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)
- "\n"))
+ (format "\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 chan

Re: [O] [New Exporter] Parameterized wrapper elements

[Rick Frankel]

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] feature request: BEGIN_LATEX_HEADER

[Achim Gratz]

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] feature request: BEGIN_LATEX_HEADER

[Eric S Fraga]

Nicolas Goaziou  writes:

> Hello,
>
> Eric S Fraga  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] Parameterized wrapper elements

[Bastien]

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