process control for different projects

[r2evans]

I don't understand a recent change to ESS on how the ess process is being chosen. I have a couple dozen packages, and often share one or a few R processes while working on them. However, when I source from one package's file (e.g., ess-eval-line-invisibly-and-step), it starts a new process, and even after that process is started I cannot change that file's process to the original.

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
• 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* }, no way to select *R:1:pkg1*

I've tried combinations of

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

This behaves this way even when starting emacs with --no-init-file and loading ESS manually with

(use-package ess :load-path "elpa/ess-20240122.1720")
(setq inferior-ess-program "R")
(setq inferior-R-program-name "R")
(setq ess-local-process-name "R")
(require 'ess-site)

But for my regular work, I'm using these .el files:

~/.emacs.d/init.el

``` '(ess-developer-code-injection-in-packages nil) '(ess-eval-visibly nil) '(ess-history-directory "~/") '(ess-history-file "~/.Rhistory") '(ess-indent-level 2 t) '(ess-indent-offset 2 t) '(ess-indent-with-fancy-comments nil) '(ess-plain-first-buffername nil) '(ess-roxy-str "#'") '(ess-roxy-template-alist '(("description" . ".. content for \\description{} (no empty lines) ..") ("details" . ".. content for \\details{} ..") ("param" . "") ("return" . ""))) '(ess-style 'RStudio) '(ess-swv-processor 'knitr) '(ess-toolbar-global nil) '(inferior-ess-exit-command "q(\"no\") " t) '(inferior-ess-r-program "/opt/R/4.3.2/bin/R") ```

~/.emacs.d/lisp/my-ess.el

``` (defun my-ess-hook () "more stuff to load with ess" (setq ess-indent-level 2 comment-add 0 ess-save-silently t ;; https://github.com/emacs-ess/ESS/pull/1019, https://github.com/emacs-ess/ESS/issues/759 inferior-ess-fix-misaligned-output t) (setq eldoc-idle-delay 2 ; or something >> 1? ess-use-eldoc nil) (local-set-key (kbd "M--") 'ess-cycle-assign) ;; keep me from accidentally KILLING R (again) (define-key ess-extra-map "r" nil) (define-key ess-extra-map "\C-r" nil) (define-key ess-mode-map "\C-c\C-n" 'ess-eval-line-invisibly-and-step) (require 'company) (push (list 'company-R-args 'company-R-objects 'company-R-library :separate) company-backends) (company-mode) ) (defun my-postinit-ess () "my ess init code run after package-initialize" (require 'ess) (require 'ess-site) (setq-default ess-dialect "R" ;; ess-default-style 'RStudio inferior-R-args "--no-save " ;; mostly for Rmd files, since "trailing double spaces" is relevant ess-nuke-trailing-whitespace-p nil ess-ask-for-ess-directory nil) (add-hook 'ess-mode-hook 'my-ess-hook) (add-hook 'inferior-ess-mode-hook 'my-ess-hook) (setq comint-scroll-to-bottom-on-input t comint-scroll-to-bottom-on-output t comint-move-point-for-output nil ;; https://github.com/emacs-ess/ESS/issues/316 ;; ess-r-package-auto-activate nil ) ) (add-hook 'after-init-hook 'my-postinit-ess) ```

OS/versions

``` ubuntu 23.10 (Wayland) GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-09-02, modified by Debian ess-version: 24.01.0 [elpa: 20240122.1720] (loaded from /home/r2/.emacs.d/elpa/ess-20240122.1720/) ```

[r2evans]

Looking at the commit log, I reverted part of 88d611c6833d521d0fbb2ef9c638bf6b3525a622,

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 the two added lines, I've restored the ability to source lines/regions from different packages into the same R process, and I can see all processes when I try to ess-switch-process. I don't know if its behavior was intentional.

[lionel-]

Looks like this is from your patch @ihor-radchenko, could you take a look please?

[mmaechler]

Yes, I'm also suffering very badly from this. Even worse, for one "project" (I don't work with projects but in the same emacs with different *.R scripts and notably as R-core member with several different R versions, notably "R-devel" vs. released version of R, versus "yesterday's version" of R ...

It has become almost impossible to evaluate the same region of R code into two different *R* buffers, may daily business as R Core developer, but also common when fixing a bug in other R code, running old version in one R buffer and the modified version in an (or several) other R session buffers.

A really simple hopefully reproducible (so many different versions of emacs nowadays, different setup..) example, Can you reproduce: Start Emacs, then M-x R .. (only one R process for now), only now open a .R file Try to eval some code. Instead of just "sending" it to the `R` buffer we had created (with M-x R) before, it asks me about where I would want the next* R process to run ... argh... and if I type C-c C-s (ess-switch-process), I do not even get the only existing running R as one of the choices!

[mmaechler]

... and yes, @r2evans proposal solve the big problem for me. As this is "uniformly better" than previous, and a reversion to previously blameless behavior (I do not work with ess-remote, though) I did commit & push this for now (and failed to send this comment before I did ...)