Removes any whitespace before the first and/or after the last non-Control
Sequence character. Unlike with the base::trimws, only the default
whitespace specification is supported.
Usage
trimws_ctl(
x,
which = c("both", "left", "right"),
whitespace = "[ \t\r\n]",
warn = getOption("fansi.warn", TRUE),
term.cap = getOption("fansi.term.cap", dflt_term_cap()),
ctl = "all",
normalize = getOption("fansi.normalize", FALSE)
)Arguments
- x
a character vector.
- which
a character string specifying whether to remove both leading and trailing whitespace (default), or only leading (
"left") or trailing ("right"). Can be abbreviated.- whitespace
must be set to the default value, in the future it may become possible to change this parameter.
- warn
TRUE (default) or FALSE, whether to warn when potentially problematic Control Sequences are encountered. These could cause the assumptions
fansimakes about how strings are rendered on your display to be incorrect, for example by moving the cursor (see?fansi). At most one warning will be issued per element in each input vector. Will also warn about some badly encoded UTF-8 strings, but a lack of UTF-8 warnings is not a guarantee of correct encoding (usevalidUTF8for that).- term.cap
character a vector of the capabilities of the terminal, can be any combination of "bright" (SGR codes 90-97, 100-107), "256" (SGR codes starting with "38;5" or "48;5"), "truecolor" (SGR codes starting with "38;2" or "48;2"), and "all". "all" behaves as it does for the
ctlparameter: "all" combined with any other value means all terminal capabilities except that one.fansiwill warn if it encounters SGR codes that exceed the terminal capabilities specified (seeterm_cap_testfor details). In versions prior to 1.0,fansiwould also skip exceeding SGRs entirely instead of interpreting them. You may add the string "old" to any otherwise validterm.capspec to restore the pre 1.0 behavior. "old" will not interact with "all" the way other valid values for this parameter do.- ctl
character, which Control Sequences should be treated specially. Special treatment is context dependent, and may include detecting them and/or computing their display/character width as zero. For the SGR subset of the ANSI CSI sequences, and OSC hyperlinks,
fansiwill also parse, interpret, and reapply the sequences as needed. You can modify whether a Control Sequence is treated specially with thectlparameter."nl": newlines.
"c0": all other "C0" control characters (i.e. 0x01-0x1f, 0x7F), except for newlines and the actual ESC (0x1B) character.
"sgr": ANSI CSI SGR sequences.
"csi": all non-SGR ANSI CSI sequences.
"url": OSC hyperlinks
"osc": all non-OSC-hyperlink OSC sequences.
"esc": all other escape sequences.
"all": all of the above, except when used in combination with any of the above, in which case it means "all but".
- normalize
TRUE or FALSE (default) whether SGR sequence should be normalized out such that there is one distinct sequence for each SGR code. normalized strings will occupy more space (e.g. "\033[31;42m" becomes "\033[31m\033[42m"), but will work better with code that assumes each SGR code will be in its own escape as
crayondoes.
Control and Special Sequences
Control Sequences are non-printing characters or sequences of characters.
Special Sequences are a subset of the Control Sequences, and include CSI
SGR sequences which can be used to change rendered appearance of text, and
OSC hyperlinks. See fansi for details.
Output Stability
Several factors could affect the exact output produced by fansi
functions across versions of fansi, R, and/or across systems.
In general it is best not to rely on exact fansi output, e.g. by
embedding it in tests.
Width and grapheme calculations depend on Unicode database version (see
fansi_unicode_version, and grapheme processing logic among other
things (see "Graphemes"). Individual character width are intended to match
R4.5.1 definitions in an English locale, except for differences introduced by
Unicode Database Version updates and grapheme processing.
How a particular display format is encoded in Control Sequences is
not guaranteed to be stable across fansi versions. Additionally, which
Special Sequences are re-encoded vs transcribed untouched may change.
In general we will strive to keep the rendered appearance stable.
To maximize the odds of getting stable output set normalize_state to
TRUE and type to "chars" in functions that allow it, and
set term.cap to a specific set of capabilities.