You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
Unlike
warning()
andstop()
,base::message()
has anappendLF
argument that isTRUE
by default. This causes it to create conditions that include an explicit rather than implicit trailing line feed.rlang::inform()
, which is called bycli::cli_inform()
, doesn't have this behaviour. It creates condition messages with an implicit trailing line feed, just like other condition emitters: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) inbase::message()
andrlang::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.The text was updated successfully, but these errors were encountered: