Ihor Radchenko <yanta...@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.