[ESS] Displaying plots in Emacs
@p|nuv|t @end|ng |rom gm@||@com
Tue May 19 16:22:19 CEST 2015
>>> 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
> 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
My plan is to base it on libuv , but that means writing a separate
- Emacs nrepl-client.el  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 . 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
More information about the ESS-help