xquartz hanging

I'm puzzled why you need XQuartz in the first place. R in a terminal usually fires up the quartz() graphics device and that has nothing to do with XQuartz (which is X on top of Quartz, not the other way around).

We do have an annoyance with XQuartz though: When install.packages() goes looking for a CRAN mirror (*), it fires up a Tk selector and that will require XQuartz to fire up. Every now and again that hangs for me too, but as it is usually the first thing I do in an R session, I can ctr-Z and kill the process and start over. But it really could do with a looking into. (I do miss strace/truss from days of yore, where you could just probe into a running process and see what it is up to.)

-pd

(*) Yeah, I know, it should be in a configuration  file ... somewhere.

On 1 Jun 2025, at 00.08,bill+rsigmac at 8pawexpress.com wrote:

Thanks for the feedback, Marc! Very interesting.

On 5/31/25 13:04, Marc Schwartz wrote:

Hi,

I am currently running R 4.5.0 on macOS 15.5 (Sequoia), and I also use emacs (30.1) and ess (25.1.0), the latter from elpa, along with other emacs packages.

It seems we (emacs/ess users) are a diminishing crowd :-(

I do not have the issue that you are referring to below, and did not under prior versions to the best of my recollection.

Then there?s hope :-)

I do tend to stay up to date on the versions of all of the above and do clean installs of R and packages with each new version, fully removing the older version file tree first (/Library/Frameworks/R.framework).

Thus, you might consider updating both macOS and R to current versions.

I had already planned to upgrade to macos-15.5. I?m not able to
upgrade (fully) to R-4.5 in the immediate future ? worse, I need
to have multiple R versions on-hand for some backwards-compatibility
testing (work apps/apis).

I do subscribe occasionally to the ?three-finger salute? way of
fixing some OS or program issues, but I really dislike the fact that
it works much more frequently than I think it should.

I don't use ggplot*, so cannot comment if there may be something specific to that package causing any issues,

|ggplot2| does tend to be more complex and test the graphics device
more than typical base graphics; I recall an issue with ggplot on
windows several years ago that caused the window to dump,
occasionally causing R to dump and crash as well, triggered by a
mouse-wheel action on a ggplot graphics pane. This is not the same
issue, certainly, but speaks to the difference with base graphics.

For the record, while I use it much much less frequently, I have yet
to see the issue appear when a base-graphics plot is displayed. This
is not conclusive.

One thing that you should do, if you have not, is to be sure to re-install XQuartz after upgrading R versions, and this is referenced on the R macOS CRAN page.

The only mentions I can find of XQuartz on the R-Mac pages are:

  * Big Sur and newer require XQuartz 2.8.5 (I?m good, installed 2.8.5
    from the start)
  * ?Always re-install XQuartz when upgrading your macOS to a new
    major version?: not applicable, I?ve been on 15.3 or newer on this
    laptop (unless ? is 15.4 a ?major version? over 15.3?)

Regardless of that, I don?t understand how an xorg-server would be
at all tied to (needing to be reinstalled/relinked after) changes in
a client library (R plotting services). Can you provide more
information (a link) where they say XQuartz needs to be reinstalled
with each R upgrade? I apologize if I?m missing it on mac.r-project.org.

See if re-installing XQuartz has any impact on the issues that you are observing.

Regardless of ?why? it may work, I think I?m going to uninstall and
reinstall XQuartz when I do the macos upgrade. ?It can?t hurt?,
famous last words.

You might also want to fully uninstall XQuartz first, before re-installing it, and the instructions for that are available on their FAQ page:

   https://www.xquartz.org/FAQs.html

Sage advice, I appreciate it.

One additional thing to consider is to try to replicate the behavior that you are observing by running R in Terminal and/or via R.app, to try to exclude the possibility that there is something going on with your emacs/ess installation.

That?s been on my list, but since I still don?t know exactly what
causes it to hang, I have not spent the time trying to repeat it
from outside of my normal R use.

Once thing I find interesting is that it is particular to one R
process, but not to XQuartz. That is, when one R process? graphics
device is hung, I can open a new R process and plotting works
without issue. I can close the first process, eventually its hung
window closes, and other processes continue to plot without issue. I
don?t know if this narrows it down at all, since a bug in either R
or XQuartz could show that specificity. (The major pain is that
often I?m working with many GBs of data, and reloading and
reprocessing is a not-free chore. Usually not impossible, just many
many minutes and reacquiring my mental focus.)

Thanks again for your experience, Marc!

If you can replicate the issues in Terminal and/or R.app, that would help to exclude emacs/ess from involvement at least. If you cannot, then you might be sure that you are running the latest versions of emacs and ess to see if that helps, in case they are adding a source of conflict.

Regards,

Marc Schwartz

On May 31, 2025, at 10:35?AM,bill+rsigmac at 8pawexpress.com wrote:

Are there easy fixes or alternatives to using XQuartz for R plots?

I?m running R-4.4.3 (emacs/ess) on macos 15.4.1 and have xquartz-2.8.5
installed. Most of the time plotting in R works well enough (I tend to
use ggplot2, I don?t know if it happens as often with base plots).
Occasionally (several times a week), ?something? happens with the plot
window, and from then on that R process can no longer plot anything
more. The ?something? is not well defined for me yet, I think it?s a
mouse-wheel or mouse-click or similar; the snark in me says ?well don?t
do that?, but I cannot nail down exactly how/when it breaks, it just does.

When it happens, the current device window is still open, but it has a
mac spinning-colorwheel, no new plotting commands work, and I cannot
close the window myself. I cannot dev.off() it, nor does dev.new() give
me a new plotting window. When this happens for a particular R process,
my only options for plotting are either (a) close the R process and
start over, or (b) manually plot to a PDF or similar one-shot graphics
device, viewing in a different app.

There are several related issues I can find:

https://github.com/XQuartz/XQuartz/issues/431, specific to macos 15.4 or
newer I think; some mention of ?minimizing windows? but I don?t minimize
my plot windows, so perhaps not that
https://github.com/XQuartz/XQuartz/issues/168, closed as ?not planned?,
though this one is much older than the first (431) issue

I?ve tried using something like |httpgd|
<https://github.com/nx10/httpgd/> since it can (mostly) provide an
?always updating graphics device? for example without xquartz.
Unfortunately, with some other packages (namely plumber that I use
frequently-enough) it can put the R?s REPL into an unbreakable state
(#215<https://github.com/nx10/httpgd/issues/215>). If that were fixed
I?d be a lot more comfortable using that as my workaround.

My research has not shown any other options for fixing or replacing
xquartz with a more stable solution. Are there good ways to troubleshoot
and try to fix the xquartz issue? Does anybody else have a workaround or
alternative that is less unwieldy than pdf(..); plot(..); dev.off()?

Thanks,
Bill

&#8203;
&#8203;
[[alternative HTML version deleted]]

​
[[alternative HTML version deleted]]

Thank you, Peter. I think that?s a misunderstanding of mine based on
mis-reading mac.r-project.org and incomplete research. I have since
uninstalled XQuartz and indeed |quartz()| still works, so my bug-report
has been a misdirection. With this, I?ve changed the here from ?xquartz
hanging? to ?quartz hanging?.

I?m still working on a reprex, haven?t found the culprit yet. (I haven?t
had a repeat since I uninstalled and reinstalled then uninstalled XQuartz.)

Thank you again,
Bill

On 6/1/25 07:24, peter dalgaard wrote:

I'm puzzled why you need XQuartz in the first place. R in a terminal

usually fires up the quartz() graphics device and that has nothing to do
with XQuartz (which is X on top of Quartz, not the other way around).

We do have an annoyance with XQuartz though: When install.packages()

goes looking for a CRAN mirror (*), it fires up a Tk selector and that will
require XQuartz to fire up. Every now and again that hangs for me too, but
as it is usually the first thing I do in an R session, I can ctr-Z and kill
the process and start over. But it really could do with a looking into. (I
do miss strace/truss from days of yore, where you could just probe into a
running process and see what it is up to.)

-pd

(*) Yeah, I know, it should be in a configuration  file ... somewhere.

On 1 Jun 2025, at 00.08,bill+rsigmac at 8pawexpress.com wrote:

Thanks for the feedback, Marc! Very interesting.

On 5/31/25 13:04, Marc Schwartz wrote:

Hi,

I am currently running R 4.5.0 on macOS 15.5 (Sequoia), and I also use

emacs (30.1) and ess (25.1.0), the latter from elpa, along with other emacs
packages.

It seems we (emacs/ess users) are a diminishing crowd :-(

I do not have the issue that you are referring to below, and did not

under prior versions to the best of my recollection.

Then there?s hope :-)

I do tend to stay up to date on the versions of all of the above and

do clean installs of R and packages with each new version, fully removing
the older version file tree first (/Library/Frameworks/R.framework).

Thus, you might consider updating both macOS and R to current versions.

I had already planned to upgrade to macos-15.5. I?m not able to
upgrade (fully) to R-4.5 in the immediate future ? worse, I need
to have multiple R versions on-hand for some backwards-compatibility
testing (work apps/apis).

I do subscribe occasionally to the ?three-finger salute? way of
fixing some OS or program issues, but I really dislike the fact that
it works much more frequently than I think it should.

I don't use ggplot*, so cannot comment if there may be something

specific to that package causing any issues,

|ggplot2| does tend to be more complex and test the graphics device
more than typical base graphics; I recall an issue with ggplot on
windows several years ago that caused the window to dump,
occasionally causing R to dump and crash as well, triggered by a
mouse-wheel action on a ggplot graphics pane. This is not the same
issue, certainly, but speaks to the difference with base graphics.

For the record, while I use it much much less frequently, I have yet
to see the issue appear when a base-graphics plot is displayed. This
is not conclusive.

One thing that you should do, if you have not, is to be sure to

re-install XQuartz after upgrading R versions, and this is referenced on
the R macOS CRAN page.

The only mentions I can find of XQuartz on the R-Mac pages are:

  * Big Sur and newer require XQuartz 2.8.5 (I?m good, installed 2.8.5
    from the start)
  * ?Always re-install XQuartz when upgrading your macOS to a new
    major version?: not applicable, I?ve been on 15.3 or newer on this
    laptop (unless ? is 15.4 a ?major version? over 15.3?)

Regardless of that, I don?t understand how an xorg-server would be
at all tied to (needing to be reinstalled/relinked after) changes in
a client library (R plotting services). Can you provide more
information (a link) where they say XQuartz needs to be reinstalled
with each R upgrade? I apologize if I?m missing it on mac.r-project.org

.

See if re-installing XQuartz has any impact on the issues that you are

observing.

Regardless of ?why? it may work, I think I?m going to uninstall and
reinstall XQuartz when I do the macos upgrade. ?It can?t hurt?,
famous last words.

You might also want to fully uninstall XQuartz first, before

re-installing it, and the instructions for that are available on their FAQ
page:

   https://www.xquartz.org/FAQs.html

Sage advice, I appreciate it.

One additional thing to consider is to try to replicate the behavior

that you are observing by running R in Terminal and/or via R.app, to try to
exclude the possibility that there is something going on with your
emacs/ess installation.

That?s been on my list, but since I still don?t know exactly what
causes it to hang, I have not spent the time trying to repeat it
from outside of my normal R use.

Once thing I find interesting is that it is particular to one R
process, but not to XQuartz. That is, when one R process? graphics
device is hung, I can open a new R process and plotting works
without issue. I can close the first process, eventually its hung
window closes, and other processes continue to plot without issue. I
don?t know if this narrows it down at all, since a bug in either R
or XQuartz could show that specificity. (The major pain is that
often I?m working with many GBs of data, and reloading and
reprocessing is a not-free chore. Usually not impossible, just many
many minutes and reacquiring my mental focus.)

Thanks again for your experience, Marc!

If you can replicate the issues in Terminal and/or R.app, that would

help to exclude emacs/ess from involvement at least. If you cannot, then
you might be sure that you are running the latest versions of emacs and ess
to see if that helps, in case they are adding a source of conflict.

Regards,

Marc Schwartz

On May 31, 2025, at 10:35?AM,bill+rsigmac at 8pawexpress.com wrote:

Are there easy fixes or alternatives to using XQuartz for R plots?

I?m running R-4.4.3 (emacs/ess) on macos 15.4.1 and have xquartz-2.8.5
installed. Most of the time plotting in R works well enough (I tend to
use ggplot2, I don?t know if it happens as often with base plots).
Occasionally (several times a week), ?something? happens with the plot
window, and from then on that R process can no longer plot anything
more. The ?something? is not well defined for me yet, I think it?s a
mouse-wheel or mouse-click or similar; the snark in me says ?well

don?t

do that?, but I cannot nail down exactly how/when it breaks, it just

does.

When it happens, the current device window is still open, but it has a
mac spinning-colorwheel, no new plotting commands work, and I cannot
close the window myself. I cannot dev.off() it, nor does dev.new()

give

me a new plotting window. When this happens for a particular R

process,

my only options for plotting are either (a) close the R process and
start over, or (b) manually plot to a PDF or similar one-shot graphics
device, viewing in a different app.

There are several related issues I can find:

https://github.com/XQuartz/XQuartz/issues/431, specific to macos

15.4 or

newer I think; some mention of ?minimizing windows? but I don?t

minimize

my plot windows, so perhaps not that
https://github.com/XQuartz/XQuartz/issues/168, closed as ?not

planned?,

though this one is much older than the first (431) issue

I?ve tried using something like |httpgd|
<https://github.com/nx10/httpgd/> since it can (mostly) provide an
?always updating graphics device? for example without xquartz.
Unfortunately, with some other packages (namely plumber that I use
frequently-enough) it can put the R?s REPL into an unbreakable state
(#215<https://github.com/nx10/httpgd/issues/215>). If that were fixed
I?d be a lot more comfortable using that as my workaround.

My research has not shown any other options for fixing or replacing
xquartz with a more stable solution. Are there good ways to

troubleshoot

and try to fix the xquartz issue? Does anybody else have a workaround

or

alternative that is less unwieldy than pdf(..); plot(..); dev.off()?

Thanks,
Bill

​
​
[[alternative HTML version deleted]]

​
[[alternative HTML version deleted]]

​
        [[alternative HTML version deleted]]