From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [Feature Request] Make property-drawers exportable Date: Wed, 25 Sep 2013 11:31:29 +0200 Message-ID: <33429FE3-CAA5-4F58-8536-135F96CA9C11@gmail.com> References: <8738shvzaj.fsf@gmail.com> <87ppvkiz8b.fsf@gmail.com> <87vc5cviu6.fsf@gmail.com> <871u80imo6.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C42FC2D6-C10E-4488-96D8-6A32A63D197C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOlRg-0006oy-AC for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 05:31:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOlRX-00031d-TT for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 05:31:44 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:58284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOlRX-00031C-KE for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 05:31:35 -0400 Received: by mail-wi0-f170.google.com with SMTP id cb5so4928573wib.3 for ; Wed, 25 Sep 2013 02:31:34 -0700 (PDT) In-Reply-To: <871u80imo6.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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org, Thorsten Jolitz --Apple-Mail=_C42FC2D6-C10E-4488-96D8-6A32A63D197C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. 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 wrote: > Thorsten Jolitz writes: >=20 >> Nicolas Goaziou writes: >=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. 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. >=20 > It seems I wasn't clear enough. More on this below. >=20 >> 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 don't deny anyone the right code this: >=20 > (defun my-latex-property-drawer (drawer contents info) > (concat "\\begin{example}\n" > (org-element-interpret-data drawer) > "\\end{example}")) >=20 > (org-export-define-derived-backend 'my-latex 'latex > :translate-alist '((property-drawer . my-latex-property-drawer))) >=20 > [...] >=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 > 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. >=20 > 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. >=20 > 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. >=20 > You have a choice. >=20 >=20 > Regards, >=20 > --=20 > Nicolas Goaziou >=20 --Apple-Mail=_C42FC2D6-C10E-4488-96D8-6A32A63D197C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJSQq1xAAoJEO+gg/nAZuwMo4YIAJQNsS6EYRBo3bUriSGeK+yn 81KyIuhp2n4N+Quh8wAf7AbbnZpWOAyxM+R3xCrFQ+ntSscIIfOZBJO80dqWBFhX Sc+swcZUBPijJIUpkOpYOrFsbZa5uudOG8QFk4oXafBezpIkMah93Ek7WH2+m19z qplF4nCJnvRWTI0bdWtNzPdBMkDDBtq8zUyXZkTRELCYWJnonhooDxXQHGv11MUf NKjyJ/qHEHwoi4f+ZZT5JPpRCndTtu2jkuRvwxp2o+GnhvlS9grWIFbP+U9t5PQz mtj9N0QizhpxvvI4u/DZe64UYMhas7U856V3ZvmpPGhFiWLSbYZU7228XhoYeng= =CeJ7 -----END PGP SIGNATURE----- --Apple-Mail=_C42FC2D6-C10E-4488-96D8-6A32A63D197C--