Ihor Radchenko <[email protected]> writes:

Sorry, I attached the wrong patch in my previous email, and did not put
[email protected] as CC, so I'll just send the whole email again
with both things fixed.

>> I took a look at the code and it's more convoluted than I expected. But
>> in the end I found out the reason why results are not printed for blocks
>> evaluated indirectly, it's this line:
>> https://github.com/emacsmirror/org/blob/8da0562b4d26cdac86fa4bbf830c531b2df41cd8/lisp/ob-ref.el#L164.
>> That parameter is later used in `org-babel-execute-src-block` to
>> determine whether the results should be printed or not. I decided to do
>> the change in that function, to localize the change as much as possible
>> and avoid any potential side effects of changing that parameter too
>> early. What I do is just ignoring that parameter is a block has the
>> header argument :cache yes. That comes at the price of not including the
>> variable I suggested, and always print results for blocks that have
>> :cache yes, but I think that always makes sense from a DWIM perspective,
>> and I can't think of any downside of it. I attached the patch, let me
>> know what you think.
>
> I do not think that always printing is a good idea.
> Imagine code block being called as a dependency from another file.
> This will be very surprising that evaluating a code in one file will
> lead to modifications in another file.

Ok, but I still think that doing the change too early is risky without
understanding the code well, so I would discard my initial variable
proposal. Instead, what about a variable that already applies only to
cached blocks? If the value is nil (default) everything will behave as
usual. If the value is non-nil, org-babel will always print the results
of a block with :cache yes regardless or how it's executed. This will
cover the case where it's executed as a dependency of another block,
which is what we care about. I don't know what other cases could there
be, but I guess the DWIM argument from my previous email will apply for
them too, and as long as it's behind a custom variable it would not
really matter if we find some potential caveat later, right?

I attach the patch for this new proposal.

>From 47065eb84c3ba2d9bdeeb6a2889a861f2f3b2eb1 Mon Sep 17 00:00:00 2001
From: Ignacio Casso <[email protected]>
Date: Sun, 8 Feb 2026 22:40:08 +0100
Subject: [PATCH] add option to print results of cached blocks evaluated
 indirectly

* lisp/ob-core.el (org-babel-cache-always-print-results): new custom
variable to always print results of a source block with :cache yes
even if :results is "none".

* lisp/ob-core.el (org-babel-execute-src-block): Use the new
org-babel-cache-always-print-results variable when deciding whether or
not to print the results of a source block being evaluated.

This allows results of cached blocks to be actually cached also when
the block is evaluated indirectly as a dependency of another block (as
those kind of references are always evaluated internally with
`:results none`)

See https://list.orgmode.org/orgmode/[email protected]
---
 lisp/ob-core.el | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index a8ca1ccd0..8d2c8dfc3 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -184,6 +184,19 @@ This string must include a \"%s\" which will be replaced by the results."
   :package-version '(Org . "9.1")
   :safe #'booleanp)
 
+(defcustom org-babel-cache-always-print-results nil
+  "Whether to force caching results of blocks evaluated indirectly.
+
+Caching a source block result needs the result being printed in the Org
+buffer.  But results of a source block are only printed by default if
+the block is evaluated directly, and not when it's evaluated as a
+reference of another block (e.g., with the `:var` header argument).
+When this variable is non-nil, results of blocks with with the `:cache`
+header argument set to `yes` will always be printed, regardless of how
+they are executed."
+  :group 'org-babel
+  :type 'boolean)
+
 (defun org-babel-noweb-wrap (&optional regexp)
   "Return regexp matching a Noweb reference.
 
@@ -953,7 +966,8 @@ 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 org-babel-cache-always-print-results)))
 	        (org-babel-insert-result
 	         result result-params info
                  ;; append/prepend cannot handle hash as we accumulate
-- 
2.43.0

Reply via email to