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 componen
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
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 th
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, bette
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
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
ex
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
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 concept
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 r
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
10 matches
Mail list logo
