[ESS] Displaying plots in Emacs

[Michael Lawrence]

On Tue, May 19, 2015 at 7:22 AM, Vitalie Spinu <spinuvit using gmail.com> wrote:

>  >>> 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.
>

What about the httpuv R 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.
>
>
What about just making an Emacs client for Rserve?


>  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
>

	[[alternative HTML version deleted]]