* subtree-export limitations
@ 2012-11-16 15:45 Philipp Kroos
2012-11-16 15:56 ` Alan Schmitt
2012-11-16 16:36 ` Suvayu Ali
0 siblings, 2 replies; 11+ messages in thread
From: Philipp Kroos @ 2012-11-16 15:45 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-16 15:45 subtree-export limitations Philipp Kroos
@ 2012-11-16 15:56 ` Alan Schmitt
2012-11-16 16:36 ` Suvayu Ali
1 sibling, 0 replies; 11+ messages in thread
From: Alan Schmitt @ 2012-11-16 15:56 UTC (permalink / raw)
To: Philipp Kroos; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-16 15:45 subtree-export limitations Philipp Kroos
2012-11-16 15:56 ` Alan Schmitt
@ 2012-11-16 16:36 ` Suvayu Ali
2012-11-17 12:25 ` Philipp Kroos
1 sibling, 1 reply; 11+ messages in thread
From: Suvayu Ali @ 2012-11-16 16:36 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-16 16:36 ` Suvayu Ali
@ 2012-11-17 12:25 ` Philipp Kroos
2012-11-17 12:48 ` Nicolas Goaziou
0 siblings, 1 reply; 11+ messages in thread
From: Philipp Kroos @ 2012-11-17 12:25 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 12:25 ` Philipp Kroos
@ 2012-11-17 12:48 ` Nicolas Goaziou
2012-11-17 13:33 ` Nicolas Goaziou
0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Goaziou @ 2012-11-17 12:48 UTC (permalink / raw)
To: Philipp Kroos; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 12:48 ` Nicolas Goaziou
@ 2012-11-17 13:33 ` Nicolas Goaziou
2012-11-17 15:12 ` Philipp Kroos
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Nicolas Goaziou @ 2012-11-17 13:33 UTC (permalink / raw)
To: Philipp Kroos; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 13:33 ` Nicolas Goaziou
@ 2012-11-17 15:12 ` Philipp Kroos
2012-11-17 16:00 ` Nicolas Goaziou
2012-11-19 13:55 ` Alan Schmitt
2012-12-22 18:58 ` Bastien
2 siblings, 1 reply; 11+ messages in thread
From: Philipp Kroos @ 2012-11-17 15:12 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 15:12 ` Philipp Kroos
@ 2012-11-17 16:00 ` Nicolas Goaziou
2012-11-18 11:23 ` Philipp Kroos
0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Goaziou @ 2012-11-17 16:00 UTC (permalink / raw)
To: Philipp Kroos; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 16:00 ` Nicolas Goaziou
@ 2012-11-18 11:23 ` Philipp Kroos
0 siblings, 0 replies; 11+ messages in thread
From: Philipp Kroos @ 2012-11-18 11:23 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 13:33 ` Nicolas Goaziou
2012-11-17 15:12 ` Philipp Kroos
@ 2012-11-19 13:55 ` Alan Schmitt
2012-12-22 18:58 ` Bastien
2 siblings, 0 replies; 11+ messages in thread
From: Alan Schmitt @ 2012-11-19 13:55 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Philipp Kroos, emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: subtree-export limitations
2012-11-17 13:33 ` Nicolas Goaziou
2012-11-17 15:12 ` Philipp Kroos
2012-11-19 13:55 ` Alan Schmitt
@ 2012-12-22 18:58 ` Bastien
2 siblings, 0 replies; 11+ messages in thread
From: Bastien @ 2012-12-22 18:58 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Philipp Kroos, emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-12-22 23:35 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-16 15:45 subtree-export limitations Philipp Kroos
2012-11-16 15:56 ` Alan Schmitt
2012-11-16 16:36 ` Suvayu Ali
2012-11-17 12:25 ` Philipp Kroos
2012-11-17 12:48 ` Nicolas Goaziou
2012-11-17 13:33 ` Nicolas Goaziou
2012-11-17 15:12 ` Philipp Kroos
2012-11-17 16:00 ` Nicolas Goaziou
2012-11-18 11:23 ` Philipp Kroos
2012-11-19 13:55 ` Alan Schmitt
2012-12-22 18:58 ` Bastien
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).