From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: Inline code :results replace not working Date: Mon, 10 Nov 2014 08:23:14 -0800 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=US-ASCII; format=flowed Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnrl7-000120-E4 for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 11:24:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xnrl1-0003nZ-Eg for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 11:24:05 -0500 Received: from iport-acv1-out.ucsd.edu ([132.239.0.176]:60151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnrl1-0003nG-1b for emacs-orgmode@gnu.org; Mon, 10 Nov 2014 11:23:59 -0500 In-Reply-To: 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: Andreas Leha Cc: emacs-orgmode@gnu.org On Mon, 10 Nov 2014, Andreas Leha wrote: > 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. >>>> [snip] >>> >>> 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. +1. I find myself writing an inline src block, then typing `C-c C-c C-x u' to view and then remove the result, then revise, and repeat. I'd be happy to just leave it in the document. >> >> 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. > [deleted ECM] It seems like implementing removable inline results cleanly is a nettlesome issue. But with the recent implementation of `org-babel-inline-result-wrap' it would be trivial to wrap results with something like "@@babel:%s@@", which can be found and removed more reliably than "=%s=". On export, either the :back-end property of such export-snippets could be revised to the backend in use by a parse-tree filter or the code in each org--export-snippet could be revised to accept such snippets. There is still the matter of adding code to find and remove those snippets where Nicolas pointed in ob-core.al. But it seems do-able. HTH, Chuck