On Mon, Dec 14, 2020 at 5:00 AM Kyle Meyer wrote:
> Thanks. Pushed (57a70d505), tacking on a Reported-by trailer to the
> commit message.
Thanks very much! The fix is working for me.
-Aaron
Juri Linkov writes:
> Thanks for notifying me. I completely agree that the most suitable
> place to fix would be in org-babel-ruby-initiate-session. So here
> is a patch that I tested with different org header args:
[...]
> Subject: [PATCH] ob-ruby.el: Funcall command if it's a function from
>> I'm not sure if it should be org-mode's responsibility to resolve the
>> actual command string, or if it should be done by
>> `run-ruby-or-pop-to-buffer'. (It kind of seems like the latter?)
>>
>> Any thoughts?
>
> Given the current situation, I don't see a good option aside from doing
> the
Aaron Madlon-Kay writes:
>> + (run-ruby-or-pop-to-buffer
>> + cmd (or session "ruby")
>> + (unless session
>> +(inf-ruby-buffer)))
>
> I have
> + (run-ruby-or-pop-to-buffer
> + cmd (or session "ruby")
> + (unless session
> +(inf-ruby-buffer)))
I have just run into an issue with this: If
Kyle Meyer writes:
> Juri Linkov writes:
>
>> Subject: [PATCH] ob-ruby.el: Don't reuse the same buffer among different
>> named
>> sessions
[...]
> Untested on my end, but makes sense as far as I can tell. I'll leave
> another day or so for any ob-ruby users t
Juri Linkov writes:
> Subject: [PATCH] ob-ruby.el: Don't reuse the same buffer among different named
> sessions
>
> * lisp/ob-ruby.el (org-babel-ruby-initiate-session): Instead of
> run-ruby that always insists on using the existing buffer, use
> run-ruby-or-pop-to-buffer
