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:36:01 +0200 Message-ID: <87k36l7kj2.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> <87oavx7lgy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XF2KJ-00077I-08 for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 10:36:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XF2KC-0003Fp-9l for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 10:36:26 -0400 Received: from plane.gmane.org ([80.91.229.3]:37683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XF2KC-0003FR-44 for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 10:36:20 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XF2K8-0003yF-Kv for emacs-orgmode@gnu.org; Wed, 06 Aug 2014 16:36:16 +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:36:16 +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:36:16 +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 Thorsten Jolitz writes: > 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? I tried it out, works very nicely in this buffer: * ORG SCRATCH #+name: myPicoBlock #+header: :var X=5 #+begin_src picolisp :results value raw :tangle no (+ 3 X) #+end_src #+results: 8 Evaluating the following src-block with C-c C-c gives an error: ,---- | split-string: Wrong type argument: stringp, nil `---- but it can be copied to the *scratch* buffer and evaluated there. #+begin_src emacs-lisp :results (defun tj/try-parser-api () (let (ptree) (org-babel-map-src-blocks nil (when (string= lang "picolisp") (setq ptree (delq nil (list (org-element-at-point) ptree))))) (org-element-put-property (car ptree) :value " (* 5 X)\n") (message "%S" ptree) (mapconcat 'org-element-interpret-data ptree "\n"))) #+end_src Then interpreting works as expected: #+begin_src emacs-lisp :results raw (tj/try-parser-api) #+end_src #+results: #+NAME: myPicoBlock #+HEADER: :var X=5 #+BEGIN_SRC picolisp :results value raw :tangle no (* 5 X) #+END_SRC #+results: myPicoBlock 25 and I can actually use `org-element-put-property' on the car of the local parse-tree (but need to add an "\n"). -- cheers, Thorsten