`rlang::inform()` messages should conform to `base::message()`

[lionel-]

Unlike warning() and stop(), base::message() has an appendLF argument that is TRUE by default. This causes it to create conditions that include an explicit rather than implicit trailing line feed.

# Explicit line feed
conditionMessage(rlang::catch_cnd(message("foo")))
#> [1] "foo\n"

# Implicit line feed
conditionMessage(rlang::catch_cnd(warning("foo")))
#> [1] "foo"

rlang::inform(), which is called by cli::cli_inform(), doesn't have this behaviour. It creates condition messages with an implicit trailing line feed, just like other condition emitters:

conditionMessage(rlang::catch_cnd(rlang::inform("foo")))
#> [1] "foo"

In hindsight this was a bad choice for rlang to take. While it makes the conditionMessage() API more uniform, it creates an ambiguity as to whether a message condition does or does not include an implicit trailing line feed. Because of this, a global handler that bypasses the default handling (output to stdout/stderr) in base::message() and rlang::inform() can't determine if a message should or should not have a line feed appended to the message. It would be better for all message conditions to have that explicit trailing "\n".

This is especially bad with cli messages passed from subprocesses through callr. They inherit from "message" and implement the explicit trailing linefeed approach, which is necessary for updating status lines in place with ansi escapes.

[lionel-]

Does that make sense to you @gaborcsardi?

[gaborcsardi]

Yes, I agree that it would have been better the other way, but can we really change it at this point? It will break a lot of things, no?

[lionel-]

I'm hoping that rlang messages are primarily emitted and handled (converted to stdout/stderr output) from rlang, so that would contain the breaking change. I agree there is a risk of fallout to other places though, e.g. testthat.