emacs-orgmode
[Top][All Lists]

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

 From: Carsten Dominik Subject: Re: [O] [Feature Request] Make property-drawers exportable Date: Wed, 25 Sep 2013 11:34:31 +0200

On 25.9.2013, at 11:31, Carsten Dominik <address@hidden> wrote:

> 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.

P.S. of course there is also the possibility that I could use Babel to define
or temporarily modify an export backend on the fly - but I have not figured out
how this might work......

>
> 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:
>
>>
>>
>>>> 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