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:34:31 +0200 Message-ID: <406B4BB5-5A38-44EB-AC97-DEA17644164C@gmail.com> References: <8738shvzaj.fsf@gmail.com> <87ppvkiz8b.fsf@gmail.com> <87vc5cviu6.fsf@gmail.com> <871u80imo6.fsf@gmail.com> <33429FE3-CAA5-4F58-8536-135F96CA9C11@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0AF3867C-D6B4-44C1-85A1-BE150540F64D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOlUe-00085E-CD for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 05:34:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOlUU-0003oe-2A for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 05:34:48 -0400 Received: from mail-we0-x234.google.com ([2a00:1450:400c:c03::234]:41754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOlUT-0003oU-K1 for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 05:34:37 -0400 Received: by mail-we0-f180.google.com with SMTP id u57so5850241wes.11 for ; Wed, 25 Sep 2013 02:34:36 -0700 (PDT) In-Reply-To: <33429FE3-CAA5-4F58-8536-135F96CA9C11@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=_0AF3867C-D6B4-44C1-85A1-BE150540F64D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25.9.2013, at 11:31, Carsten Dominik = wrote: > Hi everyone, >=20 > I would like to come back to this issue. >=20 > 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. >=20 > 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. P.S. of course there is also the possibility that I could use Babel to = define or temporarily modify an export backend on the fly - but I have = not figured out how this might work...... >=20 > The reason why I am bringing this up is the following: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Regards >=20 > - Carsten >=20 > On 17.6.2013, at 21:04, Nicolas Goaziou wrote: >=20 >> 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 >=20 --Apple-Mail=_0AF3867C-D6B4-44C1-85A1-BE150540F64D 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----- iQEcBAEBAgAGBQJSQq4nAAoJEO+gg/nAZuwMZC8H/1Vhz32ZfN0jmpeKvZqNqveD +ZAiDERVL6fWBOkP4bsjp3AhX4CphmnzVIsXw2WPXg7PJkyPYWUrsVVN8zImg3Bh FQrFV/5lS9BKfdxOadk4+HOQpa9ZcXsQsr1zKpla4XEoZXgGBfmCSDvK3h6BBNGT fAaBGjtTVAnB/rftmsdSXBC4JgqcxGrAzEviHk+mr8HPTQ3PQ5lx6+EpGArwJB07 D6ydngmEUAlEuFkMBms0yvvcZG46HcrLsV89yYuPcVs+RjgNSpC7Da52pwpbZtTD BSMG9bRNMqzux3w1nn5JVIkD/iYhr/s22vGXIVMdrJdrkivFLzeE8K/myOflpmE= =27n7 -----END PGP SIGNATURE----- --Apple-Mail=_0AF3867C-D6B4-44C1-85A1-BE150540F64D--