emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* 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).