From: Thorsten Jolitz <tjolitz@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [Feature Request] Make property-drawers exportable
Date: Mon, 17 Jun 2013 22:03:09 +0200 [thread overview]
Message-ID: <87r4g0v72a.fsf@gmail.com> (raw)
In-Reply-To: 871u80imo6.fsf@gmail.com
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> 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
next prev parent reply other threads:[~2013-06-17 20:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 9:53 [Feature Request] Make property-drawers exportable Thorsten Jolitz
2013-06-17 14:33 ` Nicolas Goaziou
2013-06-17 15:48 ` Thorsten Jolitz
2013-06-17 18:54 ` Marcin Borkowski
2013-06-17 19:04 ` Nicolas Goaziou
2013-06-17 20:03 ` Thorsten Jolitz [this message]
2013-09-25 9:31 ` Carsten Dominik
2013-09-25 9:34 ` Carsten Dominik
2013-09-25 10:33 ` SUMMARY: " Carsten Dominik
2013-09-25 10:53 ` Thorsten Jolitz
2013-09-25 10:56 ` Carsten Dominik
2013-09-26 8:44 ` Marcin Borkowski
2013-09-25 11:51 ` Nicolas Goaziou
2013-09-25 12:08 ` Carsten Dominik
2013-09-25 12:13 ` Nicolas Goaziou
2013-09-25 12:26 ` Carsten Dominik
2013-09-25 20:57 ` Nicolas Goaziou
2013-09-26 11:28 ` Carsten Dominik
2013-09-26 11:48 ` Nicolas Goaziou
2013-09-26 11:51 ` Carsten Dominik
2013-09-26 14:33 ` Nicolas Goaziou
2013-09-26 16:06 ` Carsten Dominik
2013-09-25 12:52 ` Christian Moe
2013-09-25 12:12 ` Thorsten Jolitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4g0v72a.fsf@gmail.com \
--to=tjolitz@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).