From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: [BUG] src_blocks - :results raw and replace don't work together Date: Mon, 07 Jul 2014 12:16:41 +0100 Message-ID: References: <87vbraroza.fsf@gmail.com> <877g3pcw4j.fsf@gmail.com> <8738edig5t.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X46ud-00012X-T3 for emacs-orgmode@gnu.org; Mon, 07 Jul 2014 07:16:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X46uX-0001ZN-Py for emacs-orgmode@gnu.org; Mon, 07 Jul 2014 07:16:47 -0400 Received: from plane.gmane.org ([80.91.229.3]:52895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X46uX-0001Z8-JO for emacs-orgmode@gnu.org; Mon, 07 Jul 2014 07:16:41 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X46uV-00024a-OL for emacs-orgmode@gnu.org; Mon, 07 Jul 2014 13:16:39 +0200 Received: from cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net ([81.102.136.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jul 2014 13:16:39 +0200 Received: from andreas.leha by cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jul 2014 13:16:39 +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 Hi Thorsten, Thorsten Jolitz writes: > Thorsten Jolitz writes: > >> Andreas Leha writes: >> >>> Hi Thorsten, >>> >>> Thorsten Jolitz writes: >>> >>>> Hi List, >>>> >>>> evaluating this 3 times does not work as expected: >>>> >>>> ,---- >>>> | * A >>>> | >>>> | #+header: :results raw replace >>>> | #+begin_src emacs-lisp >>>> | (+ 2 2) >>>> | #+end_src >>>> | >>>> | #+results: >>>> | 4 >>>> | 4 >>>> | 4 >>>> `---- >>>> >>>> Independent from argument order, 'replace' (which should be default >>>> anyway) is ignored. >>> >>> >>> Try adding the :wrap, which works for me: >>> >>> ,---- >>> | * A >>> | >>> | #+header: :results raw replace :wrap >>> | #+begin_src emacs-lisp >>> | (+ 2 2) >>> | #+end_src >>> | >>> | #+results: >>> | #+BEGIN_RESULTS >>> | 4 >>> | #+END_RESULTS >>> `---- >> >> This actually works here too, thanks. But is this wrapping results block >> 'neutral', i.e. is its content treated just like raw Org syntax in all >> situations? E.g. when I create a dblock from elisp, would >> >> #+results: >> #+BEGIN_RESULTS >> #+begin my-dblock >> (foo) >> #+end >> #+END_RESULTS >> >> be equivalent to >> >> #+results: >> #+begin my-dblock >> (foo) >> #+end >> >> in all cases? >> >> However, the combo ':results raw replace' seems like the natural fit >> when programmatically creating content in an Org file with a src_block >> that might eventually be evaluated more than once. That it does not work >> 'as-is' seems too much of a surprise to not call it a bug (at least when >> the manual does not mention it as special case). > > My use-case is actually this, and it won't work with wrapped results: > > ,---- > | ** Utility Function :ARCHIVE: > | > | #+name: create-subtree-with-dblock > | #+header: :var name="foo" > | #+header: :var prms=":bar loo" > | #+header: :results replace raw > | #+begin_src emacs-lisp > | (format > | (concat "\n\n** Overview :READONLY:\n\n" > | "#+begin: %s %s\n\n#+end:\n") > | name prms) > | #+end_src > | > | #+results: dblock > | > | > | ** Overview :READONLY: > | > | #+begin: foo :bar loo > | > | #+end: > `---- I am not in the position to answer this. But the combo "raw replace" is problematic, I think, in that it is hard to say how much there is to be replaced. So I think some delimiters (as produced by :wrap) are necesarry in the general case. If I understand correctly, you want to nest blocks: A source block nested in a results block. I think, that is not possible. So, for that use case, I guess, another construct (other than results block) would be necessary. But other people might have the proper answer here... Regards, Andreas