[R-pkg-devel] Svar: Issue with use of par() in package

[Jan van der Laan]

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-bounces using r-project.org> på vegne 
> av Jan van der Laan <rhelp using eoos.dds.nl>
> *Dato: *onsdag, 20. august 2025 kl. 21:32
> *Til: *r-package-devel using r-project.org <r-package-devel using 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel <https:// 
> stat.ethz.ch/mailman/listinfo/r-package-devel>