Related to my earlier post, workaround for auto colors with poor contrast, and additional hurdles to find the color for the <nick> in a query window.
**
I finally noticed a way to remove colors from the autocolor list when they don't contrast against the background, so users have a workaround to do this.
The rules for adding colors to the autocolor palette appear to be
1. If the RGB matches the RGB of a color already chosen, then don't add it.
2. If there's some other rule in the 'nick colors' list that uses that color, then skip it
3. If contrast( $color(background) , color index N) is considered high enough, then add it.
So for a black background, if the autocolor is the only rule, then per step#1 color 52 does not get added if it's an identical RGB to color index 4 that had already been added. But if there is a rule to make all @op be color 4, then color 4 does not get added to the auto color list, because 4 is used by some other rule. However since 4 now is not in the chosen list of autocolors, then 52 will not be rejected by step#2, even though it's identical RGB to the 4 that's attached to another rule.
But with color 12 and 60 added to autocolor in spite of having poor visual contrast against black, I can create a dummy rule to match NoSuchNick and attach color 60 to it, and make another such rule and attach it to color 12. And that will make autocolor not choose 12 or 60, even if that rule can never apply to anyone.
**
Using $cnick(nick) to identify the rule that applies to a nick returns false positives and false negatives. The $cnick(nick) returns the first rule that matches that nick, but doesn't allow specifying whether you want to know about matching the nicklist or the <message_nick>. So if that Nth rule is nicklist-only, then the script needs to loop through all the rules below it, to see if any match <message> for that nick.
$cnick(nick) cannot accurately find the rule that generated the color in a channel nicklist, because since it doesn't take a #channel as the parameter, it doesn't match any rule that matches only someone having a channel mode, so that causes it to return the position for a rule that has no actual effect.
While Nick Colors rules govern the nick color in a query window, just as what happens in a channel, $cnick(nick).color returns $color(normal) or $color(own), instead of returning whatever is the autocolor for that string.
It's not clear what benefit there is to having .color returning the default color whenever there's an autocolor rule in effect for that nick.
So, if the nick colors tab has rules:
1 auto-color *@* for nicklist only
2 red-if-nick-is-@op, for <message> only
3 yellow if matches libera's cloak *!*@user/* for nicklist only
4 blue if matches *!~*@* for <message> only
when the nick is an op, and has mask *!~*@user/* ...
$cnick(nick) returns 1 because the auto-color matches everyone for the nicklist. But $cnick(nick).color returns $color(normal) if the nick is someone else, or $color(own) for self, instead of the actual rando color shown. But can't determine that the <channel message nick> will be @op red, without looping through all the rules looking for a match that applies to <message>.
For the same thing in a query window, it needs to loop through all the rules looking for a match before determining that the <message nick> will be blue due to rule#4.
So it looks like for the <channel message> it would be helpful to have $nick(#,nick).messagenickcolor since it can be different than $nick(#,nick).color, except such a property would not be useful in a query window unless the property considers the channel parameter either optional or accepts a query window's name instead.
In addition to the message/nicklist colors being different due to message-only and nicklist-only rules, one or both can be overruled by
/cline color #channel nick
/cline -m color #channel nick
