Ignacio Casso <[email protected]> writes: >>> Does it make sense to add a configuration variable for printing the >>> results of blocks evaluated indirectly to fix this? It could have the >>> following values: >>> - nil (default): Don't print the results of blocks evaluated >>> indirectly, as it's done now >>> - 'cache: do it only if the block has a cache header argument >>> - t: Do it always >>> >>> WDYT? I guess it should be relatively easy to do it with the pieces >>> that already exist, so if you agree it's a good idea I can try >> >> Sounds reasonable. >> +1 > > 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. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
