alternative solution to using `ggMarginal` in R Markdown or Notebook files

[Indrajeet Patil]

I use ggMarginal function in my package and one of the issues that keep popping up is that the users get confused that running code chunk doesn't return a plot (e.g., this issue).

I know that README mentions how to do this (and I've included a similar paragraph in my README), but this solution is not beginner-friendly and I am worried that people will form a habit of avoiding using this function.

So I was wondering if there are any alternative solutions I can implement in the backdrop to get around this problem so that the user needs to only run code chunk and do nothing else.

Thanks for consideration.

[Indrajeet Patil]

Can knit_print be of any utility here?

https://cran.r-project.org/web/packages/knitr/vignettes/knit_print.html

[Chris Baker]

Hi @IndrajeetPatil , I messed around with knit_print and couldn't get anything going. I also tried looking into alternatives to ggMarginal's current print method that would make it behave nicer in Rmarkdown docs, also to no avail. This may be a fixable issue, but I don't think I could do it without getting far into the internals of knitr.

[Dean Attali]

@IndrajeetPatil You can see some information about showing ggmarginal in notebooks in this issue #89

One thing that might work for you is whenever you make the function call to print the plot, instead of calling print(p), you can use print(p, newpage = TRUE) (assuming p is a ggmarginal object)

[Indrajeet Patil]

@daattali Those solutions still require extra effort on the part of the user and that's exactly what I am trying to avoid.

Pretty much anyone who uses ggplot2 or any of its extensions packages expect that just running the go button for the RMarkdwon chunk will render the plot and ggExtra might just be the only exception to this rule. So the natural inference the users draw when this doesn't work for ggExtra plots is either that the package/function not working or that this is a bug, none of which is true.

This is why I am trying to push the burden to developer side and find a solution (either in ggExtra or in rmarkdown or in RStudio) that will make working with ggExtra plots in R Markdown similar to working with ggplot2 plots.

[Dean Attali]

I didn't mean the end user would do anything. I was suggesting perhaps your function in ggstatsplot could be explicit about printing ggmarginal.

[Indrajeet Patil]

Ah, I see.

I had considered this option but just printing the plot to a device makes it difficult to do anything further with them. Often, you want to combine two of such plots together and that wouldn't work with this approach.

library(ggplot2)
library(ggExtra)

plot <- ggplot(mtcars, aes(mpg, wt)) + geom_point()

gg_fun1 <- function(p) {
  return(ggMarginal(p))
}

gg_fun2 <- function(p) {
  print(ggMarginal(p))
}

class(gg_fun1(plot))
#> [1] "ggExtraPlot" "gtable"      "gTree"       "grob"        "gDesc"

class(gg_fun2(plot))

#> [1] "NULL"

cowplot::plot_grid(gg_fun1(plot), gg_fun1(plot), labels = c("a", "b"))

cowplot::plot_grid(gg_fun2(plot), gg_fun2(plot), labels = c("a", "b"))

^{Created on 2019-08-13 by the reprex package (v0.3.0)}

[Dean Attali]

Yes that's true. I'm not sure how this can be avoided, but you're welcome to look at the source code and submit a fix if you think one exists. We use a lot of gtable to build the plot, so it's something to do with gtable getting printed to graphics devices. I'm not an expert in this, but if you have some knowledge with these packages perhaps you'll see how this can be fixed

[Chris Baker]

I think I have a solution. Give me a few days and I'll submit something.

[Chris Baker]

K so it turns out that my fix has a problem. A leading blank page will appear when the user runs the code interactively (i.e., when pressing the "run current chunk" button). This blank page only appears the first few times in a given RStudio session (sometimes the blank page disappears on the second run, other times on the third). I'm not sure what exactly is going on, but I think it has something to do with tidyverse/ggplot2#809 and https://stackoverflow.com/questions/17012518/why-does-this-r-ggplot2-code-bring-up-a-blank-display-device/17013882#17013882 (note that I wasn't able to implement the workaround that was suggested in that github issue). A leading blank page isn't produced when drawing on non-interactive devices, or when the user knits the entire RMarkdown doc.

Do you think it's worth incorporating this fix, or does the confusion of having the leading blank page outweigh the benefit of not requiring two separate chunks to render ggmarginal plots?

[Dean Attali]

Thanks for all the work and investigation! Since you mention the word "interactively" - would this be solved by checking for interactive()? Or am I being way too naive?

[Indrajeet Patil]

@crew102 Thanks a bunch for the sleuth work to find an alternative solution!

This solution would definitely work for me - I doubt the users will think that the function did not work when they can clearly see the output.

[Chris Baker]

Checking for whether the code is run interactively or in an R Markdown chunk is indeed part of the solution, but that alone doesn't fix the leading blank page. I fooled around with different arrangements of using grid.newpage() and grid.draw(), and nothing seemed to get rid of the leading blank page.

I'll open up a PR and we can discuss further there if need be.