Verbosity

[jennybc]

Should you provide control over verbosity?

At the function level or via some big kill switch?

• Example of function level: devtools::check(quiet = TRUE)
• Example of higher level kill switch: option usethis.quiet affects all of the ui_*() functions

Context: I'm calling check() and install() and test() in .Rmd for R Packages. All of these functions make pretty strong assumptions that they're being run interactively. Such functions are easier to "write prose around" if there are ways to muffle, capture, and redact their output.

I think this might be analogous to format() and print() methods.

[hadley]

I think this is part of function API, connected to other function side-effects (and possibly non-local inputs)

[krlmlr]

What's a good playground to test classed messages that can be muffled safely?

[jimhester]

Conclusions from discussion on 2020-07-12

• Use classed messages rather than function arguments.
• Message should have some sort of package tag on them, or a way to turn off messages from a particular package. Possibly every package above them in the call stack as well?
• Messages should also have levels, analogous to a subset of log4j levels.
• The default level for interactive messages is 'inform'
• 'debug' being equivalent to verbose = TRUE
• The global levels should be able to be set by environment variable and also global R option.
• We would need support for this in rlang::inform() and cli. Maybe a standalone file as well?
  • Jim aside I think we could consider using cli much more universally throughout r-lib, it is pretty lightweight now.
• Have user facing helper to control message level, with_quiet() or similar.
• Need to consider standard function level documentation so users are aware how to modify verbosity.

[jennybc]

Consider masking output-emitters like cat() and message() with a wrapper around stop(), since usage will bypass all the measures taken to implement the above. It's easy for these to creep in, especially from external contributions.