From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: Inline code :results replace not working Date: Mon, 10 Nov 2014 11:42:06 +0000 Message-ID: References: <545C987E.4020203@gmail.com> <87fvdtwfg3.fsf@nicolasgoaziou.fr> <8661enxvfi.fsf@example.com> <86mw7z4ag3.fsf@example.com> <86y4rj2tm1.fsf@example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnnMd-0004Sv-3t for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 06:42:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnnMT-00009c-Il for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 06:42:31 -0500 Received: from plane.gmane.org ([80.91.229.3]:54462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnnMT-00008Y-CO for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 06:42:21 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XnnMR-0005WU-Tc for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 12:42:19 +0100 Received: from 193.63.220.190 ([193.63.220.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Nov 2014 12:42:19 +0100 Received: from andreas.leha by 193.63.220.190 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Nov 2014 12:42:19 +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: emacs-orgmode@gnu.org Hi Sebastien, Sebastien Vauban writes: > Andreas Leha wrote: >> Sebastien Vauban writes: >>> Andreas Leha wrote: >>>>> For me, that's the correct behavior, as inline code blocks are >>>>> *only expected to be evaluated during export*. >>>> >>>> I disagree here. >>> >>> Though, this is what Eric Schulte wrote: >>> >>> ┌──── >>> │ Currently inline blocks like don't associate themselves with their >>> │ results, they are only expected to be evaluated on export. >>> └──── >>> >>> If things have changed, I'm not aware of it. >>> >>>> As limiting the use of inline code to eval-on-export-only renders >>>> all the org-babel-execute-subtree and related functionality useless. >> >> I have been using inline results for reports quite a bit, but not >> lately. I might be wrong here, but from my memory they used to work >> (i.e. were replaceable) for a while (at least when 'wrapped') unless >> they were set to produce 'raw' results (which was a serious limitation >> and led me to change my workflow). >> >> PS: a quick check reveals that they are indeed not replaceable (even >> when wrapped) >> >> Nonetheless, from a literate programming perspective, I think that >> replaceable (and raw) inline results are definitely desirable. >> Regardless of the state of their implementation in orgmode right now. > > FWIW, I'm not -- yet? -- convinced we should see the results of inline > code blocks inlined in the paragraph (and I'm not sure either it does > not cause interpretation problems); but, for sure, I'd love to be able > to preview the value interactively, at least. > >> So, I do not doubt, that you and Nicolas are right with that >> replaceable inline results are not implemented and are -- from >> orgmodes perspective -- expected to be evaluated only during export. >> >> My message was meant more as a feature request saying that I consider >> replaceable inline results useful and would like to see them supported >> by org. > > Could you better explain your statement: "Limiting the use of inline > code to eval-on-export-only renders all the org-babel-execute-subtree > and related functionality useless"? > > I'm not sure to fully understand your use-case. That'd certainly be > worth explaining why you think it must be changed in the first instance > if you'd like Eric or Nicolas (or someone else) to change that. > Consider this simple toy example. If you press 'C-c C-v s' in the subtree, the document is 'broken' for export. If you press 'C-c C-v s' twice or more the document is 'broken' even for display. --8<---------------cut here---------------start------------->8--- #+PROPERTY: header-args:R :session *testR* * Simplistic Literate Program Let us generate some data $X$ with #+begin_src R :exports code :results none X <- rnorm(1:1000) #+end_src and plot the density of it #+begin_src R :results graphics :file test.png :exports both plot(density(X)) #+end_src #+results: [[file:test.png]] This data has mean src_R{mean(X)}. --8<---------------cut here---------------end--------------->8--- Regards, Andreas