From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [ox] possible to modify org-export-document-properties OTG Date: Sun, 22 Mar 2015 01:06:00 +0100 Message-ID: <87vbhtvqtz.fsf@gmx.us> References: <87vbi030eb.fsf@gmx.us> <87k2yg115l.fsf@nicolasgoaziou.fr> <87iodytfza.fsf@gmx.us> <877fua3q0z.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZTPH-0004sv-9A for emacs-orgmode@gnu.org; Sat, 21 Mar 2015 20:06:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZTPC-0008JO-9q for emacs-orgmode@gnu.org; Sat, 21 Mar 2015 20:06:19 -0400 Received: from plane.gmane.org ([80.91.229.3]:33983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZTPC-0008Ix-2b for emacs-orgmode@gnu.org; Sat, 21 Mar 2015 20:06:14 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YZTP4-00037e-Un for emacs-orgmode@gnu.org; Sun, 22 Mar 2015 01:06:06 +0100 Received: from 46.166.186.232 ([46.166.186.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Mar 2015 01:06:06 +0100 Received: from rasmus by 46.166.186.232 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Mar 2015 01:06:06 +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: >> I think something like SUBJECT in ox-koma-letter makes sense. > > It seems we are failing to communicate. Probably I'm just slower :) > I have nothing against SUBJECT being parsed in "ox-koma-letter". > However, `org-element-document-properties' are keywords expected to be > parsed in _every_ export back-end. This is not for SUBJECT. Yep. That was why I asked if it was possible to add it on backend basis. But the oe-parse-secondary-string is fin. Now I know. > I mean to use `parsed' at the BEHAVIOR position in > `org-export-options-alist' entries. So, obviously, this is triggered per > keyword. I /think/ that is what I would like. But I don't understand the what you mean concretely: would you have something like: (:subject "SUBJECT" nil nil space parsed) I don't understand how it could replace the behavior parameter. Would it be a cons? > If you map over a parse tree, e.g., looking for bold objects, it is > a bit tricky to tell `org-element-map' that SUBJECT is no longer > a regular keyword but now possibly contains objects. > > OTOH, we can consider that SUBJECT is still a regular keyword, and that > the property the keyword sets (e.g., :koma-letter-subject) contains the > objects. > > In this case, it is no longer ambiguous for `org-element-map' and al., > and `parsed' becomes an interesting shortcut. I agree this is a difficult problem. Personally, I think it is fine to consider a keyword as a keyword and nothing more, and not consider content within a keyword. However, as I recall, John had a post a while back about mapping over bold in CAPTIONS or something like that. I think it may be a mess to interpret content of a keyword at org-element-map level. Consider if #+SUBJECT is interpreted with in ox-koma-letter but not in an imaginary ox-new-letter. Would it not be confusing? —Rasmus -- Dung makes an excellent fertilizer