[ESS] Displaying plots in Emacs

Michael Lawrence lawrence.michael at gene.com
Tue May 19 06:30:37 CEST 2015 

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.

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

>
> I looked into DocView and saw that it communicates with ghostscript via
> files.  Interestingly the ghostscript documentation says:
>
>   The PDF language, unlike the PostScript language, inherently requires
>   random access to the file. If you provide PDF to standard input using
>   the special filename '-', Ghostscript will copy it to a temporary file
>   before interpreting the PDF.
>
> So if we work with PDF the data will sooner or later hit the disk.  I
> don’t have a problem with that but if there are reasons to avoid it, the
> SVG route might be better because SVG is rendered in Emacs as far as I
> can tell.
>
>   Titus
>
> On 2015-05-18 Mon 20:36, Michael Lawrence wrote:
> > 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 at 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 at 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 at stat.math.ethz.ch
> >> >>> wrote:
> >> >>
> >> >>> On Mon, May 18, 2015 at 8:01 PM, Titus von der Malsburg
> >> >>> <malsburg at 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 at 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 at r-project.org mailing list
> >> >>> >>> https://stat.ethz.ch/mailman/listinfo/ess-help
> >> >>> >>>
> >> >>> >
> >> >>>
> >> >>
> >> >>         [[alternative HTML version deleted]]
> >> >>
> >> >> ______________________________________________
> >> >> ESS-help at r-project.org mailing list
> >> >> https://stat.ethz.ch/mailman/listinfo/ess-help
> >> >
> >> > ______________________________________________
> >> > ESS-help at 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