Re: org-babel-execute-src-block filters characters from :session *shell* output

[Phil <pe@7d.nz>]

* [2024-06-16 14:47] Max Nikulin:
>> On 15/06/2024 20:19, Ihor Radchenko wrote:
>>> The underlying cause is a limitation of Emacs API for
>>> interactive shells - we cannot easily distinguish
>>> command output from prompt and other extra stuff
>>> your shell/other interactive command spits into the
>>> buffer.
>> Some shells support "semantic shell" that allows
>> terminal applications e.g. to copy whole command
>> output. It is based on escape sequences.
>> - https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md
>> - http://per.bothner.com/blog/2019/shell-integration-proposal/
> 
> it is implemented by simply setting PROMPT in a way
> that adds these escape sequences to the original
> PROMPT value.
> one downside will be that the unicode character we
> add may be carried along if the user copies the
> comint buffer contents.

Perhaps a minor-mode would get to the rescue
to filter copies?

I'd like to add a few general remarks about *error status*.
I'm starting to notice there are not much subprocesses
that to do get called through =call-process= with
‘(REAL-DESTINATION ERROR-DESTINATION)’ kept as
separate.  You all know how useful stdin/out/err and
the return codes are, but they're absent from Babel.

That's why a failed command will still provide a result
— an empty array for instance, something that looks
legit even when it's not.  I had again this experience
with =ob-http :pretty= and =ob-mongo= lastly: errors are
silenced.

Comint reads and write from/to terminals with all
three standard channels together. It's meant to
provide requirements to communicate with non-POSIX
terminals too. It's a great library but perhaps
there's a need to specialize things further when
dealing with one shell?

So In Emacs, those specs would land either in one precise
(possibly low-level) shell extension or a generic one that
would once more care for the many idiosyncracies every one
of them have.

Something I figured when dealing with ob-sql-session is
that if several commands are given in one batch (what a
babel source block is in many cases), they can either be
all run until the end or be stopped when an error is
met. In both cases, knowing the number of errors met is
possible in one shell that do agree with the convention
of returning a value for every command (or command line).
Otherwise, a terminal "reader" has to reinterpret the
results.

[[info:elisp#Synchronous
  Processes][elisp#Synchronous Processes]] says :

    You can’t directly specify a buffer to put the
    error output in; that is too difficult to
    implement.

Can someone explain why?


Phil