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

[Carsten Dominik]

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

signature.asc
Description: Message signed with OpenPGP using GPGMail