Unescaped newline causes an error when `.code` format is applied
Hi,
I have a user-supplied string that I want to feed cli_bullets(), but it seems to cause a bug if 2 conditions are met:
- the string contains an unescaped newline
\n, or sometimes\f - the
.codeformat is applied
Here is a reprex:
Sys.setenv(LANGUAGE = "en")
cli::cli_bullets("\n")
#>
cli::cli_bullets("foo \n bar")
#> foo bar
cli::cli_bullets("{.code \n}")
#> ``
cli::cli_bullets("{.code foo \n bar}")
#> Error in vapply(X, FUN, FUN.VALUE = character(1), ..., USE.NAMES = USE.NAMES): values must be length 1,
#> but FUN(X[[1]]) result is length 2
cli::cli_bullets("{.code foo \r bar}")
#> `foo bar`
cli::cli_bullets("{.code foo \f bar}")
#> `foo
#> bar`
cli::cli_abort("{.code foo \f bar}") #weird...
#> Error in vapply(X, FUN, FUN.VALUE = character(1), ..., USE.NAMES = USE.NAMES): values must be length 1,
#> but FUN(X[[1]]) result is length 2
Created on 2022-07-07 by the reprex package (v2.0.1)
Session info
sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#> setting value
#> version R version 4.2.1 (2022-06-23 ucrt)
#> os Windows 10 x64 (build 19043)
#> system x86_64, mingw32
#> ui RTerm
#> language en
#> collate French_France.utf8
#> ctype French_France.utf8
#> tz Europe/Paris
#> date 2022-07-07
#> pandoc 2.18 @ C:/Program Files/RStudio/bin/quarto/bin/tools/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#> package * version date (UTC) lib source
#> cli 3.3.0 2022-04-25 [1] CRAN (R 4.2.0)
#> crayon 1.5.1 2022-03-26 [1] CRAN (R 4.2.0)
#> digest 0.6.29 2021-12-01 [1] CRAN (R 4.2.0)
#> ellipsis 0.3.2 2021-04-29 [1] CRAN (R 4.2.0)
#> evaluate 0.15 2022-02-18 [1] CRAN (R 4.2.0)
#> fansi 1.0.3 2022-03-24 [1] CRAN (R 4.2.0)
#> fastmap 1.1.0 2021-01-25 [1] CRAN (R 4.2.0)
#> fs 1.5.2 2021-12-08 [1] CRAN (R 4.2.0)
#> glue 1.6.2 2022-02-24 [1] CRAN (R 4.2.0)
#> highr 0.9 2021-04-16 [1] CRAN (R 4.2.0)
#> htmltools 0.5.2 2021-08-25 [1] CRAN (R 4.2.0)
#> knitr 1.39 2022-04-26 [1] CRAN (R 4.2.0)
#> lifecycle 1.0.1 2021-09-24 [1] CRAN (R 4.2.0)
#> magrittr 2.0.3 2022-03-30 [1] CRAN (R 4.2.0)
#> pillar 1.7.0 2022-02-01 [1] CRAN (R 4.2.0)
#> pkgconfig 2.0.3 2019-09-22 [1] CRAN (R 4.2.0)
#> purrr 0.3.4 2020-04-17 [1] CRAN (R 4.2.0)
#> R.cache 0.15.0 2021-04-30 [1] CRAN (R 4.2.0)
#> R.methodsS3 1.8.1 2020-08-26 [1] CRAN (R 4.2.0)
#> R.oo 1.24.0 2020-08-26 [1] CRAN (R 4.2.0)
#> R.utils 2.11.0 2021-09-26 [1] CRAN (R 4.2.0)
#> reprex 2.0.1 2021-08-05 [1] CRAN (R 4.2.0)
#> rlang 1.0.3 2022-06-27 [1] CRAN (R 4.2.1)
#> rmarkdown 2.14 2022-04-25 [1] CRAN (R 4.2.0)
#> rstudioapi 0.13 2020-11-12 [1] CRAN (R 4.2.0)
#> sessioninfo 1.2.2 2021-12-06 [1] CRAN (R 4.2.0)
#> stringi 1.7.6 2021-11-29 [1] CRAN (R 4.2.0)
#> stringr 1.4.0 2019-02-10 [1] CRAN (R 4.2.0)
#> styler 1.7.0 2022-03-13 [1] CRAN (R 4.2.0)
#> tibble 3.1.7 2022-05-03 [1] CRAN (R 4.2.0)
#> utf8 1.2.2 2021-07-24 [1] CRAN (R 4.2.0)
#> vctrs 0.4.1 2022-04-13 [1] CRAN (R 4.2.0)
#> withr 2.5.0 2022-03-03 [1] CRAN (R 4.2.0)
#> xfun 0.31 2022-05-10 [1] CRAN (R 4.2.0)
#> yaml 2.3.5 2022-02-21 [1] CRAN (R 4.2.0)
#>
#> [1] C:/Users/Dan/AppData/Local/R/win-library/4.2
#> [2] C:/Program Files/R/R-4.2.1/library
#>
#> ──────────────────────────────────────────────────────────────────────────────
I tried some other formats with no error, and escaping the newline (\\n) removes the error.
I'm not 100% sure what the expected output would be: more likely the \n as is since it is a code output, but it also could be the \n as a space like when there is no format.
Regardless, the error is not really informative and should probably be handled, with a nicer message.
We can have a better error message, but I am not sure if we will support \n in inline styles.
Supporting \n would not be very useful indeed, but don't you think that simply removing them (just like without .code) would be doable?
Sorry, it seems that I badly searched before posting, this issue is a duplicate of https://github.com/r-lib/cli/issues/417. The other is older but there are a few more examples here so please close the one you want.
I think this is a duplicate of #417