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 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 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://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
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ emacs-orgmode@gnu.org public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git