Collaboration for ESS module on doom-emacs

[maikol-solis]

Hi!

I just saw your video about ess-unigd in YT, and I'm very impressed. Some time ago, I wanted to do something similar for the ESS module in doom, unsuccessfully.

There is a PR opened and some first discussion here and here.

I wondered if you were planning to develop this code into a proper package, or if it is simply a proof of concept.

In any case, I want to know what the possibilities are to share some ideas and see if I can finish the PR for doom-emacs.

Best.

[sje30]

hi! thanks for getting in touch, and for sharing your ideas. It looks like you are a fair bit along the path to doing something similar to what I was thinking, e.g. in this plot:

https://discourse.doomemacs.org/t/ess-module-refactor/2681/13

so here do I take it that you are running xwidget in the bottom right window to get the R plots.

In what sense didn't it work? I would have thought that should be all you need.

As for my plans, sure, I'd be happy to tidy it up into its own package (thinking of essgd.el as the new title) and put. on melpa. At this stage it is proof of concept just because I'm tinkering with ideas. But I think I'm converging and mostly happy with the approach. (Although see #3 for a bug that I can't yet figure out.). I was thinking also of seeing if we should put it into ESS (I'm one of the developers), but thought I'd keep it separate for now.

[maikol-solis]

In what sense didn't it work? I would have thought that should be all you need.

Mostly, my lack of skills with lisp. I still don't know how to connect the ESS process, with xwidget and httpgd. In V2, you started the httpgd process and extracted the URL with a regex. I am going to copy this idea from you.

As for my plans, sure, I'd be happy to tidy it up into its own package (thinking of essgd.el as the new title) and put. on melpa. At this stage it is proof of concept just because I'm tinkering with ideas. But I think I'm converging and mostly happy with the approach. (Although see #3 for a bug that I can't yet figure out.). I was thinking also of seeing if we should put it into ESS (I'm one of the developers), but thought I'd keep it separate for now.

Oh, I didn't know you were one of the ESS developers. Thank you for all your work on ESS.

I think it'll be easier to put the plots in the window layout if you decide to make a package (just by calling essgd-start, instead of factoring the whole thing in doom).

I'll keep trying your code and see how to organize the window layout in my PR. Any ideas or comments are welcome.

Best.

[rdiaz02]

Hi @maikol-solis .

I still don't know how to connect the ESS process, with xwidget and httpgd.

I wrote the following functions to use xwidgets (or EAF) for displaying figures inside Emacs (beware: Elisp newby here!):

(defun R-hgd2 ()
  "Split R window, launch httpgd."
  (interactive)
  (progn
    (split-window-vertically)  
    (insert "library(httpgd); httpgd::hgd(token = FALSE)")
  (comint-send-input)))

(defun R-launch-hgd-xwidget-browse ()
  "Load httpgd library in R, and launch xwidget after splitting"
  (interactive)
  (R-hgd2)
  ;; maybe could decrease. Whatever. Yes we need hgd to return
  ;; If right after startup, it needs to be at least around 2
  (sleep-for 2)
  (goto-char (point-max))
  (forward-line -1)
  (search-forward "h")
  (xwidget-webkit-browse-url (thing-at-point 'url)))

(defun R-launch-hgd-eaf-browse ()
  "Load httpgd library in R, and launch xwidget after splitting"
  (interactive)
  (R-hgd2)
  ;; maybe could decrease. Whatever. Yes we need hgd to return
  ;; If right after startup, it needs to be at least around 2
  (sleep-for 2)
  (goto-char (point-max))
  (forward-line -1)
  (search-forward "h")
  (eaf-open-browser (thing-at-point 'url)))

I am not a Doom user, so maybe there are some additional issues to consider, but these work just fine for me. The function names R-launch-hgd-xwidget-browse and R-launch-hgd-eaf-browse are unwidely, so I use two aliases (Rxwb, Reaf). And I have this setup the way I prefer: inferior R buffer below, figure on top, but of course modify to suit your needs.

I have both EAF (Emacs Application Framework (https://github.com/emacs-eaf/emacs-application-framework) and xwidgets because xwidgets recently broke or will be broken soon ( https://mail.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg02681.html , https://debbugs.gnu.org/db/66/66068.html )

Finally, I use the above often when launched from an Eamcs daemon (I connect to the daemon via emacsclient). There is a long known issue with the GTK build and server disconnects, so in the server where I do that, I use the Lucid build. But xwidgets will not run on the Lucid build (xwidgets needs to be compiled with GTK for there to be xwidgets support). EAF does run on Lucid just fine. But it does not like being run from emacsclient: it will give you a warning and much of EAFs functionality does not work, but it will display the plots.

Note, though, that with both solutions, I frequently run into problems in long-running R sessions or with complex plots that take a long time to display; it looks like httpgd disconnects, which might be related to https://github.com/nx10/httpgd/issues/67 . But it is hard to reproduce easily at will.

I think, though, that moving forward ess-unigd would be the best option as there are no dependencies on xwidgets or EAF.

[sje30]

hi @maikol-solis @rdiaz02

I just tidied up the code into a form that I think should be ready for MELPA:

https://github.com/sje30/essgd

We can keep the current issues here, and move over when there are new things to discuss.

I plan to submit to MELPA after checking it passes all the local tests.