From: "Berry, Charles" via "General discussions about Org-mode." <firstname.lastname@example.org>
To: Greg Minshall <email@example.com>
Cc: orgmode <firstname.lastname@example.org>
Subject: Re: using previous =#+results= when =:eval never=
Date: Sun, 4 Jul 2021 17:20:10 +0000 [thread overview]
Message-ID: <4A57F8AE-A7AC-42D2-806B-050854A87377@health.ucsd.edu> (raw)
> On Jul 3, 2021, at 10:19 PM, Greg Minshall <email@example.com> wrote:
> thanks. (i'm not surprised at an e-lisp suggestion from you! :)
> i worry about accidental modification of the base case results during
> the chaos of development. it occurs to me (reading through
> (org-babel-ref-resolve)) to keep my base case source blocks marked with
> [:results silent], which should prevent accidental modification. (*)
This seems unnecessary.
Be warned that the behavior of `org-babel-update-intermediate` is not intuitive - at least to me. My reading of the doctstring is that the result of a named src block can be changed when it is non-nil. AFAICS, this never happens. Instead, the return value from `org-babel-ref-resolve` is copied from the named result.
For your ECM, after deleting the `:eval never`, if I append `+ 1` to the `mtcars[1:3,]` and execute then next src block, I get
: Comparison failed for block testcountsdecompose
and the original in-buffer value did not change.
I can remove the `+ 1` and rerun the above block and the result is `t`
> then, i would change [:results silent] to, e.g., [:results silentx], in
> the base case source blocks whenever i wanted to re-create those
> for, e.g., inspecting the results when things differ, it would be nice
> to stay in the language of the rest of the code. but i suspect i'll be
> able to do some e-lisp magic on the RHS of a :var, e.g., crudely
> : #+begin_src R :var basecaseresults=(org-babel-read-named-result "testcountsdecompose")
> i'll play around with it. (i suspect i'll be motivated to use an e-lisp
> macro, to eliminate the quotes, for example.)
> again, thanks.
> cheers, Greg
> (*) this relies on current org-mode behavior, where
> (org-babel-read-result) will return results from a result block from a
> source block marked [:results silent]. i have no idea how likely this
> behavior is to change in the long run.
prev parent reply other threads:[~2021-07-04 17:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 16:35 using previous =#+results= when =:eval never= Greg Minshall
2021-07-03 19:08 ` Berry, Charles via General discussions about Org-mode.
2021-07-04 5:19 ` Greg Minshall
2021-07-04 17:20 ` Berry, Charles via General discussions about Org-mode. [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
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).