Closed leighmcculloch closed 6 years ago
This is a fairly complex situation. To support this each color function has to parse the incoming string and lock if it's what formatted before. And it's just a string. So this would mean that for every single input, there will be additional computation. I'm going to close this down as I don't think to support this. Thanks anyway.
Thanks for reading and explaining @fatih! Makes sense. ❤️
Scenario
I'm using the
color._String
functions to color sub parts of a string that have already been colored.Got
Want
Code
It looks like the existing behavior is probably intentional, because this piece of code clearly shows the wrap function unformating the color. I'm not sure if it would be feasible to support this scenario or even if it was if that'd be outside the intended scope of this package, so I'm not assuming this should change, but wanted to open a discussion about it. I'd be up for taking a stab at it if the consensus is this would be welcomed. Some similar packages in other languages do allow nesting of colors. e.g. https://github.com/junegunn/ansi256#nesting
https://github.com/fatih/color/blob/5df930a27be2502f99b292b7cc09ebad4d0891f4/color.go#L357-L363
https://github.com/fatih/color/blob/5df930a27be2502f99b292b7cc09ebad4d0891f4/color.go#L365-L367
https://github.com/fatih/color/blob/5df930a27be2502f99b292b7cc09ebad4d0891f4/color.go#L369-L371