The problem is I'm not sure what the correct specification is, and don't
want to delay the SRFI further to over-specify something that can only
be achieved by bypassing the API and manually encoding ANSI escapes.
Trimming is a separate issue, and not necessarily solved in the same manner.
Your proposal from before was to provide a `string-trim` state variable, which doesn't
help here.
Getting back to that issue, what is the correct behavior of `trimmed` in the presence of ANSI escapes?
Stripping everything except ANSI escapes should leave the terminal in the
correct state (at least the same state as if no trimming took place), but it's
expensive and not applicable to `trimmed/lazy`. This underlying trim
procedure is already a utility so we would just need to export it as a state
variable. This could be useful for other things, e.g. for trimming by word.
`trimmed/lazy` could preserve and restore the terminal colors, only if it
knows about them. This would imply ANSI escape handling is builtin,
which I'm not a fan of. I would suggest just noting that ANSI escapes
may not be restored cleanly (though they will always be handled as a unit)
in the docs for `trimmed/lazy`.
--
Alex