emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Thorsten Jolitz <tjolitz@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: SUMMARY: [Feature Request] Make property-drawers exportable
Date: Wed, 25 Sep 2013 13:51:51 +0200	[thread overview]
Message-ID: <87a9j115m0.fsf@gmail.com> (raw)
In-Reply-To: <3EAEACD0-1B99-40B7-8A5D-AE491C9F8528@gmail.com> (Carsten Dominik's message of "Wed, 25 Sep 2013 12:33:17 +0200")

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> 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?

Unfortunately, this is a bit more difficult.

Indeed, `node-property' elements are distinct from `property-drawer'
elements. I.e., if we want to export property drawers as examples, as
you suggested earlier in this thread, we need to implement two functions
in each back-end: a transcoder for `node-property' and another one for
the `property-drawer' itself. Similarly, in order to implement your
current suggestion, we need both
`org-BACKEND-format-property-drawer-function' and
`org-BACKEND-format-node-property-function'.

IMO, this is a bit much for defcustoms, which are sold as an easy way to
configure Org behaviour.

There may be a slightly different option available: we can introduce
a new defcustom, e.g., `org-export-with-node-properties' (what symbol to
use for short item in OPTIONS?), which will trigger the following
behaviour:

  - when t, export completely all property drawers as examples;

  - when nil, do not export property drawers (default value);

  - when set to a list of strings, export property drawers as examples
    but only include properties matching these strings;

In that case, we need to:

  1. patch ox.el to previous behaviour;
  2. write two transcoder functions for each back-end where property
     drawers make sense and install them in back-end definitions.

For example, in the `latex' back-end, such functions could be:

  (defun org-latex-property-drawer (property-drawer contents info)
    "Transcode a PROPERTY-DRAWER element from Org to LaTeX.
  CONTENTS is the contents of the drawer, as a string.  INFO is
  a plist holding contextual information."
    (and (org-string-nw-p contents)
         (format "\\begin{verbatim}\n%s\\end{verbatim}" contents)))

  (defun org-latex-node-property (node-property contents info)
    "Transcode a NODE-PROPERTY element from Org to LaTeX.
  CONTENTS is nil.  INFO is a plist holding contextual information."
    (format "%s:%s"
            (org-element-property :key node-property)
            (let ((value (org-element-property :value node-property)))
              (if value (concat " " value) ""))))


Regards,

-- 
Nicolas Goaziou

  parent reply	other threads:[~2013-09-25 11:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17  9:53 [Feature Request] Make property-drawers exportable Thorsten Jolitz
2013-06-17 14:33 ` Nicolas Goaziou
2013-06-17 15:48   ` Thorsten Jolitz
2013-06-17 18:54     ` Marcin Borkowski
2013-06-17 19:04     ` Nicolas Goaziou
2013-06-17 20:03       ` Thorsten Jolitz
2013-09-25  9:31       ` Carsten Dominik
2013-09-25  9:34         ` Carsten Dominik
2013-09-25 10:33           ` SUMMARY: " Carsten Dominik
2013-09-25 10:53             ` Thorsten Jolitz
2013-09-25 10:56               ` Carsten Dominik
2013-09-26  8:44               ` Marcin Borkowski
2013-09-25 11:51             ` Nicolas Goaziou [this message]
2013-09-25 12:08               ` Carsten Dominik
2013-09-25 12:13                 ` Nicolas Goaziou
2013-09-25 12:26                   ` Carsten Dominik
2013-09-25 20:57                     ` Nicolas Goaziou
2013-09-26 11:28                       ` Carsten Dominik
2013-09-26 11:48                         ` Nicolas Goaziou
2013-09-26 11:51                           ` Carsten Dominik
2013-09-26 14:33                             ` Nicolas Goaziou
2013-09-26 16:06                               ` Carsten Dominik
2013-09-25 12:52                 ` Christian Moe
2013-09-25 12:12               ` Thorsten Jolitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a9j115m0.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=tjolitz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).