>> I will try to write a patch that addresses all the issues I mentioned >> and share it here. > > Looking forward.
Here it is, let me know what you think. I tested it manually, if there are automated tests somewhere that I can update please let me know.
>From fb47186a7b3d639bb8edb807465869d4f947d71e Mon Sep 17 00:00:00 2001 From: Ignacio Casso <[email protected]> Date: Mon, 9 Mar 2026 20:02:39 +0100 Subject: [PATCH] fix and extend org-babel-update-intermediate variable * lisp/ob-ref.el (org-babel-update-intermediate): make variable custom and add `cached` as new possible value to only update intermediate blocks when they have the :cache yes header argument * lisp/ob-ref.el (org-babel-ref-resolve): Fix usage of `org-babel-update-intermediate` so that it only affects the :results "none" header argument (before it was also affecting other header arguments like parameter values, which resulted in a bug) * lisp/ob-core.el (org-babel-execute-src-block): Use the cache header argument and `org-babel-update-intermediate` to decide whether :results "none" header argument should be ignored. This allows results of cached blocks to be actually cached also when the block is evaluated indirectly as a dependency of another block. See https://list.orgmode.org/orgmode/[email protected] --- lisp/ob-core.el | 4 +++- lisp/ob-ref.el | 19 ++++++++++++++----- 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index a8ca1ccd0..0ec4e8381 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -953,7 +953,9 @@ guess will be made." (setq result (org-babel-ref-resolve post)) (when file (setq result-params (remove "file" result-params)))))) - (unless (member "none" result-params) + (unless (and (member "none" result-params) + (not (and cache + (eq 'cached org-babel-update-intermediate)))) (org-babel-insert-result result result-params info ;; append/prepend cannot handle hash as we accumulate diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el index 14c5ce4a9..8b043803a 100644 --- a/lisp/ob-ref.el +++ b/lisp/ob-ref.el @@ -70,8 +70,16 @@ (declare-function org-narrow-to-subtree "org" (&optional element)) (declare-function org-fold-show-context "org-fold" (&optional key)) -(defvar org-babel-update-intermediate nil - "Update the in-buffer results of code blocks executed to resolve references.") +(defcustom org-babel-update-intermediate nil + "Update the in-buffer results of code blocks executed to resolve references. + +If value is nil they will never be updated. If value is non-nil they +will always be updated. A value of ‘cached’ means to only update them if +the block has the cache header argument set to yes. This is needed +for the cache feature to work properly, as it relies on source block +results being printed in the Org buffer." + :group 'org-babel + :type 'boolean) (defun org-babel-ref-parse (assignment) "Parse a variable ASSIGNMENT in a header argument. @@ -183,9 +191,10 @@ Emacs Lisp representation of the value of the variable." (throw :found (org-babel-execute-src-block nil nil - (and - (not org-babel-update-intermediate) - params)))) + (if (and org-babel-update-intermediate + (not (eq 'cached org-babel-update-intermediate))) + params + args)))) ((and (let v (org-babel-read-element e)) (guard v)) (throw :found v)) -- 2.43.0
> And, for a good measure, we may suppress the effects in read-only > buffers. If you mean that read-only org-mode buffers should not be updated as a result of this, I don't see why would someone have a read-only mode org buffer, but I checked and they are not updated. In that case if `org-babel-update-intermediate` is non-nil, evaluation fails silently instead. Is that a problem? I think it's a very unlikely scenario, so I would leave it like that for now.
