default :results

default :results

[ian martins]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

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?

And is this inconsistent behavior across languages something that should be
fixed? or is it intentional or at least not worth doing anything about?

<https://orgmode.org/manual/Results-of-Evaluation.html#FOOT144>[1]
https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation
<https://orgmode.org/manual/Results-of-Evaluation.html#FOOT144>

[-- Attachment #2: Type: text/html, Size: 1230 bytes --]

Re: default :results

[Bastien]

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

Re: default :results

[ian martins]

On Wed, Nov 11, 2020 at 3:04 AM Bastien <bzg@gnu.org> 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://orgmode.org/list/877dt5trjr.fsf@bzg.fr/ 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 [1] page? If so, I can move it when I update.

Also, there are two library of babel pages ([2], [3]) that appear to
serve the same purpose. I was thinking of merging them. Is that fine?

[1] https://orgmode.org/worg/org-contrib/babel/languages/index.html
[2] https://orgmode.org/worg/org-contrib/babel/library-of-babel.html
[3] https://orgmode.org/worg/library-of-babel.html

Re: default :results

[ian martins]

On Sat, Nov 14, 2020 at 5:27 AM ian martins <ianxm@jhu.edu> wrote:
>
> On Wed, Nov 11, 2020 at 3:04 AM Bastien <bzg@gnu.org> 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://orgmode.org/list/877dt5trjr.fsf@bzg.fr/ 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?

shortly after sending this I reverted another change I'd made to
default behavior by setting it in
`org-babel-default-header-args:java'. Another benefit of doing it here
is that this variable becomes a list of ways in which a language
doesn't follow normal babel default conventions, making it easy to
find.