emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ihor Radchenko
Subject: Re: [PATCH] Set Python shell in Org edit buffer
Date: Sun, 07 Jan 2024 12:54:40 +0000

Jack Kamm <jackkamm@gmail.com> 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))))
>> ...
>> 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))
>
> 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.
> ...
> 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.

I imagine that both #1 and #2 should happen in
org-babel-<lang>-associate-session. #1 should probably be discouraged,
and it looks like even for ob-R creating new session is not really
necessary.

So, a good option could be
(1) removing (org-babel-comint-buffer-livep session) from
    `org-src-associate-babel-session'
(2) Removing `org-babel-edit-prep:R'

Then, the existence of org-babel-<lang>-associate-session will simply be
a reminder for babel backends to implement session support inside babel
edit buffers.

> 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.

With the above, we can use `org-babel-python-associate-session'. Just
for consistency - org-babel-<lang>-associate-session is somewhat
redundant as org-babel-edit-prep:<lang> can be used every time the
format is used, except that org-babel-<lang>-associate-session function
does not need to check if :session argument is present.

-- 
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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]