ESS module refactor

Hi guys!

I use R for my work, and I used RStudio Server, but for internal policies the access was closed. Trying ESS in doom the experience was a little rough. I installed spacemacs with the ESS layer and it was much smoother.

This post is to start a discussion about a refactor for the ESS module to improve the experience for the final user.

Note: I have all the motivation, but not all the lisp skills, to do this massive task. Of course, I offer my help with the refactor and co-maintain the module.

Note 2: I have started a branch in my doom’s fork to start playing around with the configuration. Please feel free to contribute as much as you want.

Initial ideas

The layout

The R editor de facto is RStudio, so I think that a good start could be to take this layout as the starting point.

I’m not attached to this, of course, but I think that this could be less intimidating to beginners that want to try Emacs as your R editor.

In my config.el I have this naive configuration for it. It needs a lot of work, though.

(set-popup-rule! “^\\*R.*\\*”  :side ‘bottom :width 0.5 :quit nil :ttl nil)
(set-popup-rule! “^\\*R Data View.*\\*” :side ‘top :slot 1 :width 0.5 :quit nil :ttl 0)
(set-popup-rule! “^\\*R dired\\*” :side ‘right :slot -1 :width 0.33 :quit nil :ttl 0)
(set-popup-rule! “^\\*help\\[R\\]”  :side ‘right :slot 1 :width 0.33 :quit nil :ttl 0))

The Buffers’ behavior

This is tricky because Emacs allows the user to have total freedom here.

In the current state of the module, if you open the *R* process and press ESC or q, it kills the buffer and, of course, the process (all the loaded data is lost).

The options here help with this problem

(set-popup-rule! “^\\*R.*\\*”  :side ‘bottom :width 0.5 :quit nil :ttl nil)

Also, I have those for the same problem.

(map! :after ess-help
      :map ess-help-mode-map
      :n “q” nil
      :n “ESC” nil)

(map! :after ess-rdired
      :map ess-rdired-mode-map
      :n “q” nil
      :n “ESC” nil)

Another idea is to use something like zoom for putting emphasis on the code, the *R* process, the environmental variables, etc.

Performance

I’m lost here, but it would be great to see if there are some configurations to do for lsp-mode and eglot.

Also, there is no configuration by default for lsp-mode over TRAMP. It’s just to put this in some place:

(lsp-register-client
  (make-lsp-client
   :new-connection
   (lsp-stdio-connection '("R" "--slave" "-e" "languageserver::run()"))
   :major-modes '(ess-r-mode inferior-ess-r-mode)
   :remote? t
   :server-id 'lsp-R-remote))

Speaking of TRAMP, I don’t know what kind of improvements we could do to reduce the latency when the user interacts with the *R* process.

More ideas

Final

This is will be my first big project for doom. All the feedback and help is very welcome.

Thanks.

5 Likes

Excellent idea and initiative, I’m not using R but ideas emerging here could also be beneficial for other scientist or data driven workflows.

I note that you mentioned quarto which I found excellent and a serious outsider for org-mode even if the latter is more powerful. Pandoc integration in quarto is really excellent.

Ideas may also be taken from vscode-r

Reviewing the vscode-r project I found some interesting ideas to explore. I’ll add them to the main post.

Thanks for the suggestion.

Personally I dont think these should be defaults. They can be very good documentation extras, however, and we can facilitate a level of “rstudio-like-emulation” with a new package.

That sounds awesome. Could you please expand a little further how to implement this idea?

My first thought is this rstudio-mode package should be a configuration meta-package of other ones, or am I wrong?

I created a new doom’s fork to start the contributions there.