Cannot arrange multiple R plots in same plotting space with par

[timtmok]

Positron Version:

Positron Version: 2024.06.0 (Universal) build 770
Code - OSS Version: 1.90.0
Commit: 5d79ea6
Date: 2024-06-14T05:53:04.122Z
Electron: 29.4.0
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 23.4.0

R 4.4.0

Steps to reproduce the issue:

1. Run reprex

Reprex:

par(mfrow=c(3,1))

hist(iris$Petal.Width [iris$Species == "setosa"],
     xlim = c(0,3),
     breaks = 9,
     main = "Petal Width for Setosa",
     xlab = "",
     col = "red")

hist(iris$Petal.Width [iris$Species == "virginica"],
     xlim = c(0,3),
     breaks = 9,
     main = "Petal Width for Virginica",
     xlab = "",
     col = "green")

hist(iris$Petal.Width [iris$Species == "versicolor"],
     xlim = c(0,3),
     breaks = 9,
     main = "Petal Width for Versicolor",
     xlab = "",
     col = "blue")

par(mfrow=c(1,1)) # reset layout

This usually happens in RStudio if the plots pane is too small. Enlarging the plots view in Positron doesn't seem to help. Using par(mfrow=c(1,3)) does work if the plots view is wide enough but doesn't always update to show the last plot. It does fail if setting a custom plot size of 100x100. A larger custom plot size still has an error with the reprex.

What did you expect to happen?

All three plots render in the same plotting space like this:

Were there any error messages in the output or Developer Tools console?

Error in `plot.new()`:
! figure margins too large
Hide Traceback
    ▆
 1. ├─graphics::hist(...)
 2. └─graphics::hist.default(...)
 3.   ├─base::plot(...)
 4.   └─graphics:::plot.histogram(...)
 5.     └─graphics::plot.new()

[jmcphers]

Reported today by a beta user: https://github.com/posit-dev/positron-beta/discussions/222

[edzer]

I think this is related:

plt2 = function() {
  layout(matrix(1:2, 2))
  plot(1,1)
  plot(1,1)
}
plt2()

gives an error:

Error in `plot.new()`:
! figure margins too large

although this works in base R and Rstudio. It prevents plotting maps in packages sf and terra.

[chad-fisher]

I'm also seeing this issue when I try to make a bunch of histograms in the same figure using mfrow. I'm still pretty new to all this so let me know if you need my code or anything, but I've confirmed it behaves as expected in RMD in RStudio but not in Positron

[jmcphers]

Reported again in #4582.

[arnaldmarcer]

Yes, I reported #4582. Here is the plot I get to the code

par(mfrow=c(1,2))
plot(rnorm(100))
plot(rnorm(1000))

No error, just second plot is not shown although the space for it is there. Also, doesn´t get solved by resizing the plot area.

[arnaldmarcer]

Just discovered this which might help. It is the last plot that is not shown. For instance, by doing

par(mfrow=c(1,3))
plot(rnorm(10))
plot(rnorm(100))
plot(rnorm(1000))

only the last one is not shown.

Same here:

par(mfrow=c(2,2))
plot(rnorm(10))
plot(rnorm(100))
plot(rnorm(1000))
plot(rnorm(10000))

Hope this helps

[grantmcdermott]

Interestingly, when I use tinyplot to compose multiplot arrangements, things work fine. E.g. This chunk produces the equivalent result to @timtmok's original post (and displays correctly in Positron's PLOTS pane).

library(tinyplot)

plt(
  ~ Petal.Width | Species,
  data       = iris,
  type       = 'hist',
  facet      = 'by',  # facet along "by" grouping varible (here: Species)
  facet.args = list(ncol = 1),
  legend     = FALSE,
  frame      = FALSE  # optional
)

The reason I bring this up is that it suggests (to me, at least) that the figure margins to large error is possibly a misnomer. What tinyplot does internally is open the plot window with plot.new, then draw common main and axes titles in the outer plot margins, and then use mfrow to draw the individual "facets" in the remaining space (i.e., after accounting for outer margins). So it's basically the same process as the manual approach, but has somehow tricked Positron into thinking there is enough space to draw everything.

(Legends are another issue because of internal margin (i.e., par("mar")) adjustments, but that is being tracked separately in #3667.)