Add a nontext function for texts with custom widths

[tarleb]

No description provided.

[tarleb]

@jgm what do you think about this interface? The motivation for this change is that ANSI escape codes in the terminal writer are currently included in length calculations, but should be treated as having width 0. Otherwise lines with markup come out shorter than they should.

[jgm]

Wouldn't a better solution be to modify the width calculations in doclayout itself, so that ANSI escapes don't count as having any width?

[tarleb]

Making this part of doclayout seems a bit specialized. It would require doclayout to have knowledge about all (or the most important) escape sequences, which appears to be not entirely trivial.

On the other hand, doing that would help to make centering possible: Positioning currently uses on realLength, which could be taught to respect those escape sequences as having zero length.

[jgm]

I found this: https://hackage.haskell.org/package/vgrep-0.2.3.0/docs/src/Vgrep.Ansi.Parser.html#ansiFormatted
Don't know if I'd want to depend on the whole package, but we could copy the parser if it's small...

[tarleb]

The linked parser recognizes font-related sequences, which would be good enough for our use case. If I understand correctly, then the parser is just string "\027[" *> (decimal `sepBy` char ';') *> anyChar. Slightly inaccurate, but simple.

[jgm]

I think it's okay if we miss some obscure escape sequences, as long as all the things we identify as escape sequences actually are. So, no false positives.

[tarleb]

Some quick testing indicates that the last part should be *> letter to avoid false positives. Other than that, it should work.
Should I raise an issue for that in the doclayout repo?

[jgm]

Actually, doclayout uses a fancy state machine to compute widths, so we couldn't even reuse the parser, though it could help us to construct the state machine. Yes, go ahead and open an issue.