>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
_______________________________________________
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
