[ESS] Displaying plots in Emacs

Michael Lawrence |@wrence@m|ch@e| @end|ng |rom gene@com
Tue May 19 06:28:47 CEST 2015 

On Mon, May 18, 2015 at 8:58 PM, Vitalie Spinu <spinuvit using gmail.com> wrote:

>
> I don't think there will ever be image support as part of ESS. ESS just
> cannot handle that sort of complexity. If image handling is ever added
> to it it's bound to be an ad hoc and patchy solution.
>
> On the other hand nREPL will work from the start with inline images,
> that's sort of things that MPI's are perfect for. "evaluate" pacakge
> already handles image recording quite well. So, basic pieces are there,
> someone has to put them together.
>
>
How far along is nREPL?


> I am 90% of the time on remotes and each time I need to plot something
> complex I have to take a coffee break. If something, like saving to
> files, works only on local machines it's not even worth trying
> implementing IMO.
>

Won't files just work via tramp? Coupled with change notifications, files
could work fairly seamlessly.


>
>   Vitalie
>
>
>  >>> Ista Zahn on Mon, 18 May 2015 19:42:02 -0400 wrote:
>
>  > On Mon, May 18, 2015 at 7:22 PM, Michael Lawrence
>  > <lawrence.michael using gene.com> wrote:
>  >> Hardest part is probably getting the data from a potentially remote R
>  >> session to Emacs. The Vitalie's nREPL package sounds like a potential
>  >> solution, if it were mature enough.
>
>  > I think it would be worth doing even if it only (perhaps initially)
>  > works when R is running locally. This would be a very useful feature,
>  > and I'd hate to see it indefinitely put off because of the difficulty
>  > of supporting remote sessions.
>
>  > On another note: I don't think the pdf-tools package Titus suggested
>  > works on Windows. I don't personally care about that, but perhaps it
>  > is something to keep in mind.
>
>  > Best,
>  > Ista
>
>  >>
>  >> On Mon, May 18, 2015 at 3:55 PM, Martin Maechler <
> maechler using stat.math.ethz.ch
>  >>> wrote:
>  >>
>  >>> On Mon, May 18, 2015 at 8:01 PM, Titus von der Malsburg
>  >>> <malsburg using posteo.de> wrote:
>  >>> >
>  >>> > On 2015-05-15 Fri 13:48, Michael Lawrence wrote:
>  >>> >> There was a long discussion on this here:
>  >>> >> https://stat.ethz.ch/pipermail/ess-help/2013-November/009559.html.>>
> >>
>  >>> >> Here is one approach. The R graphics engine calls Mode(1) on the
> device
>  >>> >> whenever it is "finished" drawing (the engine might "finish"
> multiple
>  >>> times
>  >>> >> when generating a single plot). This allows e.g. buffered screen
>  >>> devices to
>  >>> >> flush their buffer. The file devices do not listen to that; they
> defer
>  >>> that
>  >>> >> until they are deactivated. In theory, the engine could execute an
> R
>  >>> >> callback at that point, and the callback would typically call
>  >>> recordPlot()
>  >>> >> to get the display list, and replay the plot on some other device
> (with
>  >>> the
>  >>> >> callback disabled). Would need to check the performance profile on
> that,
>  >>> >> i.e., how greedy R is about flushing.
>  >>> >>
>  >>> >> Ideally, the file devices would support connections, so we could
> stream
>  >>> the
>  >>> >> data as PDF or PNG to ESS, without touching the disk, which is
> tricky
>  >>> when
>  >>> >> running R remotely (would tramp help?). But Emacs would need a way
> to
>  >>> >> display an image from in-memory buffer. It sounds like pdf-tools
> might
>  >>> >> enable that for PDF.
>  >>> >>
>  >>> >> If people think this or something like it might work, I'll see
> about
>  >>> adding
>  >>> >> those features to R.
>  >>> >
>  >>> > Hi Michael, unfortunately I don’t know enough about the R side of
> things
>  >>> > to give you useful feedback on your proposal.  If there is any Elisp
>  >>> > hacking to do to make this work, let me know because there I might
> be
>  >>> > able to help.
>  >>> >
>  >>> >   Titus
>  >>>
>  >>> I can't promise any help ... but I find the principal idea really
> cool:
>  >>> a pdf connection to non-disc memory (instead of traditional disc based
>  >>> file)
>  >>> to which R would write and Emacs could display in a buffer.    Reallz
>  >>> something we could be proud of!
>  >>>
>  >>> Martin
>  >>>
>  >>> >
>  >>> >>
>  >>> >> Michael
>  >>> >>
>  >>> >> On Fri, May 15, 2015 at 12:30 PM, Titus von der Malsburg <
>  >>> malsburg using posteo.de
>  >>> >>> wrote:
>  >>> >>
>  >>> >>>
>  >>> >>> One feature that I really miss when developing R code with ESS is
> the
>  >>> >>> ability to display plots in Emacs.  The free-floating plots
> generated
>  >>> >>> R’s plotting functions are really annoying because they pop up in
>  >>> random
>  >>> >>> positions and almost always cover stuff that I need to see.
>  >>> >>>
>  >>> >>> Last time I checked, people said that the only way to have plots
> in
>  >>> >>> Emacs windows would be use the XWidget branch of Emacs which
> allows
>  >>> >>> embedding of GTK widgets into Emacs buffers.  This may be a neat
>  >>> >>> solution (although R doesn’t seem to use GTK) but it’s not going
> to
>  >>> >>> happen anytime soon because the XWidget branch is pretty dead
> (last
>  >>> >>> commit in Sept 2013).
>  >>> >>>
>  >>> >>> Luckily, there may be a much simpler solution: Emacs has a
> fantastic
>  >>> >>> support for viewing PDF files via the pdf-tools package [1].  (For
>  >>> >>> people who don’t know pdf-tools, it allows you to isearch PDF
> files and
>  >>> >>> to create and edit annotations that a compatible with those
> created by
>  >>> >>> Adobe tools.  Amazing!)  So one solution is to plot into a PDF
> file and
>  >>> >>> to display that PDF in a separate Emacs buffer window.
>  >>> >>>
>  >>> >>> This has the potential to be really convenient.  For example, we
> can
>  >>> >>> activate auto-revert-mode in the buffer displaying the PDF such
> that
>  >>> the
>  >>> >>> PDF is automatically refreshed when a new plot is written to the
> PDF
>  >>> >>> file.  Also pdf-tools can scale the plot to fill the window.  This
>  >>> means
>  >>> >>> that we can resize the window and the size of the plot is
> dynamically
>  >>> >>> adapted – no need to replot.
>  >>> >>>
>  >>> >>> So far, this solution works really nicely and certainly much
> better
>  >>> than
>  >>> >>> the x11 windows created by default.  However, there are two
> things that
>  >>> >>> are suboptimal:
>  >>> >>>
>  >>> >>> 1.) It is annoying that I have to type and execute:
>  >>> >>>
>  >>> >>>   pdf()
>  >>> >>>   plot(1:10)
>  >>> >>>   dev.off()
>  >>> >>>
>  >>> >>> instead of just:
>  >>> >>>
>  >>> >>>   plot(1:10)
>  >>> >>>
>  >>> >>> Is there a way to use the PDF renderer as the default device
> instead of
>  >>> >>> x11?  If not (which is likely), what else can be done to free the
> user
>  >>> >>> >From having to generate the PDFs manually?  Is there perhaps a
> clever
>  >>> >>> way to wrap the plotting functions?  Something involving
> recordPlot and
>  >>> >>> replayPlot?
>  >>> >>>
>  >>> >>> 2.) It would be nice if plotting would automatically open a new
> Emacs
>  >>> >>> buffer displaying the result.  This could perhaps be addressed by
>  >>> >>> scanning each executed command with a regular expression,
> something
>  >>> like
>  >>> >>> (but realistically much more complex than):
>  >>> >>>
>  >>> >>>   (defvar ess-plot-command-regexp "\\bplot(")
>  >>> >>>
>  >>> >>> If it matches, ESS could open the PDF in a new buffer window or
> prompt
>  >>> >>> the user asking whether the PDF should be opened.  Is there
> already
>  >>> >>> infrastructure in ESS for scanning R commands like that?
>  >>> >>>
>  >>> >>> An alternative might be to use gfilenotify/inotify/w32notify to
> inform
>  >>> >>> ESS every time the target PDF changes.  ESS could then prompt the
> user
>  >>> >>> asking whether the plot should be displayed.  This is cleaner
> because
>  >>> >>> detecting plotting commands accurately is at least difficult.
> However
>  >>> >>> the notify solution requires that ESS knows the PDF containing
> the plot
>  >>> >>> but this could be achieved by whatever the solution for issue 1
> is.
>  >>> >>>
>  >>> >>> What are your thoughts on this?  Does the PDF approach sound like
> the
>  >>> >>> way to go?  Any ideas regarding the two issues above?  It would be
>  >>> great
>  >>> >>> to get some feedback on this.
>  >>> >>>
>  >>> >>>   Titus
>  >>> >>>
>  >>> >>> [1] https://github.com/politza/pdf-tools>> >>>
>  >>> >>> ______________________________________________
>  >>> >>> ESS-help using r-project.org mailing list
>  >>> >>> https://stat.ethz.ch/mailman/listinfo/ess-help>> >>>
>  >>> >
>  >>>
>  >>
>  >> [[alternative HTML version deleted]]
>  >>
>  >> ______________________________________________
>  >> ESS-help using r-project.org mailing list
>  >> https://stat.ethz.ch/mailman/listinfo/ess-help
>
>  > ______________________________________________
>  > ESS-help using r-project.org mailing list
>  > https://stat.ethz.ch/mailman/listinfo/ess-help
>

	[[alternative HTML version deleted]]

More information about the ESS-help mailing list