Renamed enum color to colors.

[Remotion]

Added enum colors conversion to rgb struct.
Added colors_test.cpp.

Now it looks a bit strange.
We have enum color from format.h and enum class colors from colors.h.

[eliaskosunen]

(v)print_colored and enum color should probably be entirely replaced by this. They aren't even documented, so I don't think it would be a breaking change. This would also allow renaming the enum to the more logical singular-form color.

[vitaut]

I suggest keeping the name color because enum names are normally singular in the standard (see http://eel.is/c++draft/utilities#meta.endian and http://eel.is/c++draft/atomics#order) except for bitmask types.

[Remotion]

Agree name color is better but then there are 2 different enums with same name.
How can this be resolved then ? Rename or remove enum color from format.h ?

[vitaut]

I suggest removing the old color and print_colored. Those are undocumented and experimental anyway and the new functionality seems strictly more general.

[Remotion]

What about fmt::printf(rgb, ""); ? I could add this too but then colors.h will need to include printf.h.

Another more complicated idea would be to allow multiple colors per line.

// Something like this ?
fmt::print("{:color::red}, {:color::green}, {:color::blue} \n","red","green","blue");
```

[vitaut]

I don't think we need fmt::printf(rgb, ""). The whole point of printf is to simplify transition from legacy printf and the latter doesn't have color support.

[Remotion]

What do we miss here ?

[vitaut]

Why have both print and print_rgb?

[Remotion]

print_rgb is now removed.

[eliaskosunen]

You could try fixing the g++ 4.8 build. https://github.com/Remotion/fmt-fork/blob/74107c9bd8c1df2b74d3cb4c0d98f0dcc60813d7/include/fmt/colors.h#L39-L43

FMT_CONSTEXPR expands to constexpr when relaxed C++14 constexpr is available and inline otherwise. Because constexpr functions are implicitly inline, you should remove the extra inline.

[vitaut]

Looks good but Travis build seems broken.

[vitaut]

Merged in ce50063 with minor tweaks to prevent breaking the API (we can remove the old color API during the next major release). Thanks!

[eliaskosunen]

Is it really necessary to wait for the next major release, though? The previous color API was not documented anywhere, so the feature wasn't really stabilized and it wouldn't really be a breaking change to remove it.

[vitaut]

It is still part of the public API, so I'd rather remove it in stages. Maybe not in the major version but at least we need to provide a good migration plan.

[vitaut]

I added a comment that the old color code is deprecated (https://github.com/fmtlib/fmt/blob/master/include/fmt/core.h#L1185) and we can make FMT_EXTENDED_COLORS the default in one of the minor versions.

[vitaut]

@Remotion, could you please review the updated CONTIBUTING document, particularly the part about licensing, and let me know if you agree with it being applied to your contributions to {fmt}? The library is likely to be relicensed (#1073) so I'm collecting approval from all earlier contributors.