Adds 0-255 as acceptable values for --color-match for ansi256 color support

[elzii]

Just +14 lines in ack, and +24 in t/ack-color.t.

[elzii]

Thanks for keeping this alive btw. While I mostly use it for highlighting since it is way better than ripgrep, I'm so glad it's around. And performant! Cheers.

[n1vux]

Ack already supports the ANSI colors using the relevant module CPAN Term::ANSIColor, and can set both foreground and background.

What is your underlying desire? To use the ANSI256 color numbers you already know by heart in the Env Var instead of the rgbRGB codes in --help-rgb-colors ?

You can already specify the ANSI decimal 000..255 color codes in $ACK_COLOR_<item> environment variables and --color-<item>= settings on Ack CLI and .ackrc by prefixing ANSI (or on_ANSI) instead of prefixing rgb . Any color tag exported by Term::ANSIColor is accepted. (on_ and rgb are their prefixes, not ours. We just provided a visual catalog of their rgb000 codes.)

$ ack --color-filename='blink underline red on_green' --color-match='ANSI188 on_rgb505' color
...
$ (ACK_COLOR_MATCH='blink underline red on_green' ack color)
...

NOTE: I do NOT recommend using blink nor layering red on_green, they are used as examples that anything goes that's in the ANSI module.

ASIDE, ANSI256 decimal color numbers of the rgb codes in --help-rgb-colors are 16 + base6 interpretation of color triple. ANSI color numbers reserved the lower numbers 0..15 for the old 8+8 base console colors, used in ACK as the named colors, via their ANSI names; midrange 16..231 are the 6×6×6 gridded RGB colors; and the highest in ANSI are the named greys.

Since we'll already accept --color-match=ANSI188, is there a deep need for accepting --color-match=188 ?

Even if so, we'd probably still want to process them through Term::ANSIColor (by prefixing ANSI) instead of coding \e38;... inline.

(:+1: ♥ you do get bonus points for including a test! But in general we'd prefer a discussion of desire and plan, either on mailing list or in an Issue, before a PR.)