From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philipp Kroos Subject: Re: subtree-export limitations Date: Sat, 17 Nov 2012 13:25:20 +0100 Message-ID: <87lie0bemn.fsf@t-online.de> References: <87r4ntmu00.fsf@t-online.de> <20121116163645.GF24384@kuru.dyndns-at-home.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZhSs-0000Nk-Vn for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 07:25:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZhSp-00086B-Ta for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 07:25:38 -0500 Received: from mailout03.t-online.de ([194.25.134.81]:59542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZhSp-00085p-N1 for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 07:25:35 -0500 In-Reply-To: <20121116163645.GF24384@kuru.dyndns-at-home.com> (Suvayu Ali's message of "Fri, 16 Nov 2012 17:36:45 +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: Suvayu Ali Cc: emacs-orgmode@gnu.org Ok, thanks to both of you. I'll stick with the workarounds pointed out by Alan for now. Anyway, I'm still curious if it wouldn't be feasible to treat subtree-options more similar to inbuffer-options? Maybe I'll have a look at that in some spare time, though I think my understanding of the concepts might be insufficient yet. Any further clues on this topic are much appreciated therfore! Best regards, Philipp Suvayu Ali writes: > On Fri, Nov 16, 2012 at 04:45:35PM +0100, Philipp Kroos wrote: >> >> So would be any other EXPORT_OPTIONS-line. The responsible function is >> org-export--get-subtree-options, which builds a list of already seen >> keywords. The lists members are then ignored if seen again. >> Is there any particular reason why this is done? >> > > Since Alan gave you a workaround, I will try to answer the why. I > believe the reason behind this behaviour is properties are not designed > to "accumulate" values. I believe there is a special case treatment for > certain babel uses; as I'm hazy on the details, you have to look in the > archives from about a year back (my memory tells me September 2011 to > December 2011). You should look for discussions involving Rainer(?) > and Eric Schulte. > > Hope this helps.