[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (almost a patch) Receiving more output from a Common Lisp evaluation
Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer
Mon, 06 Jul 2020 22:17:27 +0000
stardiviner <email@example.com> writes:
> I have some considering. Multi-block return might will cause other options
> to handle the result block. For example ~:cache~, ~:results replace~, and use
> 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
> to make sure ~:results trace~ is usable. If not, warn user to update SLIME.
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.
Description: PGP signature
|[Prev in Thread]
||[Next in Thread]|
- Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer,