colors in our black background world

[The Almighty Pegasus Epsilon]

So I personally don't have much love for mIRC users, but the fact
remains that they (sadly) make up the majority of IRC users these
days. They also have an annoying tendency to use ^C01 instead of ^O to
"reset" the text color, since mIRC stock comes with black text on a
white background.

We, as console dwellers, don't live in this eyeball-scorching world,
most of the time.

So here's my idea, as I first proposed it to hop, his refinements later:

We remap the colors so that the bright colors and the non-bright
colors are reversed, and rearrange the white<->black contiuum so that
^C01 is non-bright white (standard IBM grey) and ^C00 is black
(invisible to mIRC users and us), etc.

hop said (rightly) that rearranging the colors would ultimately lead
to complaints, and that it has also (apparently) been discussed here,
so he proposed an alternative: a /set mapping, where stock,
out-of-the-box EPIC has mIRC-standard colors, and you can rearrange it
with the /set if you feel like it. Another option is a compile-time
#define or ./configure --with-rearranged-colors-nonsense switch, but
hop seemed to ignore me when I mentioned that :)

The /set gets us runtime-reconfigurability, and the #define gives us
speed, and both of them give us (mild, imo) code complexity increases,
which I would be willing to deal with (implementing, of course, and
patching, maintaining, etc), if that has to happen. But before
anything happens, you people must be heard from. So, what do you all
think?

Remappable colors, yay or nay?

- pegasus

[Jeremy Nelson]

Post by The Almighty Pegasus Epsilon
hop said (rightly) that rearranging the colors would ultimately lead
to complaints, and that it has also (apparently) been discussed here,
so he proposed an alternative: a /set mapping, where stock,
out-of-the-box EPIC has mIRC-standard colors, and you can rearrange it
with the /set if you feel like it. Another option is a compile-time
#define or ./configure --with-rearranged-colors-nonsense switch, but
hop seemed to ignore me when I mentioned that :)

The color mappings are stored in a table, which for expediency sake is
static and compiled-in, but it doesn't have to be that way. After thinking
about this some more, I would probably think we could all be happy with
a $colorctl() function, that worked something like this:

$colorctl(VALID TEXT) - Returns a list of all valid (mapped) colors,
that can be used as text colors
$colorctl(VALID BACK) - Returns a list of all valid (mapped) colors,
that can be used as background colors

$colorctl(GET <x> TEXT)
$colorctl(GET <x> BOLD)
$colorctl(GET <x> BACK)
$colorctl(GET <x> BLINK)

Each ^C color maps via four tables: depending on whether it is used as a
fg color or a bg color, it specifies both the ansi color, and the bold
setting, or the ansi color and the blink setting. Ansi colors are 0-15,
and have nothing to do with mirc order colors and have nothing to do with
^C00 to ^C15. Ansi colors are the ^[[10m type numbers.

I think it should be possible to change any of these values:

$colorctl(SET <x> TEXT <ansi color>)
$colorctl(SET <x> BOLD <0|1>)
$colorctl(SET <x> BACK <ansi color>)
$colorctl(SET <x> BLINK <0|1>)

Then you can change any ^C code to anything you want, and go on your merry
way. This would satisfy Pegasus's desire to be able to change the colors,
and it would satisfy my desire that everything be 100% backwards compatable
unless you opted-in to changing it.

That's my two cents...
Jeremy