stardiviner <numbch...@gmail.com> writes: > I have some considering. Multi-block return might will cause other options > hard > to handle the result block. For example ~:cache~, ~:results replace~, and use > result > as source block input data. WDYT?
Probably. I'm not a user of either :cache or :results replace but multi-block return, if implemented, will likely require some non-trivial work to be incorporated smoothly. Returning just a single block by default will keep it safe for general users. But I do find it suspicious when some output is produced and yet not submitted into the buffer where evaluation results are supposed to go. And Org seems to be able to handle this very neatly. >> while simply hiding empty blocks, if any, for convenience. >> >> Note that currently, when “output” is specified, “values” is simply >> lost, and vice versa. Implementing multi-block results would fix this >> shortcoming too. >> >> However, I did not try to implement this yet. >> >> * Conclusion >> How do we sync with SLIME if you're OK with this? How do we treat the >> case of vcs Org + stable SLIME? > > Might on Org Mode side, add an function to detect SLIME output, or SLIME > version > to make sure ~:results trace~ is usable. If not, warn user to update SLIME. > WDYT? For now, I just delayed activation of the feature in Org until a certain future SLIME version. In my SLIME patch, it's handled more subtly, using supplied-p optional argument, a check that can be dropped once Org 9.3 becomes unsupported.
signature.asc
Description: PGP signature
