Re: [PATCH] Set Python shell in Org edit buffer

[Jack Kamm]

Ihor Radchenko <yantar92@posteo.net> writes:

> Now, the question is what to do with the existing implementation of
> `org-src-associate-babel-session'. It only runs
> org-babel-<lang>-associate-session when
>
> (and session (not (string= session "none"))
>        (org-babel-comint-buffer-livep session)
>        (let ((f (intern (format "org-babel-%s-associate-session"
>                                   (nth 0 info)))))
>            (and (fboundp f) (funcall f session))))
>
> The questionable check here is (org-babel-comint-buffer-livep session) -
> it only triggers when session is already initiated, while ob-python and
> some other backends do not necessarily need to start a new session to
> "associate" it with Org Src buffer.
>
> I am tentatively inclined to change this check to
>
> (or (org-babel-comint-buffer-livep session)
>     (eq org-src-auto-initiate-session t)
>     (alist-get (nth 0 info) org-src-auto-initiate-session)
>     (alist-get 'default org-src-auto-initiate-session))
>
> With `org-src-auto-initiate-session' being a customization that controls
> whether to associate session for a given babel backend.
>
> We may set the default value to something like
>
> ((default . t) ("R" . nil))

I think there are 2 aspects of the session+editing behavior that I'd
like to disentangle:

1. Whether to create session when editing (if it doesn't exist yet)
2. If session exists, whether to "associate" it so that evaluation
   commands (e.g. python-shell-send-region, ess-eval-region) and
   autocompletion use it.

Personally, I prefer to disable #1 while enabling #2. For ob-R, it
seems like #1 happens in `org-babel-edit-prep:R' while #2 happens in
`org-babel-R-associate-session', so adding an option to disable the
latter isn't useful for me, and it's not clear to me whether it'd be
useful generally for others either.

(I realize #2 hasn't worked properly for some time now until you fixed
it in this thread. I wasn't too badly affected because I usually only
use one session at a time, and ess-eval-region is able to figure out
the session in this case. But I did sometimes have to manually call
`ess-force-buffer-current' to get completion working, which it seems I
no longer have to do now that you've fixed this).

As an aside, I just noticed some inconsistent behavior in ob-R. It seems
it only auto-creates the session when ":session *foo*" (i.e. the session
name has "earmuffs"). But when ":session foo" (no earmuffs), ob-R
doesn't autostart the session. While this is probably accidental, it
doesn't seem to cause any problems, which makes me question whether it's
really needful for ob-R to initiate a session on edit.  In particular,
if ":session foo" already exists, then ess-eval-region still works fine
in the src block. Which is exactly my desired behavior -- don't create
the session if it doesn't exist yet, but if it already exists then play
nicely with it.

Another thing to note is that ob-R works fine with sessions externally
created with "M-x R".  (similar to how ob-python works fine with "M-x
run-python"). In fact, I sometimes use ob-R with manual "M-x R" sessions
when I need to use a different R binary/environment than my usual
one. So, it is not necessary for the R session to be started through ob-R.

As for ob-python; I think it's best to set `python-shell-buffer-name'
in `org-babel-edit-prep:python' rather than
`org-babel-python-associate-session'. While both work for
`python-shell-send-region' if the session already exists,
`org-babel-edit-prep:python' has the advantage that it will run even
if the session doesn't exist yet, so then "M-x run-python" in the src
block will create a session with the correct name.