FYI - matching on valid-colors.txt

fixed build errors and a few cases from your colors.txt that were not working, please verify, #841

Yeah, looks good. Thanks for fixing my silly mistakes (the learning curve is still vertical!).

i beg if differ on this valid-colors.txt list

checkout the screenshots, the ditto version are there as well

v3.24.317.0

vs

v3.25.57.0

with colors...

36F301
#36F301
255, 0, 0
112233

1. the new color tiles are too small
2. forcing prefixes breaks the color tiles. ...

... there are many code langs and settings doc that don't require a prefixes or even add their.

AHK is good example, it uses hex, but not #112233. it can handle 0x112233 in some places - not all, and everywhere else they use their own prefix of c112233

and\or other code docs, an xml here, don't use the RGB() prefixes <element id="Menu.DropDownCheckBoxImage" fg="0, 255, 0" />

Fixed in the latest, thanks for saying something, https://github.com/sabrogden/Ditto/releases/tag/nightly

https://www.w3.org/TR/css-color-4/#color-syntax

So 112233 is not a hex color - it's just numbers. So, do we confuse users who are not developers and will be puzzled to see a color block next to some number they copied?

XML ... fg="0, 255, 0"

Same as before - that's not RGB. How can you match for every permutation of RGB / HSL / etc. without their prefix?

Going back to this issue \ feature request. Which u implemented previously. #722

This change has broken it.