From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: (Maybe) enhance `org-element-src-block-interpreter'? Date: Wed, 06 Aug 2014 16:15:41 +0200 Message-ID: <87oavx7lgy.fsf@gmail.com> References: <87tx5qvrl4.fsf@gmail.com> <87oavywal0.fsf@gmail.com> <87fvha81zd.fsf@gmail.com> <87egwt26o3.fsf@nicolasgoaziou.fr> <87wqal7rl8.fsf@gmail.com> <87wqalztmj.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XF20c-0007sl-20 for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 10:16:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XF20W-00028d-1V for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 10:16:06 -0400 Received: from plane.gmane.org ([80.91.229.3]:41854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XF20V-00028Y-R1 for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 10:15:59 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XF20U-0005xB-PP for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 16:15:58 +0200 Received: from g231111166.adsl.alicedsl.de ([92.231.111.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Aug 2014 16:15:58 +0200 Received: from tjolitz by g231111166.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Aug 2014 16:15:58 +0200 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: > Thorsten Jolitz writes: > >> I see, thanks. I'm still getting used to the 'org-element API', but it >> seems to be much easier than I thought: just use >> org-element-at-point' and >> `org-element-interpret-data' in most cases ... > > Correct. > > For completeness, if you're working at the local level (i.e. with > `org-element-at-point'), available accessors are > > - `org-element-type' > - `org-element-property' > > When you're working at the global level (i.e. with > `org-element-parse-buffer'), you get another accessor, > `org-element-contents', and some tools to modify the parse tree > > - `org-element-put-property' > - `org-element-adopt-element' > - `org-element-insert-before' > - `org-element-extract-element' > - `org-element-set-element' > > In both cases, `org-element-interpret-data' is the only way to turn data > back into Org syntax. That makes things much clearer, thanks. I definitely would have used `org-element-put-property' to modify a 'local' parse-tree too, but I can just as well directly use `plist-put' on the raw plist in its cdr - would that be the correct way? -- cheers, Thorsten