emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug: :session results in unfriendly error reporting
Date: Tue, 17 Aug 2021 16:23:48 +1000	[thread overview]
Message-ID: <871r6swpcu.fsf@gmail.com> (raw)
In-Reply-To: <1755618.1629176532@apollo2.minshall.org>

Greg Minshall <minshall@umich.edu> writes:

> Charles,
> being sympathetic with the idea of better error reporting, i'm curious
> about the following.
>> Right. But there is no error as far as babel is concerned. R has
>> handled the condition. So there is nothing for babel to see/do.
> ...
>> Running R in this fashion starts a fresh process which signals an
>> error that babel can handle.  I see no easy way to get sessions to
>> sends signals that babel can process.
> what is going on here?  is the issue that in the no-session case, the R
> process exits with a non-zero exit code, and that is how "babel" picks
> up on it?
> i put "babel" in quotes ("\"babel\"" :) above, because, in my simple
> mind, babel isn't just the main bit that runs inside org/emacs, but also
> some glue bits that run in the various languages' environments.  things
> like initializing variables, and harvesting results.  so, might one not
> argue that checking execution status, in a session environment, could
> also be part of babel?

I think what Charles is talking about is that with a session, the state
of the session and what it returns is not necessarily anything to do
with what has occured in the code which was executed in the session.

Think of the session as a basic REPL. It reads and expression, tries to
parse and evaluate it, 'prints' out the result and then waits for the
next expression.

Whenn you don't have a session, you just have a basic interpreter. It
reads the input, parses and tries to execute it and either returns what
the successful execution returns or returns some form of error when
something goes wrong. It exits while the session doesn't (yet).

Dealing with errors in the interpreter case is much easier. Dealing with
them in a session is not because the session has not ended and the whole
idea of the session is to manage such things and get ready for the next thing.
The session only ends once all blocks have been processed. What happens
when you add another block at the end of the org file which is to use
the same session - it has to still be running or you have to evaluate
all the blocks again.

Yes, you could add session variables and use them to track error states
etc. But that would be something each separate language would have to do
and the ability to capture that information for different languages
probably varies.

It isn't so much that nothing is possible but rather nobody has
implemented a consistent model which can be adopted and has been
implemented by all backends. This is why I consider this to be a feature
request and not a bug report. This is not expected/defined behaviour
which is not behaving according to spec - this is new unimplemented
behaviour, a new feature which needs to be designed and implemented
across all backends.

This would be a good feature to have. The work is non-trivial and would
take significant time to implement.

  reply	other threads:[~2021-08-17  6:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-15 23:41 Bug: :session results in unfriendly error reporting James Powell
2021-08-16 18:25 ` Berry, Charles via General discussions about Org-mode.
2021-08-17  5:02   ` Greg Minshall
2021-08-17  6:23     ` Tim Cross [this message]
2021-08-17  7:44       ` Greg Minshall
2021-09-27  8:42         ` Bastien
2021-09-27  9:52       ` Greg Minshall

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:

  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=871r6swpcu.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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


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