subtree-export limitations

subtree-export limitations

[Philipp Kroos]

Hi,

currently the support for subtree export is somewhat limited due to the
fact that individual EXPORT_* options are allowed only once.
I.e., in the following the second latex-header-property will be ignored:

* Some subtree
  :PROPERTIES:
  :LATEX_CLASS: scrartcl
  :EXPORT_OPTIONS: toc:nil
  :EXPORT_LATEX_HEADER: \usepackage[ngerman]{babel}
  :EXPORT_LATEX_HEADER: \usepackage{xcolor}
  :END:

So would be any other EXPORT_OPTIONS-line. The responsible function is
org-export--get-subtree-options, which builds a list of already seen
keywords. The lists members are then ignored if seen again.
Is there any particular reason why this is done?

Sorry if this is documented or discussed somewhere already, I couldn't
find any reference that explains this behaviour.

Best regards,
Philipp

Re: subtree-export limitations

[Alan Schmitt]

Philipp Kroos <philipp.kroos@t-online.de> writes:

> currently the support for subtree export is somewhat limited due to the
> fact that individual EXPORT_* options are allowed only once.
> I.e., in the following the second latex-header-property will be ignored:
>
> * Some subtree
>   :PROPERTIES:
>   :LATEX_CLASS: scrartcl
>   :EXPORT_OPTIONS: toc:nil
>   :EXPORT_LATEX_HEADER: \usepackage[ngerman]{babel}
>   :EXPORT_LATEX_HEADER: \usepackage{xcolor}
>   :END:

We discussed this recently. A simple workaround is to create a new
export class with the headers you need. Another workaround is to put all
the headres in a very long line.

Alan

Re: subtree-export limitations

[Suvayu Ali]

On Fri, Nov 16, 2012 at 04:45:35PM +0100, Philipp Kroos wrote:
> 
> So would be any other EXPORT_OPTIONS-line. The responsible function is
> org-export--get-subtree-options, which builds a list of already seen
> keywords. The lists members are then ignored if seen again.
> Is there any particular reason why this is done?
> 

Since Alan gave you a workaround, I will try to answer the why.  I
believe the reason behind this behaviour is properties are not designed
to "accumulate" values.  I believe there is a special case treatment for
certain babel uses; as I'm hazy on the details, you have to look in the
archives from about a year back (my memory tells me September 2011 to
December 2011).  You should look for discussions involving Rainer(?)
and Eric Schulte.

Hope this helps.

-- 
Suvayu

Open source is the future. It sets us free.

Re: subtree-export limitations

[Philipp Kroos]

Ok, thanks to both of you. I'll stick with the workarounds pointed out
by Alan for now.
Anyway, I'm still curious if it wouldn't be feasible to treat
subtree-options more similar to inbuffer-options?
Maybe I'll have a look at that in some spare time, though I think my
understanding of the concepts might be insufficient yet. Any further
clues on this topic are much appreciated therfore!

Best regards, Philipp


Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> On Fri, Nov 16, 2012 at 04:45:35PM +0100, Philipp Kroos wrote:
>> 
>> So would be any other EXPORT_OPTIONS-line. The responsible function is
>> org-export--get-subtree-options, which builds a list of already seen
>> keywords. The lists members are then ignored if seen again.
>> Is there any particular reason why this is done?
>> 
>
> Since Alan gave you a workaround, I will try to answer the why.  I
> believe the reason behind this behaviour is properties are not designed
> to "accumulate" values.  I believe there is a special case treatment for
> certain babel uses; as I'm hazy on the details, you have to look in the
> archives from about a year back (my memory tells me September 2011 to
> December 2011).  You should look for discussions involving Rainer(?)
> and Eric Schulte.
>
> Hope this helps.

Re: subtree-export limitations

[Nicolas Goaziou]

Hello,

Philipp Kroos <philipp.kroos@t-online.de> writes:

> Anyway, I'm still curious if it wouldn't be feasible to treat
> subtree-options more similar to inbuffer-options?

It is feasible but it isn't consistent with Org mode properties.
According to manual (section 7.1):

    Note that a property can only have one entry per Drawer.

It might support "Property+" syntax, but it looks like this is
Babel-specific (no sign of such syntax in org.el, where property API is
defined). I will look into it (unless you want to do it).


Regards,

-- 
Nicolas Goaziou

Re: subtree-export limitations

[Nicolas Goaziou]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> It might support "Property+" syntax, but it looks like this is
> Babel-specific (no sign of such syntax in org.el, where property API is
> defined). I will look into it (unless you want to do it).

Well, scratch that: it already support :property+: syntax. I.e. try to
export subtree with:

* Test export
  :PROPERTIES:
  :export_latex_header: header1
  :export_latex_header+: header2
  :END:

  Test

Re: subtree-export limitations

[Philipp Kroos]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> It might support "Property+" syntax, but it looks like this is
>> Babel-specific (no sign of such syntax in org.el, where property API is
>> defined). I will look into it (unless you want to do it).
>
> Well, scratch that: it already support :property+: syntax. I.e. try to
> export subtree with:
>
> * Test export
>   :PROPERTIES:
>   :export_latex_header: header1
>   :export_latex_header+: header2
>   :END:
>
>   Test

Amazing! I didn't even know about the property+-syntax...
Now that's not as good as it *could* get since the headerlines are
separated by space rather than newline, but it's another very useful
option for a workaround at least.
After all, I think that a complete solution to this problem would break
the consistency of properties, like you said, or would have to introduce
yet another kind of syntax, what is clearly no option.
That said, I'm fine with the situation, but I'ld suggest a note in the
documentation that makes this limitation to subtree-exports clear (and
possibly points out the workarounds). What do you think?

Philipp

Re: subtree-export limitations

[Nicolas Goaziou]

Philipp Kroos <philipp.kroos@t-online.de> writes:

> That said, I'm fine with the situation, but I'ld suggest a note in the
> documentation that makes this limitation to subtree-exports clear (and
> possibly points out the workarounds). What do you think?

Sure. What should be written in that note? Where to put it? Or, better,
do you want to provide a patch for that?


Regards,

-- 
Nicolas Goaziou

Re: subtree-export limitations

[Philipp Kroos]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Philipp Kroos <philipp.kroos@t-online.de> writes:
>
>> That said, I'm fine with the situation, but I'ld suggest a note in the
>> documentation that makes this limitation to subtree-exports clear (and
>> possibly points out the workarounds). What do you think?
>
> Sure. What should be written in that note? Where to put it? Or, better,
> do you want to provide a patch for that?
>
>
> Regards,

In general, I'ld want to, yes. But now i've realized that this concerns
the users of contrib/* only..
The main documentation is sufficient for the standard, I think.
Are there attempts to port the documentation to the new features
already?

Best regards, Philipp

Re: subtree-export limitations

[Alan Schmitt]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> It might support "Property+" syntax, but it looks like this is
>> Babel-specific (no sign of such syntax in org.el, where property API is
>> defined). I will look into it (unless you want to do it).
>
> Well, scratch that: it already support :property+: syntax. I.e. try to
> export subtree with:
>
> * Test export
>   :PROPERTIES:
>   :export_latex_header: header1
>   :export_latex_header+: header2
>   :END:
>
>   Test

This is quite useful. Thanks for the information!

Alan

Re: subtree-export limitations

[Bastien]

Hi,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>   :PROPERTIES:
>   :export_latex_header: header1
>   :export_latex_header+: header2
>   :END:

FWIW I find this very ugly.

Why not having:

   :PROPERTIES:
   :export_latex_header: header1, header2
   :END:

And when the comma character is needed as a char component of a 
value, define the separator like this:

   :PROPERTIES:
   :export_latex_header(;): 2,3; 3,7...
   :END:

?

Same for #+PROPERTY - instead of the current

     #+PROPERTY: var  foo=1
     #+PROPERTY: var+ bar=2

Why not

     #+PROPERTY: var  foo=1 bar=2

?

Unless people scream at this I'll put this on my TODO list.

Thanks,

-- 
 Bastien