On 25.9.2013, at 11:31, Carsten Dominik <carsten.domi...@gmail.com> wrote:
> 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. 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...... > > 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 <n.goaz...@gmail.com> wrote: > >> Thorsten Jolitz <tjol...@gmail.com> writes: >> >>> Nicolas Goaziou <n.goaz...@gmail.com> 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))) >> >> [...] >> >>> 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. >> >> 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. >> >> >> Regards, >> >> -- >> Nicolas Goaziou >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail