From: Bastien <bzg@gnu.org>
To: ian martins <ianxm@jhu.edu>
Cc: Org-Mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: default :results
Date: Wed, 11 Nov 2020 09:03:56 +0100 [thread overview]
Message-ID: <87pn4kcob7.fsf@gnu.org> (raw)
In-Reply-To: <CAC=rjb68oTR3p+f8jzwSJ2X_pBh=RMbGcV7HkvBHkGAru5sfxg@mail.gmail.com> (ian martins's message of "Mon, 26 Oct 2020 22:01:21 -0400")
Hi Ian,
ian martins <ianxm@jhu.edu> writes:
> The doc says functional mode (=:results value=) is the default for
> most Babel libraries [1]. I haven't looked at many, but it is the
> default for ob-python and ob-shell. Scripting mode (=:results output
> =) is the default for ob-C, and the old ob-java (neither of these
> provided a functional mode).
>
> When I added functional mode to ob-java, I made it the default since
> that seemed correct. But that change breaks anyone that relied on
> the old default (the workaround is to add a =:results output=
> header). I will change the default in the short term to unbreak the
> experience, but what, if anything, should be done long term?
The default for ob-shell execution was to use the output, not the
value. Then we had a long discussion, leading to this:
- The default (no :result) is to display the functional value
- For some languages, it may break expectations, so in this case we
allow a variable that let the default (no :result) use the output
instead of the functional value.
This is what is being done for ob-shell.el where we have
`org-babel-shell-results-defaults-to-output' set to `t'.
See https://orgmode.org/list/877dt5trjr.fsf@bzg.fr/ for the conclusion
of the discussion.
Also see `org-babel-shell-results-defaults-to-output' docstring:
Let shell execution defaults to ":results output".
When set to t, use ":results output" when no :results setting
is set. This is especially useful for inline source blocks.
When set to nil, stick to the convention of using :results value
as the default setting when no :results is set, the "value" of
a shell execution being its exit code.
> And is this inconsistent behavior across languages something that
> should be fixed? or is it intentional or at least not worth doing
> anything about?
What was suggested is to have a page on Worg listing the behavior of
various packages regarding block execution.
I started a section on https://orgmode.org/worg/library-of-babel.html
with a table -- feel free to add more to this table.
Thanks,
--
Bastien
next prev parent reply other threads:[~2020-11-11 8:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 2:01 default :results ian martins
2020-11-11 8:03 ` Bastien [this message]
2020-11-14 10:27 ` ian martins
2020-11-17 12:40 ` ian martins
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 \
--in-reply-to=87pn4kcob7.fsf@gnu.org \
--to=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=ianxm@jhu.edu \
/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
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
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).