Hum, compatibility with the current coloring system would break for <ctrl-k>#<A>,<B>.
Atm this means "undo coloring" (return to default linke color) but keep e.g. bold/underline formatting. Example:
//echo 8 -a test $chr(31) $+ $chr(3) $+ 07test $chr(3) $+ #00000,fffff
The #-char also has a special use in IRC - to denote a channel as the target like in
(#mychan might be a channel named #12275 or the like).
Now, a single rgb-digit would in theory work for local coloring via the echo command -
if used together with the -c switch. Some switch is required anyway: to distinguish "color $rgb(12,0,0)" (= 12) from "color 12 of the mIRC default palette". This in turn implies some new switch for /aline and the like...
But then, would people be satisfied with the option to set rgb
line colors? I think they instantly would request an option to rgb-color parts/words of the line as well. And as it mustn't come into conflict with the established parsing of in-line ctrl-k[N[,N]] it would in turn require e.g. a distinct, new "control code" char, to denote "rgb color digits follow". This char *could* be called by a shortcut like ctrl-k calls a $chr(3), and it *could* open a different rgb-color picler the way ctrl-k opens the default color picker.
@vexed2: As in any case you can use it only locally, that is in scripts most of all: One could e.g. create a "custom" palette for a script by assigning color numbers to catchy variables. Or create a custom identifier $mycol(color title) to return those numbers...
... just some thoughts
