Hi Kristian,

Also replying to the list.

Thanks for the suggestion. Personally I have something like the following in my ~/.Rprofile

if (interactive() && terminalgraphics::has_tgp_support()) {
  options(device = terminalgraphics::tgp)
}

So that doesn't work well with your suggestion, but creating a (have to think of a better name) `get_par` function, might at least make it easier for the user to set the colors when it turns out to be impossible to set these from tgp():

tgp()
opar <- par(terminalgraphics::get_par())
plot(...)
par(opar)

`get_par` would then be similar to what you suggest. The disadvantage is that this code is only relevant when `tgp` is the active device, so users would need to either write device specific code or wrap this in if-statements. Perhaps a better solution would be to allow for a user defined callback to `tgp` that is called after the device is created. A user might then be able to do something like:

if (interactive() && terminalgraphics::has_tgp_support()) {
  set_par <- function() par(terminalgraphics::get_par())
  options(device = terminalgraphics::tgp, tgp_callback = set_par)
}

This is still extra work for the user, but avoids device specific code in the user scripts.

Thanks again.

Jan







On 8/21/25 08:35, Kristian Hovde Liland wrote:
Hi Jan,

I’m not sure how this plays with your point 3, if the intention is subsequent automatic updates, but for setting the colours once, you could let the user perform the par() part, for instance:
tgp <- function(...){
   # All the nice things that are needed.
   # <- here
   # Output in the form of a vector to be passed to par, e.g.,
   vec <- c(bg = "black",
            fg = "white",
            col.axis = "white",
            col.lab = "white",
            col.main = "white",
            col.sub = "white")
   return(vec)
}
# Example
old.par <- par(tgp()) # <- User involvement
plot(1:3, type="l")
par(old.par)

Regards,
Kristian

*Fra: *R-package-devel <r-package-devel-boun...@r-project.org> på vegne av Jan van der Laan <rh...@eoos.dds.nl>
*Dato: *onsdag, 20. august 2025 kl. 21:32
*Til: *r-package-devel@r-project.org <r-package-devel@r-project.org>
*Emne: *[R-pkg-devel] Issue with use of par() in package


I recently submitted a package to CRAN that creates a device that
outputs into the terminal (for terminals that support the Terminal
Graphics Protocol (and hopefully in the future also terminals that
support sixel)) [1].

It introduces a 'tgp' function that does the following:

1. It opens a ragg::agg_capture device.

2. When term_col = TRUE: sets the background and foreground colors of
the device to those of the terminal (when these can be detected).

3. Every time the ragg:agg_capture device is updated: updates the plot
in the terminal.

Point 2 raises an issue from CRAN as par() changes some properties and
these are not set back at the and of the function call. This is
intentional, as otherwise setting them would be useless; it is the
intention that the colors of subsequent plot calls are changed.  I am
not sure how I can set the colors of the device to those in the terminal
(as requested by the user) without violating this rule.

Are there alternative ways of helping the user to set the colors of the
device without violating this issue?

Could this be an exception to the rule as the argument intentionally
changes par()? This could be made more explicit by changing the default
value to FALSE. I guess this question is better asked at the CRAN
maintainers, but perhaps there are other package that do something
similar that I might look at.

Instead of having this functionality in the tgp() function, I could
create a 'set_figure_colours_to_terminal()` function (perhaps with a
corresponding reset function). However, this function would run into the
same issue.

I appreciate any suggestions/help that yoy could give.

Best,
Jan




[1] The current version of the code can be found here:
https://codeberg.org/djvanderlaan/terminalgraphics/src/branch/dev <https://codeberg.org/djvanderlaan/terminalgraphics/src/branch/dev>

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel <https:// stat.ethz.ch/mailman/listinfo/r-package-devel>

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to