From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@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 14:08:16 +0200 [thread overview]
Message-ID: <39CF3890-4884-4894-8670-627AC5B4E935@gmail.com> (raw)
In-Reply-To: <87a9j115m0.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]
On 25.9.2013, at 13:51, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 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;
This sounds good to me. How about allowing also a function
as a value and that function will receive the list of properties
and do with it as it pleases.
I like it!
- Carsten
>
> 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
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2013-09-25 12:08 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
2013-09-25 12:08 ` Carsten Dominik [this message]
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=39CF3890-4884-4894-8670-627AC5B4E935@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
--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).