[ESS] Displaying plots in Emacs
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Tue May 19 00:55:45 CEST 2015
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:
>> 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.
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!
>> On Fri, May 15, 2015 at 12:30 PM, Titus von der Malsburg <malsburg using posteo.de
>>> 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 . (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:
>>> instead of just:
>>> 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
>>> 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.
>>>  https://github.com/politza/pdf-tools
>>> ESS-help using r-project.org mailing list
More information about the ESS-help