emacs-orgmode
[Top][All Lists]
Advanced

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

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


From: Thorsten Jolitz
Subject: Re: [O] [Feature Request] Make property-drawers exportable
Date: Mon, 17 Jun 2013 22:03:09 +0200
User-agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> 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)))
>
> [...]

I'm sure you don't, but what if I write some library that should be used
by others that can't be assumed to have installed 'my-latex.el'?
Then I can't base that library on the use of property drawers, what I
really would like to do, since its a feature I like very much, and IMO
one of the best supported features in Org-mode both for interactive and
programmatical use. 

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

may be in the database example, but not in my application example -
there, all meta-info in property drawers is suitable for export, and no
other (Org-specific) meta info is added. 

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

Ok, these are arguments that are easily understood. I'll have to take a
second look at those macros, they definitely look ugly, but maybe they
are usefull..

Thanks so far. 

-- 
cheers,
Thorsten




reply via email to

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