emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug or not a bug? dot expansion in ob-shell


From: Bastien
Subject: Re: Bug or not a bug? dot expansion in ob-shell
Date: Mon, 07 Sep 2020 19:39:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Bastien <bzg@gnu.org> writes:

> At first, I thought "If ':results value' is always the same as the
> default, why have ':results value' at all?" and thought it'd be an
> argument for having different defaults for different languages but
> I see how I was wrong: expectations for defaults should be stable,
> while the notion of "value" and "output" can vary from one language
> to the other.

Sooooo!  I've thought about this again and here we are.

The default is to not break the previous behavior, which is to use the
output of shell scripts, not their exit codes.  This is because (1) I
don't like incompatible changes (2) the output is what most users want
anyway and (3) a default of :results value would break the default
behavior for src_sh{echo "this"} (and asking users to update to
src_sh[:results output]{echo "this"} is a bad option.)

If you want to stick to the :results value as the default, you can set
org-babel-shell-results-defaults-to-output to nil.  Yes, a new option,
but at least now we have a clear convention: the default for all Babel
libraries should be to stick to ":results value" when no :results
header is set (as the manual suggests) ; when deriving from this, a
library should add an option to do so.  

I strongly believe that having an option is better than implicitely
changing the default expectation when no :results header is set, it 
is more predictable for users.

I hope this all makes sense.

-- 
 Bastien



reply via email to

[Prev in Thread] Current Thread [Next in Thread]