* Inline code :results replace not working
@ 2014-11-07 10:01 mcg
2014-11-08 21:27 ` Nicolas Goaziou
0 siblings, 1 reply; 19+ messages in thread
From: mcg @ 2014-11-07 10:01 UTC (permalink / raw)
To: emacs-orgmode
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).
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-07 10:01 Inline code :results replace not working mcg
@ 2014-11-08 21:27 ` Nicolas Goaziou
2014-11-10 9:21 ` Sebastien Vauban
0 siblings, 1 reply; 19+ messages in thread
From: Nicolas Goaziou @ 2014-11-08 21:27 UTC (permalink / raw)
To: mcg; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-08 21:27 ` Nicolas Goaziou
@ 2014-11-10 9:21 ` Sebastien Vauban
2014-11-10 9:40 ` Andreas Leha
0 siblings, 1 reply; 19+ messages in thread
From: Sebastien Vauban @ 2014-11-10 9:21 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 9:21 ` Sebastien Vauban
@ 2014-11-10 9:40 ` Andreas Leha
2014-11-10 10:27 ` Sebastien Vauban
0 siblings, 1 reply; 19+ messages in thread
From: Andreas Leha @ 2014-11-10 9:40 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 9:40 ` Andreas Leha
@ 2014-11-10 10:27 ` Sebastien Vauban
2014-11-10 10:56 ` Andreas Leha
0 siblings, 1 reply; 19+ messages in thread
From: Sebastien Vauban @ 2014-11-10 10:27 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 10:27 ` Sebastien Vauban
@ 2014-11-10 10:56 ` Andreas Leha
2014-11-10 11:16 ` Sebastien Vauban
0 siblings, 1 reply; 19+ messages in thread
From: Andreas Leha @ 2014-11-10 10:56 UTC (permalink / raw)
To: emacs-orgmode
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---
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 10:56 ` Andreas Leha
@ 2014-11-10 11:16 ` Sebastien Vauban
2014-11-10 11:42 ` Andreas Leha
0 siblings, 1 reply; 19+ messages in thread
From: Sebastien Vauban @ 2014-11-10 11:16 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 11:16 ` Sebastien Vauban
@ 2014-11-10 11:42 ` Andreas Leha
2014-11-10 16:23 ` Charles C. Berry
0 siblings, 1 reply; 19+ messages in thread
From: Andreas Leha @ 2014-11-10 11:42 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 11:42 ` Andreas Leha
@ 2014-11-10 16:23 ` Charles C. Berry
2014-11-10 17:03 ` Ista Zahn
2014-11-12 9:03 ` Sebastien Vauban
0 siblings, 2 replies; 19+ messages in thread
From: Charles C. Berry @ 2014-11-10 16:23 UTC (permalink / raw)
To: Andreas Leha; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 16:23 ` Charles C. Berry
@ 2014-11-10 17:03 ` Ista Zahn
2014-11-10 20:04 ` Grant Rettke
2014-11-12 9:03 ` Sebastien Vauban
1 sibling, 1 reply; 19+ messages in thread
From: Ista Zahn @ 2014-11-10 17:03 UTC (permalink / raw)
To: Charles C. Berry; +Cc: Andreas Leha, emacs-orgmode Mailinglist
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 17:03 ` Ista Zahn
@ 2014-11-10 20:04 ` Grant Rettke
2014-11-10 20:45 ` Thomas S. Dye
2014-11-11 1:53 ` Ista Zahn
0 siblings, 2 replies; 19+ messages in thread
From: Grant Rettke @ 2014-11-10 20:04 UTC (permalink / raw)
To: Ista Zahn; +Cc: Andreas Leha, emacs-orgmode Mailinglist, Charles C. Berry
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 20:04 ` Grant Rettke
@ 2014-11-10 20:45 ` Thomas S. Dye
2014-11-10 21:26 ` Grant Rettke
2014-11-11 1:53 ` Ista Zahn
1 sibling, 1 reply; 19+ messages in thread
From: Thomas S. Dye @ 2014-11-10 20:45 UTC (permalink / raw)
To: Grant Rettke
Cc: Andreas Leha, emacs-orgmode Mailinglist, Ista Zahn,
Charles C. Berry
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 20:45 ` Thomas S. Dye
@ 2014-11-10 21:26 ` Grant Rettke
0 siblings, 0 replies; 19+ messages in thread
From: Grant Rettke @ 2014-11-10 21:26 UTC (permalink / raw)
To: Thomas S. Dye
Cc: Andreas Leha, emacs-orgmode Mailinglist, Ista Zahn,
Charles C. Berry
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 20:04 ` Grant Rettke
2014-11-10 20:45 ` Thomas S. Dye
@ 2014-11-11 1:53 ` Ista Zahn
2014-11-11 14:37 ` Grant Rettke
2014-11-13 18:40 ` Michael
1 sibling, 2 replies; 19+ messages in thread
From: Ista Zahn @ 2014-11-11 1:53 UTC (permalink / raw)
To: Grant Rettke; +Cc: Andreas Leha, emacs-orgmode Mailinglist, Charles C. Berry
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-11 1:53 ` Ista Zahn
@ 2014-11-11 14:37 ` Grant Rettke
2014-11-13 18:40 ` Michael
1 sibling, 0 replies; 19+ messages in thread
From: Grant Rettke @ 2014-11-11 14:37 UTC (permalink / raw)
To: Ista Zahn; +Cc: Andreas Leha, emacs-orgmode Mailinglist, Charles C. Berry
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-10 16:23 ` Charles C. Berry
2014-11-10 17:03 ` Ista Zahn
@ 2014-11-12 9:03 ` Sebastien Vauban
2014-11-12 17:26 ` Charles Berry
1 sibling, 1 reply; 19+ messages in thread
From: Sebastien Vauban @ 2014-11-12 9:03 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
"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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-12 9:03 ` Sebastien Vauban
@ 2014-11-12 17:26 ` Charles Berry
0 siblings, 0 replies; 19+ messages in thread
From: Charles Berry @ 2014-11-12 17:26 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-11 1:53 ` Ista Zahn
2014-11-11 14:37 ` Grant Rettke
@ 2014-11-13 18:40 ` Michael
2014-11-14 15:11 ` Grant Rettke
1 sibling, 1 reply; 19+ messages in thread
From: Michael @ 2014-11-13 18:40 UTC (permalink / raw)
To: emacs-orgmode
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).
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Inline code :results replace not working
2014-11-13 18:40 ` Michael
@ 2014-11-14 15:11 ` Grant Rettke
0 siblings, 0 replies; 19+ messages in thread
From: Grant Rettke @ 2014-11-14 15:11 UTC (permalink / raw)
To: Michael; +Cc: emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-11-14 15:11 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-07 10:01 Inline code :results replace not working mcg
2014-11-08 21:27 ` Nicolas Goaziou
2014-11-10 9:21 ` Sebastien Vauban
2014-11-10 9:40 ` Andreas Leha
2014-11-10 10:27 ` Sebastien Vauban
2014-11-10 10:56 ` Andreas Leha
2014-11-10 11:16 ` Sebastien Vauban
2014-11-10 11:42 ` Andreas Leha
2014-11-10 16:23 ` Charles C. Berry
2014-11-10 17:03 ` Ista Zahn
2014-11-10 20:04 ` Grant Rettke
2014-11-10 20:45 ` Thomas S. Dye
2014-11-10 21:26 ` Grant Rettke
2014-11-11 1:53 ` Ista Zahn
2014-11-11 14:37 ` Grant Rettke
2014-11-13 18:40 ` Michael
2014-11-14 15:11 ` Grant Rettke
2014-11-12 9:03 ` Sebastien Vauban
2014-11-12 17:26 ` Charles Berry
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).