feat: for the progress items strip ansi sequences

[Tieske]

#195 added a feature to strip ansi sequences from text. That can be used to strip them from the spinner/progress items. Net effect being that those items can use color in their different sprites.

Possibly also from pane-titles.

[Gitkbc]

Submitted PR #207 implementing the proposed change.

Spinner and ticker width calculations now strip ANSI escape
sequences before computing visible width, allowing colored
sprites without breaking cursor positioning.

Please let me know if any adjustments are needed.

[Tieske]

@Gitkbc same here; let's keep the discussion in one place.

[tanmayrajurkar]

@Tieske
While looking at #207 locally, I had a few additional observations beyond the commit-structure points already raised:

1. In progress.lua, visible_width() is introduced for spinner and ticker. There are currently tests for ANSI-styled sprites, but none explicitly asserting that plain (non-ANSI) sprites retain identical left_seq() behavior. It may be useful to lock that path in to avoid regressions.

2. In draw/line.lua, truncation now results in rendering the stripped (plain) title, whereas non-truncated titles preserve ANSI. That creates two output semantics for the same API depending on width. Just flagging that in case we want to explicitly define whether truncation should alter styling or only layout.

3. The visible width = strip_ansi + utf8swidth rule is implemented separately in progress.lua and draw/line.lua. If this becomes the canonical definition of display width for styled strings, it might make sense to centralize it to avoid divergence later.

Just sharing observations for discussion purposes – let me know if any of this is not in line with the intended direction

[Tieske]

1. the ANSI style tests currently use hardcoded ANSI sequences instead of the ones provided in the library itself. That's not nice. If there is no test for plain input with no ANSI sequences, then adding one would make sense
2. I think that when truncating, we should only remove the visible characters. All ANSI sequences should remain such that styling isn't influenced by the truncation. That would solve the current edge case.
3. It's a bit of a personal thing, but I don't like single line functions, I'd rather do those in line (unless there are too many calls)

My 2cts

[tanmayrajurkar]

That makes sense

It's a bit of a personal thing, but I don't like single line functions, I'd rather do those in line (unless there are too many calls)

Interesting point on the single-line functions as well