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