From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [Feature Request] Make property-drawers exportable Date: Mon, 17 Jun 2013 22:03:09 +0200 Message-ID: <87r4g0v72a.fsf@gmail.com> References: <8738shvzaj.fsf@gmail.com> <87ppvkiz8b.fsf@gmail.com> <87vc5cviu6.fsf@gmail.com> <871u80imo6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UofeA-0000Je-Cm for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 16:03:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uofe8-0001mV-VU for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 16:03:26 -0400 Received: from plane.gmane.org ([80.91.229.3]:38899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uofe8-0001mI-N7 for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 16:03:24 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Uofe6-0003SP-6V for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 22:03:22 +0200 Received: from g231104022.adsl.alicedsl.de ([92.231.104.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jun 2013 22:03:22 +0200 Received: from tjolitz by g231104022.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jun 2013 22:03:22 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Thorsten Jolitz writes: > >> Nicolas Goaziou 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