Restyling wrapped strings

[krlmlr]

strwrap_ctl() appears to add escape sequences that clear style. This has led to weird printing in tibble.

What's the reason for adding \033[0m and \033[1m before and after newlines? What breaks if these sequences are omitted? Could strwrap_ctl() be more careful about inserting the "right" escape sequences at EOL?

The output of the first example, sent to cat(), looks great in both RStudio and in my terminal.

I have worked around in tibble, this may be too much of a corner case to worry about at all. For now we could add something like this to the documentation:

The output of strwrap_ctl() is intended to use "as is", because each line ends with a sequence that turns off all formatting applied previously. If you intend to apply further formatting to the wrapped output, make sure to apply the formatting to each line individually, and not to the entire result collapsed by e.g. paste(..., collapse = "\n").

library(fansi)
library(crayon)

options(crayon.enabled = TRUE)

split <- function(x) {
  unlist(strsplit(x, "\n", fixed = TRUE))
}

collapse <- function(x) {
  paste(x, collapse = "\n")
}

split(green(bold("xxx\nyyy")))
#> [1] "\033[32m\033[1mxxx"  "yyy\033[22m\033[39m"
split(green(collapse(strwrap_ctl(bold("xxx yyy"), width = 4))))
#> [1] "\033[32m\033[1mxxx\033[0m"  "\033[1myyy\033[22m\033[39m"
split(green(collapse(strwrap2_ctl(bold("xxx yyy"), width = 4))))
#> [1] "\033[32m\033[1mxxx\033[0m"  "\033[1myyy\033[22m\033[39m"

^{Created on 2020-03-28 by the reprex package (v0.3.0)}

Follow-up to tidyverse/tibble#574 (comment).

[brodieG]

I do agree that at a minimum this should be clearly documented.

IIRC I add the "\033[m" for two reasons. First weird things happen when you start adding newlines in the middle of SGR formatted strings:

This is actually failing in a different way than I remember last where IIRC the color bled past the newline, not the last line.

Additionally, what is the desired outcome of:

writeLines(paste("| ", strwrap_ctl("\033[42mhello world\033[m", 5), " |"))

Without the closing escape the green would just bleed out. I think you could make the case for that being the correct outcome, but I find it less useful. A big use case of strwrap_ctl is to make narrower text column that can then be pasted with other text columns with or without formatting, and prevent the formatting from cross contaminating across columns. We can't just direct the user to manually add closing escapes between columns because they also need to resume the color for the column on the next line. Having completely self encapsulated lines as strwrap_ctl produces makes it easy to combine columns.

Note that the additional "\033[1m" you ask about is the resumption of the bolding in the subsequent line.

I think part of the problem is that the crayon model tries to mimic XML-like nested semantics (i.e. green(xxx) -> <span style='color: green'>xxx</span>) when in reality ANSI CSI SGR is a state based system so the metaphor and the expectations that come with it fails in cases like these. IIRC crayon does quite a bit internally to try to perpetuate the illusion.

We could try to be more selective in how we terminate the lines, i.e. instead of terminating all styles we can just terminate the styles that are known to be active, but that will require messing with C code that allocates memory for strings, which is not too bad but not something I'm particularly eager to do at the moment. I think if we do this crayon styles will have a better chance of applying as expected. Another option is for crayon to recognize "\033[m" and do the same thing it does for "\033[39m" and similar. This is probably less work (though still some) and if deemed important enough I could submit a PR to crayon.

[brodieG]

Thinking about this more I think the "right" solution is to have fansi terminate only the active styles, and not all styles. Then at least crayon will behave more as expected. There might be some issues with some styles that don't have explicit terminators (and I think that's part of the reason I use \033[m, but I think those are rare).

[brodieG]

strtrim_ctl relies on strwrap_ctl, so two birds with one stone on that one.

substr_ctl does the termination in R, so we may need an interface to the closing string determination code for that. strsplit_ctl relies on substr_ctl (although it also has dormant C code).

Update: unfortunately I ran out of time due to a CRAN Fix or Else deadline, so this will have to wait for next release.

[brodieG]

@krlmlr I put in an experimental solution in the development branch:

normalize takes all SGR sequences and decomposes them into the simplest form, which then makes them compatible with crayon. Most fansi functions gain the normalize parameter, but there is also normalize_sgr which takes any arbitrary string and normalizes the SGR sequences in it, e.g.:

> normalize_sgr("\033[4;44mhello\033[mworld")
[1] "\033[4m\033[44mhello\033[24m\033[49mworld"

@gaborcsardi, this might be of interest as it makes it possible to combine arbitrary SGR strings with crayon, and not just those that are generated by crayon or programs that are careful to always pair the opening sequence with the corresponding closing one.

This is still a bit experimental and probably won't make it onto CRAN for a few weeks, so if you have any feedback let me know.