[ESS] Displaying plots in Emacs

[Michael Lawrence]

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.

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