Sigh. Serves me right for thinking aloud in a state of sleep deprivation. Yes, let's amend my previous post:

First, pretend that I never proposed an RGB FFFFFF format for local color specification. As you said, and for the reasons you said, hardcoded color values would be bad. (You even said this the first time -- "whatever new colour indexes are added have to be customizable" -- but my mind discarded it.)

Second, let's also pretend I never suggested the idea of ^K + "#" as the literal prefix for signalling a local color sequence. ^K + "#" already exists as a "valid" sequence over-the-wire (^K + anything != 0-9 == already interpreted by IRC clients as "transparency".)

Had I been wide awake, I probably would have suggested something more akin to:
  • ^K#[#][,#[#]] = the extended public palette
    • with 0-15 continuing to behave as they do now, for 100% legacy compatibility (re-definable by client authors/users);
    • with 16-98 being hardcoded hues from a globally agreed-upon "IRC palette" for over-the-wire consistency;
    • and with 99 continuing to be what it is now (transparency).
  • ^?#[#][,#[#]] = new local palette whose control sequences are never sent over IRC, nor even between clients via things like DCC chat (0-99 being locally re-definable palette entries)
As for which control character would be best for local colors (?), that's a tough one. Any character not already in use on IRC would be a candidate, but using any of them would still constitute robbing a public resource for private use. Perhaps, then, the correct choice would be a character already disallowed by the IRC protocol. Does it disallow ASCII #0? If #0 is disallowed on IRC, and if #0 wouldn't also pose an internal challenge to mIRC (on account of it being a C creature), and if #0 also wouldn't be a problem for any of the text editing Windows APIs mIRC uses, then #0 would work wonderfully -- Khaled could just map a local key combination to spew it (perhaps CTRL-SHIFT-K).

Regarding the CTRL-SHIFT-copy idea:

Quote:
Also, adding in another key combination for copying doesn't really sound very user friendly, especially given that your suggestion CHANGES behaviour that users have relied on for 10+ years. If anything, Ctrl+Shift+Copy should be the local copy, which would preserve backward compatibility and not be surprising to users who upgrade.

That's what I said. smile CTRL-SHIFT-copy would be a verbatim copy, copying all control codes verbatim and changing nothing. CTRL-copy would also copy control codes, but would convert each private control sequence it encountered to the 16-98 public control sequence whose hue was the nearest match to the private sequence being converted. I had the same "don't change expectations" idea. "Don't change the expectation that any codes picked up by CTRL-copy will be compatible with sending over-the-wire." If CTRL-copy performed nearest-match local -> public code conversion, that expectation would not be disrupted.

However, now that I think of it, mIRC would already need something buried deep within its I/O routines to at least strip local color control sequences from outgoing messages (assuming users attempted to send them from an editbox or via /msg type commands in scripts). So, as long as it would be inserting a stripper, it could just as easily insert a converter at that same level instead. In which case having CTRL-SHIFT-copy in addition to CTRL-copy would be pointless; CTRL-copy could just stay as it is, a non-converting verbatim copier.

/me hopes he got everything right this time