http://qs1969.pair.com?node_id=11143685


in reply to Text::ANSI::Util for wrapping "colorful" text

Looks like qualified bugs to me, because of duck test. Vanishing space character can be fixed in line #160, it should be $prev_type instead of '', I think. As to other issues, there are quite a few hundred lines of code, I gave up after some poking around. In the very next line, #161, condition never evaluates to false (or does it?), I don't understand what its purpose would be, etc.

I think you missed an issue (easily seen with underline) of ANSI code leaking into preceding whitespace. If debugging output is un-commented in #273-277, I think it's clear it is a matter of a space char either being prepended or appended to a term in further processing, but again I'm not ready to find where exactly, in code, it happens. I think something similar would fix the leading indentation issue.

To add to things to fix for the author, I tried to use Text::ANSI::WideUtil qw/ta_mbwrap/;, it fails with call to non-existent Text::WideChar::Util::_mbs_indent_width

Update 22/05/10. Here's a patch, seems OK with limited testing. Issues mentioned in this thread are fixed, tests are passed. As strange as it is, color continuing in next line's left margin is "a feature", see #153. For now, there's ugly condition to both satisfy existing test and provide clean white-space margin. As I expected, if term is ANSI-code only, it must have originated from code following WS originally (of course not including the case of code in the very start of text), therefore a space char should be prepended, not appended, to it.

Update#2 22/05/10. Sadly, there still was leak of formatting into preceding WS in case of several adjacent codes (as "Marley " . BOLD . GREEN . "was" . RESET). I have updated patch, replacing $re with $re_mult. Damn, I thought I checked that :(. Well, there's still a convoluted/artificial case such as " ". UNDERLINE . " was" . RESET;. Multiple spaces being compressed to one, where should code go? Result may look OK if we agree on "where", but I don't like that debugging output says @termsw stores "0" and "undef" for these 2 spaces. I think it's already for the author to unravel :(

--- BaseUtil.pm.original Sun Aug 8 19:50:33 2021 +++ BaseUtil.pm Tue May 10 12:16:22 2022 @@ -157,7 +157,7 @@ my $only_code; $only_code = 1 if !@s; while (1) { my ($s, $s_type) = splice @s, 0, 2; - $s_type //= ''; + $s_type //= $prev_type; last unless $only_code || defined($s); # empty text, only code if ($only_code) { @@ -445,7 +445,7 @@ if ($x + ($line_has_word ? 1:0) + $wordw <= $widt +h) { if ($line_has_word && $ws_before) { - push @res, " "; + splice @res, $#res + $res[-1] !~ /^$re_mu +lt$/, 0, ' '; $x++; } push @res, $word; @@ -474,7 +474,7 @@ push @res, "\n"; $y++; push @res, $crcode; - push @res, $sli; + splice @res, $#res + $sli =~ /\S/, 0, $sl +i; if ($sliw + $wordw <= $width) { push @res, $word;