[ESS] Displaying plots in Emacs

[Vitalie Spinu]

 >>> Michael Lawrence on Mon, 18 May 2015 21:30:37 -0700 wrote:

 > The issue is how we actually transfer the SVG data to Emacs.  I could see
 > doing something with sockets, but that sounds redundant with nREPL.

Yes, that's exactly the idea. Transfer either SVG or raw png data
through sockets or other transfer channels. Good thing about nREPL is
that the transfer layer is by construction separated. You can add
whatever weirdo transfer protocols latter and everything else will work
out of the box. My plan is to have TCP sockets first and Web Sockets a
bit later.

  > How far along is nREPL?

Conceptually it's pretty far. I have a pretty clear picture of what has
to be done. But it's a fairly complex issue with many running
pieces. Here are the main ones.

 - The R-nREPL is pretty basic now. It uses R's builtin connection
   system that is limited to only one client per server's
   session. That's unacceptable from a tool which calls itself "network
   REPL".

   My plan is to base it on libuv [1], but that means writing a separate
   binding package.

 - Emacs nrepl-client.el [2] is tightly bound with CIDER/clojure
   ecosystem. I have already done some work on cleaning and splitting it
   up, but more should still be done.

 - Emacs support for image manipulation sucks. Simply displaying images
   in repl window is not what I would be satisfied with. I have now
   almost finished image-transform and image-display [3]. Image-display
   is a replacement for image-mode that works well with potentially very
   long chains of images and abstracts from the physical representation
   of those images. You can have images as files, archives, email
   attachment or piped through nREPL. The exact physical representation
   doesn't matter, the UI is the same for all cases.

 - nREPL is by construction asynchronous and R's inability to do basic
   concurrency is a huge handicap. So additional tooling must be build
   which is not needed for Clojure.

   My workaround idea is to have one R master server and one R slave
   fork for each new client instance, The master will take care of
   routing client requests to slave forks and will also be responsible
   for tooling requests which are different from eval requests
   (completions, help etc). That would allow a pretty good amount of
   non-blocking communication and should be more than enough for most
   needs.

 Vitalie


[1] https://github.com/libuv/libuv
[2] https://github.com/clojure-emacs/cider/blob/master/nrepl-client.el
[3] https://github.com/vspinu/image-display