Nested colorize objects disable all attributes

[Blacksmoke16]

require "colorize"

foo = "foo".colorize.red

str = "hello #{foo} bar".colorize.underline

str => "\e[4mhello \e[31mfoo\e[0m bar\e[0m"

Because coloring/modes are reset via \e[0m all attributes are turned off, not just the one that is ending. The correct code sequence should be like "\e[4mhello \e[31mfoo\e[39m bar\e[24m". I.e. \e[39m only resets the foreground color and \e[24m only resets the underline.

[HertzDevil]

That only solves part of the problem because you could still have:

foo = "foo".colorize.red
str = "hello #{foo} bar".colorize.green
puts str

and bar will not be colored, even when foo ends with \e[39. The #surround method might handle this correctly, but not string interpolations I believe.

[straight-shoota]

Yeah and I don't think there can be a good solution really. To properly return to the previous colorize state, it would be necessary to keep track of the context.

This technically works, but the nested colorization needs to be actually nested inside the colorize surround context.

String.build do |io|
  Colorize.with.green.surround(io) do
    io << "hello #{"foo".colorize.red} bar"
  end
end # => "\e[32mhello \e[0;31mfoo\e[0;32m bar\e[0m"

Note that this is not concurrency safe because there is just a global @@last_color property.

[asterite]

I agree with @HertzDevil and @straight-shoota . The way these ansi codes work is not composable (unlike, say, html tags) because they are just toggles. And because of that, string interpolation won't work.

I think this is a "wontfix". Or, well, you can use surround.

[Blacksmoke16]

I mean I don't think we can solve for all use cases so maybe this is more of an enhancement than a bug. But is there any reason to not use the correct toggles instead of \e[0m all the time? At least then it'll be more correct than before in more cases.