From: akater <email@example.com> To: firstname.lastname@example.org Cc: email@example.com 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: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 1557 bytes --] stardiviner <firstname.lastname@example.org> 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 --]
prev parent 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 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).