1

I often share an R process with multiple .R files. The default in ESS when I ess-eval-line-invisibly-and-step from a new file within a different R package I develop is to create a new R process. The current need is to allow this, then tell R to change the target process to my *R:1*, then kill this *R:2* that I didn't want it to create.

I think it's related to ess-r-package-project, ...-info, or something within ess-r-package-*, but I can't seem to get it right.

Namely, these don't seem to change the behavior:

(setq ess-r-package-auto-activate nil)
(setq ess-r-package-mode nil)
(setq ess-r-package-auto-enable-namespaced-evaluation nil)

So I'd like to be able to either of the following:

  • switch the target process before starting a new one
  • do not automatically start a new process when in a new package directory

Update: emacs does not give me a complete choice of processes for a given buffer. Walk-through:

  • open a file in one of my packages pkg1, start R into *R:1:pkg1*; sourcing lines (ess-eval-line-invisibly-and-step) sends code to this process, so far so good
  • open a file in a different package pkg2, try to ess-eval-line-invisibly-and-step a line into the first process, instead starts *R:2:pkg2*
  • try to switch the target process for pkg2/file.R, but ess-switch-process only offers { *R:2:pkg2* | *new* }, does not show nor provides a way to select *R:1:pkg1*
2
  • 2
    Don't you get a question with a Process to use: prompt about which process to use? That should come from ess-force-buffer-current, in which case you just give it the name of the existing process.
    – NickD
    Jan 28 at 2:03
  • @NickD it does, but not a complete list. Even if it gave me a complete list of current R processes, I cannot pre-determine which process to send it to, since merely trying something -- including ess-switch-process -- causes it to start a new one, at which point I would need to be able to see and select *R:1:pkg1* to be able to switch, but I cannot. I think this is a very recent bug, self-answering shortly.
    – r2evans
    Jan 28 at 5:02

1 Answer 1

1

I'm not certain that this really is the intended solution to the problem, but by reverting a portion of a recent commit (88d611c), I'm able to restore the original behavior:

The portion of the commit that I reverted is this:

diff --git a/lisp/ess-inf.el b/lisp/ess-inf.el
index 9ca3f455..aaff314c 100644
--- a/lisp/ess-inf.el
+++ b/lisp/ess-inf.el
@@ -828,6 +828,8 @@ to `ess-completing-read'."
                                                    'ess-dialect
                                                    (process-buffer (get-process (car lproc)))))
                                            (not (equal ess-local-process-name (car lproc)))
+                                           (equal (buffer-name (process-buffer (get-process (car lproc))))
+                                                  (funcall ess-gen-proc-buffer-name-function (car lproc)))
                                            (car lproc)))
                                     ess-process-name-list)
                             ;; append local only if running

By commenting out those two +-added lines, recompiling ess-inf.el, then reloading emacs, I'm able to restore the prior behavior. Namely, the walk-through from the (edited) question:

  • open a file in one of my packages pkg1, start R into *R:1:pkg1*; sourcing lines (ess-eval-line-invisibly-and-step) sends code to this process, so far so good;
  • open a file in a different package pkg2, and now doing ess-eval-line-invisibly-and-step on a line into the first process works; and
  • calling ess-switch-process shows { *R:1:pkg1* | *R:2:pkg2* | *new* }, as expected.

Again, I'm not certain that there isn't a preferred/intended/canonical way to get the pre-commit behavior I'm looking for. This is submitted as ESS#1276, perhaps the developers can shed light on it. Edit: patched with d8472e0, not yet on melpa.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.