Inline code :results replace not working

Inline code :results replace not working

[mcg]

Hello,

I use inline code for simple calculations to insert numeric results into
text apart from "normal" code blocks for more complex calculations and
graphics (all in R).


The :results replace option is not working for inline code, even if I
explicitly set it in the code block. So I get

#+PROPERTY: session *R*

  #+begin_src R :results replace value
2+3
  #+end_src

  #+RESULTS:
  : 5

src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=

I would really like to have numeric outcome in the buffer (not only
minibuffer upon evaluation) but also evaluate the whole buffer when
exporting to have everything updated.

What is the problem here? For now I would have to
- evaluate only on export and keep :results silent
- evaluate all manually - meaning I get repeated results if I call
org-evaluate buffer

Cheers,

Michael


System:
LMDE Update Pack 8 (jessie)
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.4) of 2013-09-27
on trouble, modified by Debian
Org version 8.2.10 (release_8.2.10-5-g20dcd0).

Re: Inline code :results replace not working

[Nicolas Goaziou]

Hello,

mcg <giepen.m@googlemail.com> writes:

> I use inline code for simple calculations to insert numeric results into
> text apart from "normal" code blocks for more complex calculations and
> graphics (all in R).
>
>
> The :results replace option is not working for inline code, even if I
> explicitly set it in the code block. So I get
>
> #+PROPERTY: session *R*
>
>   #+begin_src R :results replace value
> 2+3
>   #+end_src
>
>   #+RESULTS:
>   : 5
>
> src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=
>
> I would really like to have numeric outcome in the buffer (not only
> minibuffer upon evaluation) but also evaluate the whole buffer when
> exporting to have everything updated.
>
> What is the problem here? For now I would have to
> - evaluate only on export and keep :results silent
> - evaluate all manually - meaning I get repeated results if I call
> org-evaluate buffer

:results replace is not implemented (yet?) for inline source blocks. See
"ob-core.el", line 2139 (in master branch).


Regards,

-- 
Nicolas Goaziou

Re: Inline code :results replace not working

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Hello,
>
> mcg <giepen.m-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
>> I use inline code for simple calculations to insert numeric results into
>> text apart from "normal" code blocks for more complex calculations and
>> graphics (all in R).
>>
>>
>> The :results replace option is not working for inline code, even if I
>> explicitly set it in the code block. So I get
>>
>> #+PROPERTY: session *R*
>>
>>   #+begin_src R :results replace value
>> 2+3
>>   #+end_src
>>
>>   #+RESULTS:
>>   : 5
>>
>> src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=
>>
>> I would really like to have numeric outcome in the buffer (not only
>> minibuffer upon evaluation) but also evaluate the whole buffer when
>> exporting to have everything updated.
>>
>> What is the problem here? For now I would have to
>> - evaluate only on export and keep :results silent
>> - evaluate all manually - meaning I get repeated results if I call
>> org-evaluate buffer
>
> :results replace is not implemented (yet?) for inline source blocks.

For me, that's the correct behavior, as inline code blocks are *only
expected to be evaluated during export*.

They are not intended to be executed in the buffer during normal use.
Hence, the above behavior (having the results inlined) is weird, and/or
buggy.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Inline code :results replace not working

[Andreas Leha]

Hi

Sebastien Vauban <sva-news@mygooglest.com> writes:
> Nicolas Goaziou wrote:
>> Hello,
>>
>> mcg <giepen.m@googlemail.com> writes:
>>
>>> I use inline code for simple calculations to insert numeric results into
>>> text apart from "normal" code blocks for more complex calculations and
>>> graphics (all in R).
>>>
>>>
>>> The :results replace option is not working for inline code, even if I
>>> explicitly set it in the code block. So I get
>>>
>>> #+PROPERTY: session *R*
>>>
>>>   #+begin_src R :results replace value
>>> 2+3
>>>   #+end_src
>>>
>>>   #+RESULTS:
>>>   : 5
>>>
>>> src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=
>>>
>>> I would really like to have numeric outcome in the buffer (not only
>>> minibuffer upon evaluation) but also evaluate the whole buffer when
>>> exporting to have everything updated.
>>>
>>> What is the problem here? For now I would have to
>>> - evaluate only on export and keep :results silent
>>> - evaluate all manually - meaning I get repeated results if I call
>>> org-evaluate buffer
>>
>> :results replace is not implemented (yet?) for inline source blocks.
>
> For me, that's the correct behavior, as inline code blocks are *only
> expected to be evaluated during export*.
>

I disagree here.  As limiting the use of inline code to
eval-on-export-only renders all the org-babel-execute-subtree and
related functionality useless.

Regards,
Andreas

Re: Inline code :results replace not working

[Sebastien Vauban]

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.  As limiting the use of inline code to
> eval-on-export-only renders all the org-babel-execute-subtree and
> related functionality useless.

Though, this is what Eric Schulte wrote:

  ┌──── https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00490.html
  │
  │ Currently inline blocks like don't associate themselves with their
  │ results, they are only expected to be evaluated on export.
  └────

Admittedly, this is an old quote (2012).  If things have changed, I'm
not aware of it -- but that does not mean it did not.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Inline code :results replace not working

[Andreas Leha]

Hi,

Sebastien Vauban <sva-news@mygooglest.com> 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.  As limiting the use of inline code to
>> eval-on-export-only renders all the org-babel-execute-subtree and
>> related functionality useless.
>
> Though, this is what Eric Schulte wrote:
>
>   ┌──── https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00490.html
>   │
>   │ Currently inline blocks like don't associate themselves with their
>   │ results, they are only expected to be evaluated on export.
>   └────
>
> Admittedly, this is an old quote (2012).  If things have changed, I'm
> not aware of it -- but that does not mean it did not.

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

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.

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.

Regards,
Andreas

PS:
a quick check reveals that they are indeed not replaceable (even
when wrapped)
--8<---------------cut here---------------start------------->8---
* Test replacement of inline results

Here is an inline result src_R[:results wrap replace]{3+2}.
--8<---------------cut here---------------end--------------->8---

Re: Inline code :results replace not working

[Sebastien Vauban]

Andreas Leha wrote:
> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> 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.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Inline code :results replace not working

[Andreas Leha]

Hi Sebastien,

Sebastien Vauban <sva-news@mygooglest.com> writes:
> Andreas Leha wrote:
>> Sebastien Vauban <sva-news@mygooglest.com> 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

Re: Inline code :results replace not working

[Charles C. Berry]

On Mon, 10 Nov 2014, Andreas Leha wrote:

> Hi Sebastien,
>
> Sebastien Vauban <sva-news@mygooglest.com> writes:
>> Andreas Leha wrote:
>>> Sebastien Vauban <sva-news@mygooglest.com> 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-<backend>-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

Re: Inline code :results replace not working

[Ista Zahn]

On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry <ccberry@ucsd.edu> wrote:
> On Mon, 10 Nov 2014, Andreas Leha wrote:

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

+1 from me as well. For exactly the reason Andreas illustrated I've
given up on using inline results for the past year or so. Would be
great to see this feature become usable by implementing a system for
replacing them.

-Ista

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

Re: Inline code :results replace not working

[Grant Rettke]

On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn <istazahn@gmail.com> wrote:
> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry <ccberry@ucsd.edu> wrote:
>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>
> [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.
>
> +1 from me as well. For exactly the reason Andreas illustrated I've
> given up on using inline results for the past year or so. Would be
> great to see this feature become usable by implementing a system for
> replacing them.

My approach here has been to use "hidden" source blocks that aren't
exported but make it
really easy to see the result during development. These settings
should work on any configuration,
so I didn't include mine here.

✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
#+BEGIN_SRC R
a = 10
b = 23
c = a + b
#+END_SRC

#+BEGIN_SRC R :results output silent :exports none
c
#+END_SRC

The user calculated src_R{c}.
✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂

When you use these functions
http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
the addition of these "hidden" blocks hav almost zero cost and give me
what I want.

Re: Inline code :results replace not working

[Thomas S. Dye]

Grant Rettke <gcr@wisdomandwonder.com> writes:

>
> My approach here has been to use "hidden" source blocks that aren't
> exported but make it
> really easy to see the result during development. These settings
> should work on any configuration,
> so I didn't include mine here.

I think you've set the :session header argument somewhere.

>
> ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
> #+BEGIN_SRC R
> a = 10
> b = 23
> c = a + b
> #+END_SRC
> #+BEGIN_SRC R :results output silent :exports none
> c
> #+END_SRC
>
> The user calculated src_R{c}.
> ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
>
> When you use these functions
> http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
> the addition of these "hidden" blocks hav almost zero cost and give me
> what I want.
>
>

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Inline code :results replace not working

[Grant Rettke]

On Mon, Nov 10, 2014 at 2:45 PM, Thomas S. Dye <tsd@tsdye.com> wrote:
> Grant Rettke <gcr@wisdomandwonder.com> writes:
>
>>
>> My approach here has been to use "hidden" source blocks that aren't
>> exported but make it
>> really easy to see the result during development. These settings
>> should work on any configuration,
>> so I didn't include mine here.
>
> I think you've set the :session header argument somewhere.

I did. I use:

#+begin_src emacs-lisp
(print emacs-version)
#+end_src

#+NAME:
#+begin_example

"24.3.1"
#+end_example

#+begin_src emacs-lisp
(print org-version)
#+end_src

#+NAME:
#+begin_example

"8.2.10"
#+end_example

#+begin_src emacs-lisp
(print (pp-to-string org-babel-default-header-args))
#+end_src

#+NAME:
#+begin_example

"((:eval . \"always\")
 (:padline . \"yes\")
 (:noweb . \"no-export\")
 (:exports . \"both\")
 (:results . \"output replace\")
 (:comments . \"noweb\")
 (:session . \"none\")
 (:cache . \"no\")
 (:hlines . \"no\")
 (:tangle . \"no\"))
"
#+end_example

#+begin_src emacs-lisp
(print (pp-to-string org-babel-default-header-args:R))
#+end_src

#+NAME:
#+begin_example

"((:session . \"*R*\"))
"
#+end_example

Re: Inline code :results replace not working

[Ista Zahn]

On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke <gcr@wisdomandwonder.com> wrote:
> On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn <istazahn@gmail.com> wrote:
>> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry <ccberry@ucsd.edu> wrote:
>>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>>
>> [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.
>>
>> +1 from me as well. For exactly the reason Andreas illustrated I've
>> given up on using inline results for the past year or so. Would be
>> great to see this feature become usable by implementing a system for
>> replacing them.
>
> My approach here has been to use "hidden" source blocks that aren't
> exported but make it
> really easy to see the result during development. These settings
> should work on any configuration,
> so I didn't include mine here.
>
> ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
> #+BEGIN_SRC R
> a = 10
> b = 23
> c = a + b
> #+END_SRC
>
> #+BEGIN_SRC R :results output silent :exports none
> c
> #+END_SRC
>
> The user calculated src_R{c}.
> ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
>
> When you use these functions
> http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-bindings-and-useful-functions
> the addition of these "hidden" blocks hav almost zero cost and give me
> what I want.

The problem I have is not that I miss being able to see results of the
inline block in the org-mode buffer. The problem is that I don't want
blocks to be evaluated on export (too time consuming in many cases).
So I turn that off, and either evaluate the blocks one at a time (I'm
aware of the dangers of this, not my point here) or call
org-babel-execute-buffer. Everytime I do that I get duplicate output
from inline code. As far as I can see inline code +
org-babel-execute-buffer is incompatible, which is why I gave up on
the former.

Best,
Ista

Re: Inline code :results replace not working

[Grant Rettke]

On Mon, Nov 10, 2014 at 7:53 PM, Ista Zahn <istazahn@gmail.com> wrote:
> The problem is that I don't want
> blocks to be evaluated on export (too time consuming in many cases).
> So I turn that off, and either evaluate the blocks one at a time (I'm
> aware of the dangers of this, not my point here) or call
> org-babel-execute-buffer. Everytime I do that I get duplicate output
> from inline code. As far as I can see inline code +
> org-babel-execute-buffer is incompatible, which is why I gave up on
> the former.

Gotcha.

The approach that I use requires the operator to keep the object
available and in the correct state,
in the environment, so that it is available during export. This is
probably pretty typical. It requires more
forethought as there are more opportunities for mistakes, versus
generating the inline output at evaluation
time.

Re: Inline code :results replace not working

[Sebastien Vauban]

"Charles C. Berry" wrote:
> 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.

What command are you calling with the above?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Inline code :results replace not working

[Charles Berry]

Sebastien Vauban <sva-news@...> writes:

> 
> "Charles C. Berry" wrote:
> > 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.
> 
> What command are you calling with the above?

Oops! Make that  'C-c C-c y C-x u'

- C-c C-c runs the command org-ctrl-c-ctrl-c.

- y confirms code block evaluation

- <pause here to ponder result>
 
- C-x u runs the command undo.

---

saving myself two keystrokes (C-x u) isn't much, but if I wonder off and do 
something else, then I have to navigate back, find the offending result and 
edit it out.

Best,

Chuck

Re: Inline code :results replace not working

[Michael]

Ista Zahn <istazahn <at> gmail.com> writes:

> 
> On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke <gcr <at> 
wisdomandwonder.com> wrote:
> > On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn <istazahn <at> gmail.com> 
wrote:
> >> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry <ccberry <at> 
ucsd.edu> wrote:
> >>> On Mon, 10 Nov 2014, Andreas Leha wrote:
> >>
> >> [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.
> >>
> >> +1 from me as well. For exactly the reason Andreas illustrated I've
> >> given up on using inline results for the past year or so. Would be
> >> great to see this feature become usable by implementing a system for
> >> replacing them.
> >
> > My approach here has been to use "hidden" source blocks that aren't
> > exported but make it
> > really easy to see the result during development. These settings
> > should work on any configuration,
> > so I didn't include mine here.
> >
> > ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
> > #+BEGIN_SRC R
> > a = 10
> > b = 23
> > c = a + b
> > #+END_SRC
> >
> > #+BEGIN_SRC R :results output silent :exports none
> > c
> > #+END_SRC
> >
> > The user calculated src_R{c}.
> > ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
> >
> > When you use these functions
> > http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-
bindings-and-useful-functions
> > the addition of these "hidden" blocks hav almost zero cost and give me
> > what I want.
> 
> The problem I have is not that I miss being able to see results of the
> inline block in the org-mode buffer. The problem is that I don't want
> blocks to be evaluated on export (too time consuming in many cases).
> So I turn that off, and either evaluate the blocks one at a time (I'm
> aware of the dangers of this, not my point here) or call
> org-babel-execute-buffer. Everytime I do that I get duplicate output
> from inline code. As far as I can see inline code +
> org-babel-execute-buffer is incompatible, which is why I gave up on
> the former.
> 
> Best,
> Ista
> 
> 

+1

First of all nice that something is "happening" on the issue - happy not to 
be the only one missing something. 
+ 1 
on  I also don't bother too much about the eval-on-export functionality as 
long as I can evaluate the buffer and get non repeated inline results.
For now I don't use inline blocks anymore. 

As an intermediate solution I would like to specify document wide options 
for inline code blocks only (:results silent); sorry - cannot find the 
example I saw on the net recently on how to do so. I could not get it 
working. 
I could set results silent argument in every inline src code but don't want 
the inline source code to be too long unnecessarily (affects readability of 
text). 

Re: Inline code :results replace not working

[Grant Rettke]

Maybe use `org-babel-default-inline-header-args'.

On Thu, Nov 13, 2014 at 12:40 PM, Michael <giepen.m@gmail.com> wrote:
>
>
> Ista Zahn <istazahn <at> gmail.com> writes:
>
>>
>> On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke <gcr <at>
> wisdomandwonder.com> wrote:
>> > On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn <istazahn <at> gmail.com>
> wrote:
>> >> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry <ccberry <at>
> ucsd.edu> wrote:
>> >>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>> >>
>> >> [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.
>> >>
>> >> +1 from me as well. For exactly the reason Andreas illustrated I've
>> >> given up on using inline results for the past year or so. Would be
>> >> great to see this feature become usable by implementing a system for
>> >> replacing them.
>> >
>> > My approach here has been to use "hidden" source blocks that aren't
>> > exported but make it
>> > really easy to see the result during development. These settings
>> > should work on any configuration,
>> > so I didn't include mine here.
>> >
>> > ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
>> > #+BEGIN_SRC R
>> > a = 10
>> > b = 23
>> > c = a + b
>> > #+END_SRC
>> >
>> > #+BEGIN_SRC R :results output silent :exports none
>> > c
>> > #+END_SRC
>> >
>> > The user calculated src_R{c}.
>> > ✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
>> >
>> > When you use these functions
>> > http://orgmode.org/manual/Key-bindings-and-useful-functions.html#Key-
> bindings-and-useful-functions
>> > the addition of these "hidden" blocks hav almost zero cost and give me
>> > what I want.
>>
>> The problem I have is not that I miss being able to see results of the
>> inline block in the org-mode buffer. The problem is that I don't want
>> blocks to be evaluated on export (too time consuming in many cases).
>> So I turn that off, and either evaluate the blocks one at a time (I'm
>> aware of the dangers of this, not my point here) or call
>> org-babel-execute-buffer. Everytime I do that I get duplicate output
>> from inline code. As far as I can see inline code +
>> org-babel-execute-buffer is incompatible, which is why I gave up on
>> the former.
>>
>> Best,
>> Ista
>>
>>
>
> +1
>
> First of all nice that something is "happening" on the issue - happy not to
> be the only one missing something.
> + 1
> on  I also don't bother too much about the eval-on-export functionality as
> long as I can evaluate the buffer and get non repeated inline results.
> For now I don't use inline blocks anymore.
>
> As an intermediate solution I would like to specify document wide options
> for inline code blocks only (:results silent); sorry - cannot find the
> example I saw on the net recently on how to do so. I could not get it
> working.
> I could set results silent argument in every inline src code but don't want
> the inline source code to be too long unnecessarily (affects readability of
> text).
>
>
>
>
>
>



-- 
Grant Rettke
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson