[-- 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 --]
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
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
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.