emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [BUG] src_blocks - :results raw and replace don't work together


From: Thorsten Jolitz
Subject: Re: [O] [BUG] src_blocks - :results raw and replace don't work together
Date: Mon, 07 Jul 2014 13:59:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Andreas Leha <address@hidden> writes:

> Hi Thorsten,

>> 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.

I really don't want to dig into the Org Babel internals here, but that
might well be the reason, since inserting multi-line raw Org syntax into
the buffer makes it hard to tell whats new and whats old without some
extra work/bookkeeping (doing a diff or so ...). 

> 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.

Is a single 

,----
| #+results: dblock
`----

line seen as block (together will the following results)? Would surprise
me, but I don't know.

I don't want to nest blocks, I want to insert plain raw Org syntax into
the buffer that is subsequently treated just like the other content I
typed in by hand before (assuming the the leading #+results: line does
not affect the contents usual interpretation).

Maybe I'm bending Org-modes flexibility a bit too much here, but this
is my real-world use-case.

-- 
cheers,
Thorsten




reply via email to

[Prev in Thread] Current Thread [Next in Thread]