[O] subtree-export limitations
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: [O] subtree-export limitations
Philipp Kroos 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: [O] subtree-export limitations
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: [O] subtree-export limitations
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 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: [O] subtree-export limitations
Hello, Philipp Kroos 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: [O] subtree-export limitations
Nicolas Goaziou 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: [O] subtree-export limitations
Nicolas Goaziou writes: > Nicolas Goaziou 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: [O] subtree-export limitations
Philipp Kroos 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: [O] subtree-export limitations
Nicolas Goaziou writes: > Philipp Kroos 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: [O] subtree-export limitations
Nicolas Goaziou writes: > Nicolas Goaziou 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: [O] subtree-export limitations
Hi, Nicolas Goaziou 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
