On 30/06/2024 18:06, Ihor Radchenko wrote:
Max Nikulin writes:
https://debbugs.gnu.org/67259
Notice that the report is for *interactive* sessions. Org babel sessions
are not so interactive. They are to maintain state, not to interact with
users directly...
You are not right. We have legitimate cases when people can switch to
session buffer, enter commands there, switch back to Org buffers,
send code blocks to the same session, and so on.
Timings are still important part of interactive sessions and ob-shell
has no chance to simulate them having just block of commands.
By the way, dash does not support bracketed paste since it is a minimal
shell mainly for interpreting scripts. So result of pasting several
commands at once is different from bash. I do not think it is related to
dash bugs.
Possible voluntary decision is to consider every session source block
similar to "C-x C-e" in bash prompt, so nothing should become implicit
stdin of commands. Content of a source block should be saved into a
temporary file then "source /path/to/block_content" command should be
send to the session buffer. Likely command depends on shell.
This may work, but we should at least echo the original commands into
session buffer, because users may want to examine them.
I have no idea which way bash or readline function
edit-and-execute-command is implemented, but commands are echoed when
editor is closed. Anyway it may greatly vary across shells.
I am unaware if it is possible to detect if bracketed paste is
implemented and to send input as bracketed paste. Perhaps some escape
sequences are involved. ob-shell might offer variants for sessions: dumb
stdin, source a temporary file, or bracketed paste. Anything besides
stdin (with its confusing differences from interactive sessions) is
almost certainly requires shell-specific code. And `shell' is likely not
suitable with its TERM=dumb.
