WISH: Make it possible to stack stderr (aka "message") sinks

[HenrikBengtsson]

Issue

In ?sink we can read:

Sink-ing the messages stream should be done only with great care. For that stream file must be an already open connection, and there is no stack of connections.

This prevents us from doing things such as:

> x <- capture.output({
+   message(1)  ## this is captured, but ...
+   y <- capture.output(message(2), type="message")
+   message(3)  ## ... these two message/stderr output
+   message(y)  ## messages are _not_ captured
+ }, type="message")
3
2
> x
[1] "1"

The latter two lines are outputted to the message output, which reopened, because the inner capture resets it to the default when it closes it's redirect.

This is a problem, because it prevents all of us from capturing/sinking standard error output ("messages"). If we attempt to do it, we must be careful to make sure there is not already an active "message" sink, otherwise we will destroy the active one. This makes it very complicated to capture stderr in package code. This is basically also what ?sink tells us:

Do not sink the messages stream unless you understand the source code implementing it and hence the pitfalls.

Actions

Try to find out why the current limitation exists. Is it deliberate - an active design decision - and if so, then exactly why? Or is it just because no one got around to implement a stacked version for the "message" streams?

[HenrikBengtsson]

Asked about this in R-devel thread 'sink(con, type = "message"): what is the reason why 'message' sinks cannot be stacked?', 2018-03-20 (https://stat.ethz.ch/pipermail/r-devel/2018-March/075734.html)

[HenrikBengtsson]

See R-devel thread 'Bug report: parLapply with capture.output(type="message") produces an error' on 2023-10-05 (https://stat.ethz.ch/pipermail/r-devel/2023-October/082936.html) for an example where the lack of stackable "message" sinks is in play.