[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]