Re: [O] [Feature Request] Make property-drawers exportable

[Carsten Dominik]

Hi everyone,

I would like to come back to this issue.

While I can follow the argumentation that drawers are meta data and that it is 
really hard for a backend to do something general and correct with them, I am 
still wondering if it wouldn't be good to have some default way to export them 
anyway.  I'd be perfectly content to have is such that drawers can be exported 
as an @example block.  I also think that the export of drawers should 
definitely be OFF by default.

Having the default backends allow export of drawers as examples opens the door 
to use filters to modify it.  This has the advantage that a new backend does 
not have to be defined.  I am experimenting right now with defining filters 
with Babel in buffers, and I am finding this a powerful way to tweak the export 
of an individual file.

The reason why I am bringing this up is the following:

I am reviving the Org Issues file, see the other thread on the mailing list.  I 
would like to be able to export the LOOGBOOK state changes, and these are 
naturally located in a drawer.

The problem here is that the export is happening on worg, in an automatic way.  
So it is not really an easy option to define a new backend that will be used 
for just this file, because publishing on Worg uses org-to-html.

Now, being the person with the keys, I *could*, of course go and define a 
special backend on Worg that does what I want - but I do also understand the 
wish expressed by a couple of people in this thread.

We still have the variable org-export-with-drawers in ox.el.  My proposal would 
be to set the default to nil, plain and simple, and use a t value to make 
drawers export as @example.  Safe enough, and easy enough.

Regards

- Carsten

On 17.6.2013, at 21:04, Nicolas Goaziou <address@hidden> wrote:

> Thorsten Jolitz <address@hidden> writes:
> 
>> Nicolas Goaziou <address@hidden> writes:
> 
>>> Property drawers are Org meta data, they are not for user's
>>> cosumption. Though you can export some properties with macros (see
>>> {{{property{NAME}}}} macros).
>> 
>> I don't really agree. Property drawers are for meta data used by
>> Org-mode too, obviously, but they are perfectly suited for meta-data
>> about the document, as well as those simple data-base features described
>> in the manual.
> 
> It seems I wasn't clear enough. More on this below.
> 
>> Why deny Org users the full benefit of these other uses for
>> property-drawers by denying them the possibility to export their
>> document meta-data or data-bases?
> 
> I don't deny anyone the right code this:
> 
>  (defun my-latex-property-drawer (drawer contents info)
>    (concat "\\begin{example}\n"
>            (org-element-interpret-data drawer)
>            "\\end{example}"))
> 
>  (org-export-define-derived-backend 'my-latex 'latex
>    :translate-alist '((property-drawer . my-latex-property-drawer)))
> 
> [...]
> 
>> And whats wrong with a simple CD collection database implemented with
>> property-drawers, as described in the manual? Why shouldn't people be
>> allowed to export their CD database to some text-formatting backend?
> 
> Database example is interesting. My point is that you will never want to
> dump the whole database in your exported document because Org may fill
> it with its own meta-data, making the output look like garbage. Also,
> some backends (ox-icalendar, at least) create properties during export,
> so you would even get new properties in your output.
> 
> It's perfectly fine to export the part of a database you're interested
> in, like your whole CD collection, but it requires to filter out Org
> meta-data, and to properly format your own properties. This depends so
> much on the contents of your database that it is impossible to provide
> good defaults for it.
> 
> Therefore, default export doesn't even try. Instead, tools are provided
> to access values from your own database (again, macro
> {{{property(...)}}}) so they can be exported. If you have special needs
> for your database, just code them and plug them in.
> 
> You have a choice.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
>

signature.asc
Description: Message signed with OpenPGP using GPGMail