From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Bug or not a bug? dot expansion in ob-shell Date: Fri, 21 Feb 2020 16:04:57 -0500 Message-ID: <8736b36492.fsf@alphaville.usersys.redhat.com> References: <87eeur3p1p.fsf@ucl.ac.uk> <87a75eap8k.fsf@gnu.org> <87y2sy3kkl.fsf@ucl.ac.uk> <87r1yq4xiz.fsf@gnu.org> <875zg2kcy0.fsf@ucl.ac.uk> <87h7zmiw0v.fsf@gmail.com> <871rqqag19.fsf@bzg.fr> <87wo8iitzz.fsf@ucl.ac.uk> <87ftf63d79.fsf@gnu.org> <87pnear7tl.fsf@ucl.ac.uk> <87v9o236v1.fsf@gnu.org> <8736b66z6t.fsf@gnu.org> <877e0h571l.fsf@alphaville.usersys.redhat.com> <878skwbc3g.fsf@bzg.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58084) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5FU9-0000yU-6z for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 16:05:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5FU7-00029V-Km for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 16:05:21 -0500 Received: from ciao.gmane.io ([159.69.161.202]:40268) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j5FU7-000295-ET for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 16:05:19 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1j5FU4-000Svz-KP for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 22:05:16 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Hi Bastien, I think all this is reasonable. I have some inline comments and a suggestion at the end. Bastien writes: > Hi Nick, > > I didn't conduct the survey in 2013, you can find the results here: > https://orgmode.org/worg/org-configs/org-customization-survey.html > > I understand why you (and Tim and Derek) think an option is too much. > > But let's separate two problems: one is that Org have many options, > some perhaps unneeded (or only here because of bad design decisions we > made in the past), causing a technical debt, another one being "How to > handle shell's notion of "return value" in ob-shell.el? > > The first problem is real: patches are always welcome in this area but > this is the kind of problem that requires a big picture and a strong > push, incremental fixes are difficult here. > But if we can avoid making the problem worse, we should do that. Messes like this are created, not born. > The second problem is real too, and while being cautious about not > making the first problem worse, the solution should be independant. > > That said, we have three solutions: > > 1. Stick to a strict reading of Org and bash manuals: the absence of a > :results header means "return the value, i.e. the exit status". > > 2. Deviate from this strict reading, introduce an exception for *all* > shell blocks: no :results header means "return output" and you need > to use :results value to get the exit status (your proposal). > > 3. Deviate from this strict reading and introduce an option that says: > "Don't deviate from the Org's and bash manuals for all src blocks". > > Obviously, nobody wants the first solution. I'm not convinced of that: personally, I would be happy with the first solution and maybe others would be too. I would add a :results output header explicitly where needed and be on my way. Of course, it would break workflows where the output is expected and that might be a problem for some. I agree that the option takes care of this problem. > > Part of me agrees with your second solution: after all, we had to wait > until Vladimir's "echo ." trick to find out there was a problem. > > Part of me think that (1) deviation from the normal behavior should be > carefully advertized and (2) by design, the normal behavior should not > require tweaking options manually for each block. An option fulfills > both these needs: allowing to get the normal behavior by default and > advertizing the "deviation". I somewhat object to the use of the word "normal" in this paragraph: I think you mean "current" in the first and last instances. I disagree with (2): see my suggestion below. And IMO, the option makes it so that most users don't have to change anything. That is a good think in general (it is the reason that the option exists), but it hides the deviation rather than advertising it, because unless somebody follows this discussion, they don't know that there *is* a deviation. > > Right now I'm not convinced we should get rid of this option. > > But I'm convinced we should take the decision we no consideration of > the first (biggest) problem of Org having *perhaps* too many options. > > Case still open. My longer term suggestion (which, I realize, does not help to close *this* case any time soon): I think that the global default setting `:results value' is wrong: it works fine for "functional" code blocks (ones where a function is defined and then called with some parameters to make sure it produces the correct value - the function can be written in any language: I don't mean to restrict it to functional languages); it does not work well for the "scripting" cases (ones where the code block is a sequence of calls, each of which might or might not produce output - but it's the whole output that matters, not the individual calls). In the longer run, I think the possibility of *forcing* users to choose which one they want, should be entertained. Thanks and regards! -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler