From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [ox] possible to modify org-export-document-properties OTG Date: Tue, 17 Mar 2015 09:25:10 +0100 Message-ID: <87k2yg115l.fsf@nicolasgoaziou.fr> References: <87vbi030eb.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXtKJ-0005qG-9z for emacs-orgmode@gnu.org; Tue, 17 Mar 2015 11:22:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXtKD-0000Oe-HZ for emacs-orgmode@gnu.org; Tue, 17 Mar 2015 11:22:39 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]:33127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXtKD-0000OU-3w for emacs-orgmode@gnu.org; Tue, 17 Mar 2015 11:22:33 -0400 In-Reply-To: <87vbi030eb.fsf@gmx.us> (rasmus@gmx.us's message of "Tue, 17 Mar 2015 01:58:36 +0100") 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: Rasmus Cc: emacs-orgmode@gnu.org Hello, Rasmus writes: > Is it possible to modify or extend org-export-document-properties on the > go? And would it be OK? `org-export-document-properties' is a defconst, which is computed from `org-element-document-properties', also a defconst. So, no, it isn't meant for that. Document properties are keywords where `org-element-context' is allowed to return an object. It doesn't make sense to add random keywords specific to some export back-ends to the list. > Or should org-element-parse-secondary-string be used with appropriate > limitations? For now, I suggest to use `org-element-parse-secondary-string'. > It would be useful 'cause it's an easy way to have a property parsed. In > ox-koma-letter.el it would make sense to make #+SUBJECT a document > property (ATM org-syntax isn't interpreted). In some backends it would > probably also make sense to make #+KEYWORDS parsed. I'm also working on a > patch to add #+SUBTITLE, which would also benefit from being easily added > as a document-property. You can always use `org-element-parse-secondary-string' on the keyword value and `org-export-data' or `org-export-data-with-backend' on it. At some point, I thought about adding a `parsed' behaviour to `org-export-options-alist' as a shortcut. Sadly, I cannot remember why I didn't implement the idea eventually. It may be related to `org-element-map', which couldn't map over data in such keywords, or the fact that it would be confusing wrt `org-element-context'. E.g., if we consider the two keywords #+TITLE: *boXld* #+PARSED_K=C3=8AYWORD_IN_SOME_BACKEND_IGNORED_IN_OTHERS: *boXld* in the former, `org-element-context' at "X" returns a `bold' object, in the latter, a `keyword' element. Note that I'm not arguing it should return a `bold' object in both cases, it really shouldn't, but it can be confusing and potentially trigger false bug reports. Regards, --=20 Nicolas Goaziou