From: Ihor Radchenko <yantar92@posteo.net>
To: Jack Kamm <jackkamm@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] FAILED test-ob-python/session-multiline
Date: Mon, 28 Aug 2023 08:31:52 +0000 [thread overview]
Message-ID: <87edjn4lfr.fsf@localhost> (raw)
In-Reply-To: <87fs449xoy.fsf@gmail.com>
Jack Kamm <jackkamm@gmail.com> writes:
> This one might take some time to fix, since it's hard to reproduce and
> I'm not sure the cause of it. But here are 3 different solutions I am
> considering now:
>
> 1. In addition to printing `org-babel-python-eoe-indicator' after
> execution, we could also print out a "beginning of execution"
> indicator before execution, and then capture the output between the
> beginning and end indicators. This is how the async session
> execution works, and should avoid any possibility of capturing
> prompts.
This idea looks interesting. Although I would not be so sure that it
will fix things - I have learned that comint has many edge cases we may
not easily anticipate.
For example, see the discussion in
https://yhetil.org/emacs-devel/87y1tgqhmc.fsf@localhost/
> 2. Instead of relying on our own custom `org-babel-python-send-string',
> we could try switching to python.el's
> `python-shell-send-string-no-output', which is probably more
> robust. This would also allow removing the ugly
> `org-babel-python-eoe-indicator' we currently print.
Beware non-standard REPL prompts. When we have something other than >>>,
the logic may have hard time figuring out output boundaries without
deterministic separators like eoe-indicator.
> Downside is that the output would not be echoed into the session
> anymore. To fix that, we could manually insert the captured output
> into the comint session buffer after execution. Alternatively, we
> could add an argument to `python-shell-send-string-no-output' to
> avoid suppressing output, submit it upstream to python.el, and then
> backport to Org to support older emacs versions.
If we can (eventually) remove some custom code from Org and move it to
Emacs, it will be the best for working towards RMS request
https://orgmode.org/list/E1kIPh1-0001Lu-Rg@fencepost.gnu.org
> 3. Revisit a series of commits I made in 2020, which was supposed to
> make session evaluation more robust, and was inspired by
> `python-shell-send-string-no-output':
> https://git.sr.ht/~bzg/org-mode/commit/4df12ea39
>
> However, I had to partially revert that work, due to compatibility
> issue with emacs 26.3:
> https://list.orgmode.org/871rjcan53.fsf@kyleam.com/
>
> I think we no longer support emacs 26.3, so I could potentially
> revisit this now -- but it's been a few years and will take some
> time to refresh my memory about this.
Note that I changed `org-babel-comint-wait-for-output' and some other
ob-comint machinery since that time. In particular, I tried to address
various edge cases we encountered with bash sessions. See the commentary
in `org-babel-comint-with-output'.
--
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>
next prev parent reply other threads:[~2023-08-28 8:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-26 12:45 [BUG] FAILED test-ob-python/session-multiline Ihor Radchenko
2023-08-26 15:47 ` Jack Kamm
2023-08-26 16:31 ` Ihor Radchenko
2023-08-27 17:55 ` Jack Kamm
2023-08-28 8:31 ` Ihor Radchenko [this message]
2023-10-15 23:56 ` Jack Kamm
2023-10-16 8:09 ` Ihor Radchenko
2023-10-15 23:39 ` Jack Kamm
2023-10-16 7:55 ` Ihor Radchenko
2024-04-02 18:27 ` Ihor Radchenko
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=87edjn4lfr.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=jackkamm@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
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).