summaryrefslogtreecommitdiff
path: root/t/t4026-color.sh
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2014-11-20 15:17:05 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-11-20 20:41:07 (GMT)
commit695d95df19b74485be62aba0f978044ff1215ea0 (patch)
treee104b49b7da5c2a5531ce0199faa518cc4ce38c3 /t/t4026-color.sh
parent62ce40d9338046a89de5d2bfb6b258872fd366c0 (diff)
downloadgit-695d95df19b74485be62aba0f978044ff1215ea0.zip
git-695d95df19b74485be62aba0f978044ff1215ea0.tar.gz
git-695d95df19b74485be62aba0f978044ff1215ea0.tar.bz2
parse_color: refactor color storage
When we parse a color name like "red" into its ANSI color value, we pack the storage into a single int that may take on many values: 1. If it's "-2", no value has been specified. 2. If it's "-1", the value is "normal" (i.e., no color). 3. If it's 0 through 7, the value is a standard ANSI color. 4. If it's larger (up to 255), it is a 256-color extended value. Given these magic numbers, it is often hard to see what is going on in the code. Let's refactor this into a struct with a flag that tells which scheme we are using, along with a numeric value. This is more verbose, but should hopefully be simpler to follow. It will also allow us to easily add support for more schemes, like 24-bit RGB values. The result is also slightly less efficient to store, but that's OK; we only store this intermediate state during the parse, after which we write out the actual ANSI bytes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4026-color.sh')
0 files changed, 0 insertions, 0 deletions