emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Phil <pe@7d.nz>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-babel-execute-src-block filters characters from :session *shell* output
Date: Thu, 04 Jul 2024 11:55:26 +0000	[thread overview]
Message-ID: <87wmm1pe1d.fsf@localhost> (raw)
In-Reply-To: <ae988c8d-1793-47d4-95e4-705add7b8acc@7d.nz>

Phil <pe@7d.nz> writes:

> The error management channel is important.  Only a very
> small fraction of errors should be silenced, and we
> must not have feedback displaying that a function ran
> correctly when it did not.

Sure. I completely agree.

> Let's decouple an interactive shell from its
> compiler/interpreter (setting aside a Lisp
> evaluator that can dodge most of the problems):
>
> In many programming languages the source code can
> indeed be assimilated line by line by the
> interpreter through an interactive shell.
> - It returns nothing or an error after a definition
>    or a silent directive, then the prompt.
> - One or more values as a result or errors, then the prompt,
>    when calling functions and procedures.
> - It can expect more input and more lines before
>    terminating a statement, returning a secondary
>    prompt until that statement completes or fails.
>
> The terminal display is organized from programming
> interactions but the separation of channels is needed
> for further processing.
>
> 1) We should avoid filtering output with regexp acrobatics.

It is indeed not ideal. But it is hard to do better.
We simply do not have the means.

Of course, if someone can find a more robust way to decouple errors,
actual evaluation results, prompts (primary, secondary, etc), and the
interpreter echoing the input, it would be a patch we will happily
accept.

> 2) Communication with the process should go
>     through a function that can display
>     inputs and outputs and errors in three different channels
>     before sending it to the process.
>     Communicating directly to the process should remain
>     possible, but it's a short-circuit.

Yes, of course. But how?

> + Err : file, line, error code, message,
>       including the prompt which goes to stderr.
>     + The line number where the error occurs
>       related to a source block. There may be extra code
>       wrapping a block and noweb may complicate
>       things even more.
>       The situation to avoid is a line number unrelated
>       to the edited source block.
>       (Weaving and tangling programs is fine for me
>       I'm only thinking out loud here).

> Example:
> Errors goes in one file buffer
> and a filter wraps them in blocks.
> file:/tmp/babel-uuid/fiction.err
> #+begin_err :lang fiction :err 5 :line 2
> Parse error: near "?": syntax error
>    ? ;
>    ^--- error here
> #+end_err

This would be nice to have for sessions, yes. We already have this for
many non-session code blocks.

> Should all commands in a block be run ?
> It depends on the language of course, but usually, no,
> the execution stops and drops into a backtrace
> or raises an exception pointing to the stack frames.
> Dash has =set -e= (that doesn't always behave as expected).
> Sqlite has =.bail= for noninteractive sessions.

I am not sure if I agree, but your preference is a valid preference some
people might have. Our defaults are to send the whole block, which is an
ok option as well.

> And now here is my problem.
> Am I missing something about carriage return ?
> A differentiation problem between what happen
> when pressing C-q C-j in a shell, and <return> ?
>
> If ob-sql-session concatenates the SQL
> commands on one line, sqlite is able to stop on error.
> #+begin_src sql-session :engine sqlite :session A
>    select 1;  raise;   select 2;
>    select 33;
> #+end_src
>
> #+RESULTS:
> : 1
> : Parse error: near "raise": syntax error
> :   raise;   select 2; select 33;
> :   ^--- error here
>
> If it does not, a newline terminates the command,
> the prompt is displayed and the next line is
> an other command. Which is not the desirable effect
> as there's no way to halt the remaining commands.

This is simply how comint.el buffers work.
C-q C-j will enter literal newline. <return> will send the command
entered so far (including literal newlines) as input stream to the
interpreter. All at once.

The reason why comint does not do line-by-line is simply because it has
limited notion of the interpreter syntax - multiple lines may or may not
be several commands. Think of \ continuation in bash.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


  reply	other threads:[~2024-07-04 11:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13 14:32 org-babel-execute-src-block filters characters from :session *shell* output Cook, Malcolm
2024-06-14 14:09 ` Ihor Radchenko
2024-06-14 14:29   ` Cook, Malcolm
2024-06-15 13:19     ` Ihor Radchenko
2024-06-16 12:47       ` Max Nikulin
2024-06-17 17:57         ` Ihor Radchenko
2024-06-30 19:05           ` Ihor Radchenko
2024-07-02 19:34             ` Phil
2024-07-02 20:05               ` Ihor Radchenko
2024-07-03 21:07                 ` Phil
2024-07-04 11:55                   ` Ihor Radchenko [this message]
2024-07-06 11:36           ` Max Nikulin
2024-07-06 15:43             ` Ihor Radchenko
2024-07-09  7:54             ` Phil
2024-06-17 15:48       ` Cook, Malcolm
2024-06-17 18:03         ` Ihor Radchenko
2024-06-17 22:40           ` Cook, Malcolm
2024-06-17 23:09             ` Cook, Malcolm
2024-06-19 14:40             ` Ihor Radchenko
2024-06-30 19:08       ` Ihor Radchenko
2024-07-06 11:39         ` Max Nikulin
2024-07-06 11:46           ` Ihor Radchenko
2024-08-05 15:08         ` Ihor Radchenko
2024-10-23 15:49           ` org-babel-execute-src-block filters characters from :session *shell* output AND Re: [BUG] conda doesn't work in ob-shell sessions Cook, Malcolm
2024-10-23 16:52             ` Cook, Malcolm

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=87wmm1pe1d.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=pe@7d.nz \
    /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).