From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [ox] possible to modify org-export-document-properties OTG Date: Wed, 18 Mar 2015 17:42:01 +0100 Message-ID: <87iodytfza.fsf@gmx.us> References: <87vbi030eb.fsf@gmx.us> <87k2yg115l.fsf@nicolasgoaziou.fr> 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]:60678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYH2u-0007cl-N8 for emacs-orgmode@gnu.org; Wed, 18 Mar 2015 12:42:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYH2o-0006LM-UQ for emacs-orgmode@gnu.org; Wed, 18 Mar 2015 12:42:16 -0400 Received: from mout.gmx.net ([212.227.17.21]:63871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYH2o-0006L0-Ji for emacs-orgmode@gnu.org; Wed, 18 Mar 2015 12:42:10 -0400 Received: from x200s ([46.166.186.247]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MeQ43-1YtWmS2br5-00QCDQ for ; Wed, 18 Mar 2015 17:42:03 +0100 In-Reply-To: <87k2yg115l.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Tue, 17 Mar 2015 09:25:10 +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: emacs-orgmode@gnu.org Nicolas Goaziou writes: > 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. I think something like SUBJECT in ox-koma-letter makes sense. But what I'm really after is an "easy" way to control org-export-data from the backend definition. >> Or should org-element-parse-secondary-string be used with appropriate >> limitations? > > For now, I suggest to use `org-element-parse-secondary-string'. Why I don't like this is that it feels quite low-level (purely emotional) (org-export-data (oe-parse-2nd-string =E2=8B=AF) =E2=8B=AF) > At some point, I thought about adding a `parsed' behaviour to > `org-export-options-alist' as a shortcut. Presumably you'd want to be able to toggle it for elements of export-options. > 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_KYWORD_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. I don't understand why an export setting would affect an element interpretation such as org-element-map. Probably I have something different in mind than you. =E2=80=93Rasmus --=20 However beautiful the theory, you should occasionally look at the evidence