[ESS] Displaying plots in Emacs
Vitalie Spinu
spinuvit at gmail.com
Tue May 19 05:58:56 CEST 2015
I don't think there will ever be image support as part of ESS. ESS just
cannot handle that sort of complexity. If image handling is ever added
to it it's bound to be an ad hoc and patchy solution.
On the other hand nREPL will work from the start with inline images,
that's sort of things that MPI's are perfect for. "evaluate" pacakge
already handles image recording quite well. So, basic pieces are there,
someone has to put them together.
I am 90% of the time on remotes and each time I need to plot something
complex I have to take a coffee break. If something, like saving to
files, works only on local machines it's not even worth trying
implementing IMO.
Vitalie
>>> Ista Zahn on Mon, 18 May 2015 19:42:02 -0400 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.
> 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
More information about the ESS-help
mailing list