From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: SUMMARY: [Feature Request] Make property-drawers exportable Date: Wed, 25 Sep 2013 12:33:17 +0200 Message-ID: <3EAEACD0-1B99-40B7-8A5D-AE491C9F8528@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> <406B4BB5-5A38-44EB-AC97-DEA17644164C@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EA68F513-1712-4E15-B600-D25BB196E20C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOmPU-0001cF-VY for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 06:33:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOmPM-0004Pm-Eq for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 06:33:32 -0400 Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:46616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOmPM-0004Pd-58 for emacs-orgmode@gnu.org; Wed, 25 Sep 2013 06:33:24 -0400 Received: by mail-we0-f179.google.com with SMTP id x55so5943300wes.10 for ; Wed, 25 Sep 2013 03:33:23 -0700 (PDT) In-Reply-To: <406B4BB5-5A38-44EB-AC97-DEA17644164C@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=_EA68F513-1712-4E15-B600-D25BB196E20C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK, now that I have made a fool out of myself, I think I understand now how things work, and what I did not understand correctly in the discussion so far. 1. I misunderstood that drawers could not be exported in general with the new exporter. This is wrong, drawers are exported just fine as long as org-export-with-drawers is t or contains a list of drawer names that should be exported. The reason why I misunderstood was a bug in my test file where I have #+OPTIONS: d:(LOGBOOK) instead of d:("LOGBOOK") 2. If a drawer is selected for export, it will be exported as if it was part of the Org file. 3. The only exception to this rule are property drawers, which will currently not be exported by any of the backends. Nicolas proposed to define a derived backend that does export the property drawer, or he proposed to use macros to extract specific properties to include into the exported file. Both are viable options. I think this is all well and fine and very well argued. One possible remaining option would be to introduce user variables org-BACKEND-format-property-drawer-function in analogy org-BACKEND-format-drawer-function. This would provide an easy way to configure export of the property drawer as a whole, in a way that could be file-local. I would like to have this option. Nicolas, would you agree to a patch in this direction? - Carsten On 25.9.2013, at 11:34, Carsten Dominik = wrote: >=20 > On 25.9.2013, at 11:31, Carsten Dominik = wrote: >=20 >> 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. >=20 > 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 >=20 >=20 >>=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 >=20 --Apple-Mail=_EA68F513-1712-4E15-B600-D25BB196E20C 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----- iQEcBAEBAgAGBQJSQrvtAAoJEO+gg/nAZuwMCfEH/jSDm0o4uPBEYu6mnSJzyCrQ pmrhBeZwW739FSPxVRG+KcY6jK5pNEnCh09vTJRkUPEwWC6o9VzuDKhUBnWRT9g/ cIKc3Uqirg0cYrYakkrcPulIfJrrHI99hlzSGMlPXyUeuwsMDbD+n/MoFOT2ejl6 EdH6p5gYTWEOba3NpFZq+W/yQwk6l/986+dyGAg4BMnB8ylOAq2mA/2NTyFz0uu3 S7jFecCNeoycKdd5OrwoBpt0xpIpuJGr72kPWh6nH/4+ikIRPX8W7xDQhzd37tA3 PM7ZpWuhb9pnL6063mksLuPKJxtfFMp1WPgHoM8Yyb3OSmK66k0iRQB8swQJsN4= =8LZh -----END PGP SIGNATURE----- --Apple-Mail=_EA68F513-1712-4E15-B600-D25BB196E20C--