From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id PqphLwybq19nNwAA0tVLHw (envelope-from ) for ; Wed, 11 Nov 2020 08:04:28 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id qMqoKgybq1/tWgAAbx9fmQ (envelope-from ) for ; Wed, 11 Nov 2020 08:04:28 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3A293940366 for ; Wed, 11 Nov 2020 08:04:28 +0000 (UTC) Received: from localhost ([::1]:54974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcl7B-0004xt-LX for larch@yhetil.org; Wed, 11 Nov 2020 03:04:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcl6n-0004xQ-Qe for emacs-orgmode@gnu.org; Wed, 11 Nov 2020 03:04:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52263) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcl6l-0004C1-Kc; Wed, 11 Nov 2020 03:03:59 -0500 Received: from lns-bzn-32-82-254-31-120.adsl.proxad.net ([82.254.31.120]:54168 helo=guerry) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1kcl6k-0004rN-A7; Wed, 11 Nov 2020 03:03:58 -0500 Received: by guerry (Postfix, from userid 1000) id 3C9061A60E8F; Wed, 11 Nov 2020 09:03:56 +0100 (CET) From: Bastien To: ian martins Subject: Re: default :results Organization: GNU References: Date: Wed, 11 Nov 2020 09:03:56 +0100 In-Reply-To: (ian martins's message of "Mon, 26 Oct 2020 22:01:21 -0400") Message-ID: <87pn4kcob7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Org-Mode mailing list Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.51 X-TUID: Pv7pk/4WtrtG Hi Ian, ian martins writes: > The doc says functional mode (=3D:results value=3D) is the default for > most Babel libraries [1].=C2=A0 I haven't looked at many, but it is the > default for ob-python and ob-shell. Scripting mode (=3D:results output > =3D) 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.=C2=A0 But that change breaks anyone that relied on > the old default (the workaround is to add a =3D:results output=3D > header).=C2=A0 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=20 `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". =20=20 When set to t, use ":results output" when no :results setting is set. This is especially useful for inline source blocks. =20=20 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. =20=20 > 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, --=20 Bastien