emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: akater <nuclearspace@gmail.com>
To: numbchild@gmail.com
Cc: emacs-orgmode@gnu.org
Subject: Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer
Date: Mon, 06 Jul 2020 22:17:27 +0000	[thread overview]
Message-ID: <87tuykuw3s.fsf@gmail.com> (raw)
In-Reply-To: <87zh9wg8yt.fsf@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 --]

      reply	other threads:[~2020-07-06 22:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08 23:20 (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer akater
2020-05-24 13:35 ` Bastien
2020-05-25  0:21 ` stardiviner
2020-07-06 22:17   ` akater [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuykuw3s.fsf@gmail.com \
    --to=nuclearspace@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=numbchild@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).