emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Tom Gillespie <tgbugs@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: bug: Error handling in source blocks.
Date: Tue, 10 Aug 2021 16:14:53 -0700	[thread overview]
Message-ID: <CA+G3_PPC9VoH8Hm4jFbQWPJojXeCdS5fD5Pm00AY=8RZehXLdg@mail.gmail.com> (raw)
In-Reply-To: <87czqlf0gg.fsf@gmail.com>

I will also chime in here to say that managing output streams and
errors for babel is a major new feature that I am interested in. The
issue, as Tim points out, is that there is a lot of complexity lurking
here due to the fact that certain languages have fundamentally
different capabilities and ways of handling or not handling errors,
and of running code (on arbitrary hosts) in the first place.

What works for one will almost certainly not work for another. Take
for example ob-lisp where there is already built in error handling in
emacs itself. Compare that with python where someone would likely need
to implement a special PYTHONBREAKPOINT entrypoint or something like
that, if it were possible at all.

I have had a draft of a document on what I called "babel
regularization" for well over a year now, but it is not in a state
that would be productive to share due to the sheer number of ob-langs
and systems affected and the need to be able to clearly catalog and
articulate the diversity of existing behaviors.

If you dig through old conversations on this list you will find a
discussion of the default behavior for ob-shell :returns values vs
output as the default, we were barely able to agree on which
principles should be followed to make the decision. In that case we
were lucky that there was already a way for users to set their desired
behavior in their init file or in a setup file or in the file itself.
How to handle errors will be much more complex, in part because it
will touch on what ob-lang implementations are able to overwrite
and/or must provide in order to actually function. At the moment there
are practically no constraints.

Lots of work to do here, so grateful for a report on the variability
in the behavior of the existing system.

Best!
Tom

next prev parent reply	other threads:[~2021-08-10 23:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10  4:13 bug: Error handling in source blocks James Powell
2021-08-10 19:42 ` Berry, Charles via General discussions about Org-mode.
2021-08-10 20:30 ` Tim Cross
2021-08-10 23:14   ` Tom Gillespie [this message]
2021-08-11  6:23   ` tomas

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='CA+G3_PPC9VoH8Hm4jFbQWPJojXeCdS5fD5Pm00AY=8RZehXLdg@mail.gmail.com' \
    --to=tgbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@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

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).