[ESS] Displaying plots in Emacs

[Michael Lawrence]

Writing out to files is a bit messy but it would surely work, even
remotely, via tramp. That SVG support looks really cool. But it requires
X11. But yea, it would be relatively easy to grab the SVG stream from
Cairo. In fact, using the cairoDevice and RGtk2 packages, one could do this
already in R. All we need is the Mode callback in the R graphics engine, so
that we don't have to dev.off(). I could add that callback to the
cairoDevice package for now, just to experiment.

On Mon, May 18, 2015 at 8:17 PM, Titus von der Malsburg <malsburg using posteo.de>
wrote:

>
> On 2015-05-18 Mon 16:42, Ista Zahn 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.
>
> Pdf-tools uses a separate server process for rendering and it’s
> apparently not possible to pass PDF to this process directly:
> https://github.com/politza/pdf-tools/issues/90
>
> Perhaps DocView mode is better suited for our purpose.  DocView also
> uses external tools for rendering (ghostscript et al.) but I imagine
> that it shouldn’t be too hard to feed those with data from Emacs.
>
> I also saw that Emacs has native support for rendering SVG but I found
> very little documentation and only a simple proof-of-concept demo:
>
> http://www.mail-archive.com/gnu-emacs-sources@gnu.org/msg02056/svg-clock.el
>
> R can produced SVG through the libcairo; perhaps that’s a more promising
> target than PDF?  Either way, if we get the data from R, it should
> somehow be possible to render it.
>
>   Titus
>
> >
> > 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]]