Ihor Radchenko <yanta...@posteo.net> writes: > Jack Kamm <jackk...@gmail.com> writes: > >>> FAILED 376/1256 test-ob-python/session-multiline (0.011955 sec) at >>> ../lisp/test-ob-python.el:105 >> >> Hmmm. Do you have an idea of how long this has been happening, and how >> frequently it breaks? > > For months. > >> My first suspicion is the large ob-python commit I pushed on Tuesday: >> >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=579e8c572345c42ad581d3ddf0f484567d55a787 > > So, should not be the recent commit.
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. 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. 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. 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....@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. Of these options, Option 1 is the easiest, and the most certain to solve this bug. Options 2 and 3 are more difficult and riskier, but would have other benefits if they work: we can remove the ugly `org-babel-python-eoe-indicator' that is currently printed to the session, and/or reduce long-term maintenance burden by relying on python.el's implementation for capturing output.