[ESS] Displaying plots in Emacs

[Michael Lawrence]

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.

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