Open dzfranklin opened 4 years ago
This is interesting usage of ob-async. I used this :var
in non-ob-async case. I guess this is not easy to implement.
Whoever works on this, should also consider the :cache
header variable.
I'm having some inconsistency using it and I'm currently trying to stabilize/understand.
Adding to this as its related to the :var
header arg, ob-async
causes variables to be evaluated twice, for example:
#+BEGIN_SRC sh :var INPUT=(read-string "Input: ")
echo $INPUT
#+END_SRC
The input prompt will show twice, and the second input value will be used.
Checklist
troubleshooting.org
bufferExpected Behavior
I can use
#+NAME:
and:var
to pass the result of one block to another block even if the first block is:async
Actual Behavior
Even after the block finishes executing and the result is shown,
#<process emacs>
is stored under the name of the block. For example:Steps to Reproduce
#+NAME: result-value
to store the result of an:async
shell block's execution.:var input_var=result-value
and write code to print the value of that variable in the block.#<process emacs>
or possible#<process emacs <n>>
Troubleshooting Artifacts
troubleshooting.org and a direct link to the raw troubleshooting.org file that shows the results of the blocks.
Note
In the case of python (and possibly other languages) this breaks the code necessary to store the value. As a result, attempting to execute a block with a variable set by an async block will lead to a SyntaxError. I'm including this note because the first keywords I googled for related to this error, before I realized it was a broader issue.