From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcin Borkowski Subject: Re: [Feature Request] Make property-drawers exportable Date: Mon, 17 Jun 2013 20:54:34 +0200 Message-ID: <20130617205434.031ab429@aga-netbook> References: <8738shvzaj.fsf@gmail.com> <87ppvkiz8b.fsf@gmail.com> <87vc5cviu6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoeZe-0003pj-UL for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 14:54:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoeZb-0003Ef-Ve for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 14:54:42 -0400 Received: from msg.wmi.amu.edu.pl ([2001:808:114:2::50]:33728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoeZb-0003EI-Kp for emacs-orgmode@gnu.org; Mon, 17 Jun 2013 14:54:39 -0400 Received: from localhost (localhost [127.0.0.1]) by msg.wmi.amu.edu.pl (Postfix) with ESMTP id 92E9D419A0 for ; Mon, 17 Jun 2013 20:54:36 +0200 (CEST) Received: from msg.wmi.amu.edu.pl ([127.0.0.1]) by localhost (msg.wmi.amu.edu.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-PUMzPcfZwB for ; Mon, 17 Jun 2013 20:54:36 +0200 (CEST) Received: from aga-netbook (99-52.echostar.pl [213.156.99.52]) by msg.wmi.amu.edu.pl (Postfix) with ESMTPSA id 5637742082 for ; Mon, 17 Jun 2013 20:54:36 +0200 (CEST) In-Reply-To: <87vc5cviu6.fsf@gmail.com> 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 Dnia 2013-06-17, o godz. 17:48:49 Thorsten Jolitz napisa=C5=82(a): > Nicolas Goaziou writes: >=20 > > Hello, > > > > Thorsten Jolitz writes: > > > >> for me property-drawers are a very useful feature of Org-mode, > >> since the need to store meta-data for a document is so frequent and > >> property-drawers are human- and machine-readable, easy to handle > >> interactively and programmatically, and avoid all that nasty > >> redundancy and accidental variation of giving meta-data as free > >> text. > >> > >> However, property-drawers are not exported except separating blank > >> lines. This is a real pity in my eyes, since parts of an Org-mode > >> document that can't be exported are visible only to the author of > >> the document and a few fellows that use the raw Org document too. > >> This might make sense in some cases, but in others the property > >> information should be visible in the exported docs too. > > > > This has been requested before. >=20 > I know, because I missed that feature before, and I remember others > did ask for it too. >=20 > > 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). >=20 > I don't really agree. Neither do I! > 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. 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? >=20 > I mean, everything else in Org-mode is more or less configurable, why > hardcode in this case that export is (by default) impossible? >=20 > Whats wrong e.g. with >=20 > ,------------------------------- > | * My Source-file > | :PROPERTIES: > | :github-repo: <> > | :licence: <> > | :END: > `------------------------------- >=20 > ? >=20 > This is not Org meta-data, its meaningless to Org-mode, but its > meta-data about the document, easily stored and accessed, readable, > and stays in the background during visibility cycling. And its for > user consumption, thus there should be a way to export this. >=20 > 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? >=20 > IMO there should be transoder functions for property-drawers just like > for other elements in the main backend libs, not in some derived > backend. If by default they are not exported, nothing changes, but at > least the user has a choice. Another use-case: properties might be used as the source of data in tables/spreadsheets. Now I *really* would like to export my spreadsheet to LaTeX, together with the "source data". (As I wrote on the list some time ago, I used spreadsheets to prepare solutions to problems for a course I'm teaching. Exporting the solutions w/o the givens is stupid. Of course, I could put them also in the table, but this seems artificial for me. Another use case: assume I prepare a test, with each (sub)node a problem. It would be natural to put the maximum mark for each problem in properties, and (obviously) I'd like to be able to export them (mapped to some LaTeX command, maybe even something like \orgproperty{name}{value} - I could deal with the formatting on the LaTeX side then.). > cheers, > Thorsten Best, --=20 Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University