From: ian martins <email@example.com> To: Bastien <firstname.lastname@example.org> Cc: Org-Mode mailing list <email@example.com> Subject: Re: default :results Date: Sat, 14 Nov 2020 05:27:57 -0500 [thread overview] Message-ID: <CAC=rjb4TvCV3G=Zg4uTXtPpDjJopJ8m1S-3ZRHAivr9Xzr6hWA@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Wed, Nov 11, 2020 at 3:04 AM Bastien <email@example.com> wrote: > > 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://firstname.lastname@example.org/ for the conclusion > of the discussion. I agree with your reasoning. I already reverted the behavior, but Instead of adding a `org-babel-java-results-defaults-to-output variable' I set the default in `org-babel-default-header-args:java'. It was better because it didn't add a new variable, but worse because it isn't customizable. Should I change it? > 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, I will add to it. Would it be better for the table to be on the languages  page? If so, I can move it when I update. Also, there are two library of babel pages (, ) that appear to serve the same purpose. I was thinking of merging them. Is that fine?  https://orgmode.org/worg/org-contrib/babel/languages/index.html  https://orgmode.org/worg/org-contrib/babel/library-of-babel.html  https://orgmode.org/worg/library-of-babel.html
next prev parent reply other threads:[~2020-11-14 10:28 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 2020-11-14 10:27 ` ian martins [this message] 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='CAC=rjb4TvCV3G=Zg4uTXtPpDjJopJ8m1S-3ZRHAivr9Xzr6hWA@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: default :results' \ /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).