Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer

[akater <nuclearspace@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

stardiviner <numbchild@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]