[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: using previous =#+results= when =:eval never=
From: |
Berry, Charles |
Subject: |
Re: using previous =#+results= when =:eval never= |
Date: |
Sun, 4 Jul 2021 17:20:10 +0000 |
> On Jul 3, 2021, at 10:19 PM, Greg Minshall <minshall@umich.edu> wrote:
>
> Chuck,
>
> 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
#+begin_src emacs-lisp
(compare-old-to-new "testcountsdecompose")
#+end_src
#+RESULTS:
: 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`
HTH,
Chuck
> then, i would change [:results silent] to, e.g., [:results silentx], in
> the base case source blocks whenever i wanted to re-create those
> results.
>
> 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.