David Spickett 23dffff410
[lldb] Fix issues handling ANSI codes and Unicode in option help (#183314)
Fixes #177570, and a bunch of FIXMEs for other tests known to be
incorrect.

To do this, I have adapted code from the existing ansi::TrimAndPad. At
first I tried a wrapper function, but there's a few things we need to
handle that cannot be done with a simple wrapper.

We must only split at word boundaries. This requires knowing whether the
last adjustment, which may be the final adjustment, was made at, or just
before, a word boundary. Also it must check for single words wider than
the requested width (though this you could do with a wrapper).

For this reason, the new TrimAtWordBoundary has more special case checks
and a more complex inner loop. Though the core is the same split into
left, ansi escape code and right that TrimAndPad uses.

It is that splitting that implements the "bias" we need to print
correctly formatted characters. When you have a preceeding ANSI code,
this must be included in the printed range, same for proceeding.
TrimAndPad already handled this, and I've copied that logic over.

TrimAndPad also used Unicode aware functions, which fixes the known
issues with Unicode (though no command option actually uses Unicode at
the moment).

This PR replaces PR #181860, where I tried to implement all this using a
strategy that used "visible indexes" to decide where to cut the lines,
and then converted those into "actual indexes" to know what to print.

This worked for most cases, but adding the "bias" was very complex. The
preceeding codes were quite easy to do, but proceeding proved to be too
complex.

I also had the feeling I was revinventing TrimAndPad and though it
didn't turn out to be that simple, it wasn't far off.

As the majority of the work is now done in TrimAtWordBoundary, I have
reused some existing OutputWordWrappedLines tests for the new function.
2026-02-26 11:00:53 +00:00
..