[ESS] Displaying plots in Emacs

[Ista Zahn]

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