From: Bastien <bzg@gnu.org>
To: Nick Dokos <ndokos@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug or not a bug? dot expansion in ob-shell
Date: Fri, 21 Feb 2020 09:04:19 +0100 [thread overview]
Message-ID: <878skwbc3g.fsf@bzg.fr> (raw)
In-Reply-To: 877e0h571l.fsf@alphaville.usersys.redhat.com
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.
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.
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".
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.
--
Bastien
next prev parent reply other threads:[~2020-02-21 8:04 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 9:02 Bug or not a bug? dot expansion in ob-shell Vladimir Nikishkin
2020-02-19 9:27 ` Fraga, Eric
2020-02-19 9:41 ` Bastien
2020-02-19 9:43 ` Bastien
2020-02-19 9:57 ` Bastien
2020-02-19 11:03 ` Fraga, Eric
2020-02-19 11:38 ` Bastien
2020-02-19 11:56 ` Fraga, Eric
2020-02-19 12:06 ` Vladimir Nikishkin
2020-02-19 12:10 ` Bastien
2020-02-19 12:27 ` Bastien
2020-02-27 14:25 ` Kaushal Modi
2020-02-19 12:47 ` Tim Cross
2020-02-19 13:00 ` Bastien
2020-02-19 13:15 ` Tim Cross
2020-02-19 13:23 ` Bastien
2020-02-19 13:31 ` Fraga, Eric
2020-02-19 13:43 ` Bastien
2020-02-19 14:05 ` Fraga, Eric
2020-02-19 16:00 ` Bastien
2020-02-19 19:43 ` Diego Zamboni
2020-02-19 20:41 ` Samuel Wales
2020-02-19 21:32 ` Bastien
2020-02-20 20:37 ` Nick Dokos
2020-02-20 21:01 ` Tim Cross
2020-02-21 6:55 ` Derek Feichtinger
2020-02-21 8:04 ` Bastien [this message]
2020-02-21 21:04 ` Nick Dokos
2020-02-22 6:23 ` Jack Kamm
2020-02-22 13:37 ` Bastien
2020-02-23 9:50 ` Stefan Nobis
2020-02-23 13:13 ` Bastien
2020-02-23 16:13 ` Jack Kamm
2020-02-23 20:44 ` Bastien
2020-02-29 15:35 ` Jack Kamm
2020-02-29 15:39 ` Jack Kamm
2020-03-01 2:08 ` Tom Gillespie
2020-03-01 3:50 ` Tim Cross
2020-03-04 18:41 ` Nick Dokos
2020-09-06 17:33 ` Bastien
2020-03-01 4:09 ` Jack Kamm
2020-03-01 5:07 ` Tom Gillespie
2020-03-01 5:58 ` Jack Kamm
2020-03-01 15:46 ` Jack Kamm
2020-09-06 17:36 ` Bastien
2020-09-07 17:39 ` Bastien
2020-02-23 15:27 ` Fraga, Eric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878skwbc3g.fsf@bzg.fr \
--to=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=ndokos@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).