$chr(0) definitely does not work with the way mIRC handles C strings. You can only get \0 inside of bvars, so that severely limits its use. I highly doubt you'll ever see this change. Way too many moving parts in mIRC rely on C strings right now, and changing all of them at once would result in HUGE amounts of new potential security issues. This is absolutely not worth it.
Agreed, it wouldn't be worth it.
I still disagree with your proposal of using only 0-15 for legacy compat.
There is an excellent and compelling reason not to change the nature of 0-15. Even while 0-15 are re-definable, they tend to
default to the same colors in most clients (because their origins are the EGA/VGA text mode color palette). So while different clients might not use exactly the same RGB value for ^K04, ^04 usually tends to be bright red; and while different clients might not use exactly the same RGB value for ^K02, ^K02 usually tends to be dark blue; etc. (In the opposite sense, there are also groups (channels) where everyone communally employs the
same alternate RGB definitions for 0-15.)
Considering both those factors, any new "standard" that either (a) suddenly standardized 0-15 by prohibiting their re-definition, or (b) gave license to haphazardly re-defining 0-15 for local use, would upset and further complicate this balance for users of older clients. IMHO, 0-15 is simply a sleeping dog best left lying. It is widely understood to imply "public and
usually standard, but re-definable," and that understanding is entrenched and shouldn't be meddled with.
Specifically, again, because what we need is more LOCAL indexes, not over the wire colours. At the end of the day, I don't think Guest18542 cares whether Jane158 thinks the "Royal Blue" is a smidgen too dark for her liking.
I can imagine that argument having been made by the designers of 16-color video cards to the ones advocating 64-color video cards.
(And if Guest18542 didn't value greater color variety, Guest18543 would.)
Besides, that comparison misrepresents my intent: I didn't join this discussion
to advocate extreme public color granularity. I only chimed in to give support to the idea of releasing IRC from its legacy public 16 text mode color prison. (In any sense that I did propose granularity, it was while I was still thinking that there was no point to having private colors at all; so I included the notion of granularity in the proposed public scheme just for the benefit of its local uses. As long as there
would be a private color range, however, then I still propose expanding the public range. And on that note, there's a difference between proposing that in the interest of excess, and proposing it in the interest of escaping inadequacy. (Just trying to clarify -- no belligerence or anything intended.))
Anyway. Considering that 0x00
is out of the question, robbing
some public resource for private use becomes, I guess, the only option. And because it would be bad to waste an entirely new (non-^K) control character on something that could never be employed over-the-wire, how about this:
Two rows of hardcoded colors were eliminated, reducing the "guaranteed always the same color" range to ^K16 - ^K69. That range still represents every possible primary, secondary, and tertiary color, but now offers 4 instead of 6 luminosity choices for each. Grey has also been reduced to 4 luminosity choices. With ^K70 - ^K98 now freed, a total of 29 palette positions are available for local/private re-definable hues -- which is the 20 you're advocating plus room for 9 more in the future.
Your thoughts? Anyone else's thoughts?
You're also not going to get an "agreement" on 80 more colour codes from other IRC clients at this point in time, so that makes it harder to implement this over the wire stuff.
Was there ever an agreement on the first 16? To my knowledge, one influential client author simply introduced them, and the others followed suit for compatibility. Yes, there was a brief chaotic period (due to existing clients, which didn't yet support color, leaving the new color control codes visible). But again, that wouldn't happen this time considering that existing clients hide the control sequences for 16-99.
In any case, I'm not even saying that that approach should be taken again. This time, the idea could be discussed among the influential client authors. And in that case, I don't see a good reason why any of them would be flatly against the mere idea itself of extending the IRC color scheme (unless some were just "against change").
What client authors would be agreeing/disagreeing upon is:
1) Is the current public color scheme outdated and restrictive compared to what most users of color might prefer?
2) Should a new scheme incorporate the old scheme (and its behavior) for legacy compatibility (to prevent possible chaos and confusion)?
3) Is it a known problem that color consistency cannot be guaranteed on IRC (that John's ^K04 isn't always the same color as Jane's ^K04)?
4) Would a new range of ^K## codes whose RGB hues were hardcoded solve that problem?
5) Would the best choices for those ^K## codes' RGB hues be a handful of luminosity iterations of every possible primary, secondary, and tertiary color?
6) Can we mutually agree to deem any remaining ^K## codes "hereafter off limits" (forevermore reserved for local client use only)?
Seems to me like "yes" would be an easy answer to 1-4, and a fairly easy answer to 5-6.
As for your comments about Ctrl+Shift+C, I think I might have been reading it the other way around the first time, thinking you would copy remote codes and translate them for local use. I see your point now. The problem is, many users already hit Ctrl+Shift+C because they aren't entirely sure whether the combo is Ctrl+C or Ctrl+Shift+C. Both work right now, so this change might be surprising to *those* users
Well, it's pointless to further debate this as long as a deeply-buried I/O routine were present to strip (or convert) local use codes.
But just for the sake of answering you anyway: sucks to be them. Not doing things to blindside people who're accustomed to properly using key combinations is one thing, but holding back on change because it might blindside people who don't RTFM is a bit much. It would be nice not to upset their habits, but since people can misuse things in any number of ways, most new ideas would be relegated to the forbidden bin by adhering to such a principle.
(Edited for typos and other clarifications, including updated inline image URL.)
