Forums Feature Suggestions More colors PLEASE!

I have been using mIRC for many years (atleast over a decade), and I have been generally happy with it. I have troied other irc programs, but for one reason or another, I did not like them as much as this ine. However, there is one shortfall that has bothered me over the years. The anemic choice of colors offered. How about expanding the color options? I cannot see why it could be possible to include an option to define custom colors. MSPaint offers 28 colors, Internet Explorer offers 56 colors (with the option of "defining custom colors"), and Firefox offers 70 colors! mIRC only offers 16 (!?!) colors! How hard can it be to extend the color range?
Unless Mr. Mardam-Bey wants to go in history as the "Bill Gates of IRC" ("No one will need more than 640K of memory"), I would strongly suggest to him to widen the color choices.

This has been discussed plenty of times in the time that I've been hanging around the forums. The main thing stopping this seems to be the lack of standards. I'm not an expert on irc standards but the first 16 colors are standardized and more have never been added.

It also seems mIRC won't get more colors until there is some standard for more colors. Though I'm sure others could elaborate more on the topic, or you could search the forum for similar topics.

Open the color dialog, right click a color, select your custom color. Or use the /color command.

Well the problem with this argument is mirc already tries to interpret colors from ^k17 to 99, or atleast strips them from text. Also even though the first 16 are standardized alot of scripts change the defaults to suit their scheming.

You're comparing image editing software and two multi-media web browsers with a text-based IRC client. Of course they will have more colour choice-- that's practically what they are built for.

Colours over IRC were an after thought. They're technically not even part of the protocol. The limit is implicit in how the protocol was proposed well over a decade ago (when you started using IRC). So the 16 colour limit isn't really something mIRC can do much about now.

Of course you can also use colours locally, and there need not be any limit here, but the way colours are rendered are tied closely to the way they are rendered over IRC (it uses the same syntax), so extending the 16 colour limit would require a new syntax for local use. This would probably not be all that trivial.

However, the assumption here is that 16 colours is limiting. Is it really? We're talking local usage only, we can't change how colours work remotely. Colour usage locally would probably just be used for theming scripts. Themes tend to use only a handful of colours-- maybe 6 or 7 at most. Most themes only make use of ~3-4 colours (text, event, bg, accent). I don't know any themes that actually use 16 colours... so I'd question why you'd need more.

Note that the reason web browsers support all 16-million colours is because they are meant to allow designers to develop anything they want. Basically, if designers want to break the rules and use lots of colours, they can-- but this doesn't really happen that often. Designers are also responsible for designing the entire page, not just the content, so it's often required to use more colours when you're dealing with the overall page design (though even this is limited to a very small palette, in practice). If you actually look at most websites, you'll find that, minus the "chrome" (the skeleton of the design), there are again only a handful of colours used for text content (foreground, background, accent). Browsers still have to let developers pick any set of colours, which is why they support any colour, but designers won't just use every colour that is available to them just because they can.

mIRC actually works the same way in this respect-- you can pick ANY colour you want. So technically, your statement is misleading... mIRC offers 16 million colours. The difference is that you can only use 16 of them at a time. But again, given what I said above about themes, this tends to be way more than enough in practice.

The only real problem with colour limitations is that you have to share your local colour palette with the remote colour palette. IOW, if you change your "royal blue" (color #2) to a "neon blue", someone typing Ctrl+K+2 will send a neon blue, not a royal blue. That can make it difficult to apply non-standard theme colours while still using the standard colours over IRC. But again, this limitation is due to the way mIRC shares the palette. I think a separate palette for local use was suggested (extending Ctrl+K to 99 when not sent over the server and using the 16+ values for local palette codes), but I imagine it's not an easy change.

Thanks! I did not know that you could do that! Well, that answered my question. I do appreciate it.

Well, the standard 48 colors should be enough for starters. Besides, Loki12583 has already provided us with a more than adequate solution to the problem.

I think besides just allowing for a separate color palette or using another option for local colors (e.g. $rgb), it might be worthwhile to try and get the protocol standards updated to include more colors so that all clients can make use of a larger standard set of colors locally and remotely. It does mean people have to update their clients, but that really isn't such a horrible thing.

Of course, I don't know that anyone will get the right people together to make that kind of protocol/standards change on something that sees relatively little use. But who knows?

There is no such thing.

Well, there are at least standards in that Ctrl-K is color, Ctrl-B is bold, etc. It may be that the colors themselves are not standard, but the use of Ctrl-K is. It may not be part of the protocol, but it's still a standard. Getting an agreement to allow/handle more colors either using Ctrl-K through 99 or using some other method among the major clients would make it possible to use more colors over IRC once the clients are updated to make use of those colors. They don't have to agree on a specific set of colors; just that they will handle more colors in a specific way.

Just a thought. I don't really expect it to happen. Though mIRC could just force it to happen considering it's a leader in IRC clients and if mIRC users suddenly started using a lot of colors, other clients would need to either block those or handle them or their users would get upset at all the numbers/codes/etc that are mixed into their text incorrectly. But I think what will happen (if anything) is just that local colors will increase, but you won't be able to send more than 16 colors to anyone else.

I'd guess it's just a matter of desire to add it. Italics were added for v7 using ctrl+I (control code 29) - plenty of other control codes left that, to other clients, would just appear as an odd error until they would add support for it. And therein lays the rub. Think about a decade back and you might have seen oddball messages ("# appears as NAME NAME") from Microsoft's chat client - nothing else embraced that (avatars, I suppose) and those users were often finding themselves kicked swiftly.

If more colors did end up being allowed, I would imagine it would actually have an RGB type syntax. mIRC would probably have to drop its palette-based drawing, though.

This is sort of what it comes down to. You could easily extend mIRC to use 99 colours 0-98 (99 is transparency), that would only cause minor issues with unsupporting clients. The problem would be: which 99 colours would be standardized as the default? A palette based solution needs standardized colour choice, otherwise doing something like <ctrl+k> + 10,40 could easily overlay 2 very similar shades of blue in one client, making the text unreadable, while making it completely readable (yellow on black for instance) in another. This is why if there were ever any new standardization for colours, it would be RGB, not palette/index based-- but an RGB system would NOT be backwards compatible with mIRC's current colour parsing mechanisms, so that would be problematic too.

Well, one possible, but incredibly hacky and ugly, method would be to specify colors as multiple existing color codes.

i.e.
<ctrl+k>Rf[,Rb]<ctrl+k>Gf[,Gb]<ctrl+k>Bf[,Bb]<ctrl+k>Pf[,Pb][text here]

Where *f = foreground, *b = background, R, G and B are color values (within the range 0-99 rather than 0-255) and P are the 'standard' palette entries.
Clients supporting this would notice the 4 sequential color instructions and interpret them as above, while clients that don't support it would naturally fall back to the last color instruction.
( There's a caveat with regard to background colors, as a color instruction without background color component won't reset the background color. )

Even if IRC doesn't support additional colours it would be nice if mIRC did locally.

/echo could support RGB values with no problems whatsoever.

It could (I mentioned that), but it would be very rudimentary. You would only be able to apply the colour to the entire line, not specific parts, which I could see as being a big limitation for many scripters.

I don't see any reason why RGB would be limited to one color on the entire line in an /echo. It wouldn't be that difficult to make it possible to add any number of colors to a local /echo using RGB. Whether they are done using some RGB identifier or a switch that tells mIRC to treat all Ctrl-K's as RGB and parse them as RGB instead of the normal way... Ctrl-K255,35,124 or Ctrl-K255,35,124,40,87,237 for background colors or something like that (semicolon between would look better, but doesn't fit line up with normal color syntax). Or not use RGB in that way, but convert it so it's one number... Ctrl-K23578,54023 or whatever. The switch would just tell mIRC not to use only 1-2 numbers for the color code. There may be better methods as well. The point is that it shouldn't be difficult at all for local /echo to have many colors throughout a line using RGB, so there shouldn't be any limitation.

This is a nice proposal, but it's fairly short-sighted and hacked together on the premise that /echo is the only input to a window, and that no data ever comes out of that window. It doesn't answer many of the real issues you'd have with properly handling those coloured lines consistently throughout the execution of the client. For instance:

How would mIRC render these control codes when Ctrl+Copied? How would they get logged? How would something like /loadbuf know to interpret the syntax used among non-RGB codes? What would /msg # $line(#otherchan,N) do with those codes? More importantly, how would you be able to mix the 2 syntaxes in a single line? This would be extremely important for theming, since you would basically be unable to use RGB colour codes in an ON TEXT event (where incoming data might contain palette based colour codes) otherwise. You can recall similar theming problems in 6.x when scripts printed codepage characters in theme output on Unicode channels. The idea that just because it's local you can control whether you're using one syntax or another exclusively per-line doesn't actually work that way in practice.

Adding a special switch in a single command that changes the way mIRC parses an extremely common control code syntax won't work very well when you consider how the control codes need to interact with the rest of the client.

The only real way to support RGB style colours would be to add a completely new control code for that purpose; but then things get really weird and confusing for new users, especially given the ever-mounting problem that mIRC hasn't even rendered control code glyphs properly for the last 5+ years. The inability to differentiate control codes is likely to be a source of confusion and bugs, and frankly, given the rendering problems, I think it would be wiser if we found a strategy to move away from control codes, not add more.

Obviously I was talking about a single command. Such a method could just as easily be applied throughout mIRC in any command or event that can be used locally. There is no reason why RGB can't be made to work locally. It absolutely can. Yes, it will require work, but it can be done. Besides, the switch was just one option. Using some kind of identifier would work as well as I mentioned. mIRC could even let a remote user include the identifier and then display the right colors locally so that it was possible to send any color to someone who has a newer mIRC. Obviously, if other users who don't have the newest mIRC see it, they will see the identifier, but that would be completely up to the sender if they wanted to do that. Sending the identifier could be disabled by default, allowing a user to enable it if they want to send it. If they know everyone in the channel has a new version of mIRC, they could enable it and everyone could send any colors they wanted and everyone could see them. If they were in a channel where most aren't using a new enough version of mIRC, they can leave it disabled. That's just a side option that could be done to make it even more useful without suddenly having a lot of "messed up" text being sent to channels. Or, if there are any available CTRL codes, one of them can be used instead of Ctrl-K for setting colors and that code would always refer to RGB like you mentioned. Sure, rendering is a problem, but when it comes down to it, people are doing just fine scripting right now regardless of the rendering problem. It's not ideal, but it does work fine.

Logging should be changed anyhow. There should be an option to strip all codes and then you can open the logs in Notepad if you want, but if you allow codes, it should save in a format like RTF or something similar, where the codes are replaced with real formatting information. Then, you can open the logs in a word processor and see all formatting. It also lets you log any kind of color or formatting and load it back into mIRC without the slightest problem.

Why would you need to mix syntax? If I want a color from the palette, I can just use the RGB version of it. I'd expect with RGB enabled that you can have some kind of color wheel or similar to use and the standard palette colors should be included so you can click on them and their RGB information would be easily available.

And as far as your on TEXT example, we are talking about local display. on TEXT wouldn't even have to look for any kind of RGB if it's entirely local. You would assume the text coming in is palette-based. Then, if you wanted to adjust colors to RGB, you can halt it and echo the way you want.

However it is done, it definitely can be done. And there is no reason to think that multiple colors on a line are not possible or too difficult. No, adding RGB wouldn't be simple and easy. But neither was Unicode. Unicode took a year or more to do. Maybe RGB will take many months to do, but it can definitely be done.

Personally, I'd rather add scriptable image support to channels/queries first. Then people can script emoticons into their clients and others can use it for displaying things like warning images on errors or whatever else they might want to display for a local theme. But I wouldn't be surprised at all to see RGB in mIRC somewhere down the road.

My point was never that adding RGB syntax was "impossible", so I don't know what you're arguing. The issue is that there are a huge amount of inconsistencies, problems, blockers and edge cases that will make scripting with 2 distinct syntaxes much more difficult, and, in some cases, impossible, if you were to overload Ctrl+K.

One of the impossible cases:



I explained why:



You cannot assume, even when echoing local data, that your local data will only use a single format, because although you might be displaying data locally, you cannot guarantee that the data does not come from a remote source (and therefore unfiltered). As I pointed out, a good example of this is an ON TEXT event. If you do (echo -R being the fictional "enable RGB syntax switch"):



You cannot guarantee that $1- will not contain palette based codes. In fact, it's highly likely that they will. We had this same problem in 6.x when scripters would put $chr(160) in their themes, breaking Unicode lines because the $1- was interpreted as invalid unicode, since encoding was based on the entire line being valid UTF8. This is a case where /echo might be local but depends on remote input that you cannot control. You therefore need to support mixing the syntax, otherwise the feature would be extremely limited, as I originally stated. The only way you could fix this would be to manually convert every palette based code to RGB syntax, which would be quite complex, and still not entirely predictable.

Consider another example, of entirely local /echo with absolutely no remote data, but rather, input from your user only. Let's say it's a local game script, but your script has some options for the user:



You want a colourful name, so you add control codes. There's no reason why your script can't handle control codes, so you want to support this. But you also use RGB syntax when echoing data:



The issues with palette based code mixing are obvious here, so you would consider converting the colours to RGB syntax. However there are less obvious issues here, namely, you don't even know if the input is going to be a palette based control code syntax. The user could be aware of RGB syntax and wants to use that in his player name. You can't only support one or the other-- I mean, you can, but this is the kind of thing that makes scripting difficult and riddled with gotchas.

Obviously the real solution is a new control code, but I'm personally against that, and I don't think other clients (and servers, since they have to strip this stuff out too) are going to enjoy having to update their code to support yet another colour syntax.

Final note: this is not the same as the Unicode conversion. mIRC's conversion to Unicode was a completely internal change that for 95% of scripts did not affect a single line of code, and for the other 5% only affects a few lines that used $chr()s over 128 for whatever reason. The result was that you could begin to use Unicode in more places without needing any changes to your scripts (in fact, it actually fixed long standing incompatibilities like the $chr(160) issue I pointed out above). Changing the colour syntax in an indistinguishable manner via a line switch causes weird side effects all over the place that are not containable to the original point of usage, not without extreme diligence and modified scripts to support the new syntax. This is very different. You can't just start supporting RGB syntax in your script without the side effects leaking out to other parts and having unintended backwards incompatible behaviours. Logging to RTF format is one of those backwards incompatible changes. What if a user WANTS text based logs? mIRC should obviously still support this via switch. In that case, you still haven't answered how the syntax would get logged-- or even how the data would get copied (which wouldn't even be an RTF problem).

It seems to me that it would make more sense to come up with something other than $chr(3) to allow for multiple colours on a line.

Given that mIRC would likely use a new switch to specify that RGB colours are being used, the formatting options are limitless.

//echo -aR [color:16777215]a[/color][color:255]b[/color][color:0]c[/color]

There's no reason why something like this couldn't work. I'm not saying that's a good way of doing this, just using it as an example.

I'd do it a bit differently. I know mIRC supports colours from 0 to 99 already; it just repeats every 16 colours. I don't see why 20 through 83 can't be used for a 6-bit colour palette, with 16 of them being the original 0 through 15. However, those 64 colours should be locally customizable.

See: EGA Colours

There would be a lot of duplication / wasted indexes if you just appended the EGA palette on top of mIRC's. That seems like a poor use of the precious index values.

Since when? Nothing from ^K16 to ^K99 generates any colors for me. For me, ^K16 to ^K99 act like ^O but without also undoing bold/italics/reverse/underline. They all "undo" color, resetting a line back to its default color.


Heaven forfend. Let's please not unearth that relic. It's little more than a set of 4 variations of the original CGA/EGA text mode color palette.

If there is going to be an extension of the IRC color code system, it should either be:

* Direct RGB, and to balance excessive color control code lengths against color granularity, it should probably be a 4096 color RGB system using a brand new color ^control code + "000" through "FFF" [+ "," + "000" through FFF"]). This would limit each code's length to 8 characters maximum (4 when background color isn't also given) while otherwise still offering extremely fine-grained color selection (for a text medium, anyway).

Or:

* A carefully designed, non-customizable, 82 color palette compatible with the existing ^K system (by using values 16-98, saving 99 for transparency). I say non-customizable because one of the main complaints people have with ^K00-^K15 is that nobody can ever be sure which colors they will produce in other users' clients. If the IRC color code system is to be extended, the new color range should not be allowed to inherit that problem. To compensate for the inability to customize it, it should simply be carefully designed: so as to be "chromatically unbiased," with every possible primary, secondary, and tertiary color represented, and each one in multiple luminosities. Doing that would actually eliminate most desire to customize, since with such careful palette color selection, people will already be able to find very close matches for whatever hues they actually desire.

Personally, I prefer the second option. And the reasons are the disadvantages of the first option. Direct RGB most definitely will require a new ^control code followed by up to 7 characters, for up to 8 characters total. Unlike the recent addition of ^I for italics, where old clients only see one strange character per use, the sight of ^?XXX,XXX will cause much more offense to those using older clients, especially in cases of multiple invocations (think colorful channel topics). People will take sides, bots will be scripted to auto-/kick, ad nausea. Also, IRC daemons with color code-stripping and color message blocking channel modes will require updates to handle stripping and blocking of the new ^?XXX,XXX format RGB codes.

Comparatively, isn't it true that most (if not all?) existing IRC clients treat ^K16-^K99 the way mIRC does (by treating ^K16-^K99 as "go back to line's default color")? If so, the ^K16-^K98 palette method would not heap plagues of control code gibberish upon users of older clients. (The worst ^K16-^K98 would do is cause older client users to see no color where color should exist. King Legibility, though, would be preserved.) Also, most IRC daemons with color stripping (or color message blocking) channel modes either look only for ^K, or simply parse for and strip "^K##,##". So the ^K16-^K98 palette method would require no updates in most of their cases.

On that note, I put this together. Please note: while I can pass tests like this one with flying colors (pun intended), I do not own a professional, ISF calibrated monitor. As such, the palette color values you see in the image below should be treated as extremely "alpha" -- requiring fine-tuning by someone with both excellent color sensitivity and a big, expensive, accurate display device. Nevertheless, even in its "alpha" state, this palette still nicely illustrates the effectiveness of the design goal stated above (offering multiple luminosities of all the primary, secondary, and tertiary colors). Done that way, it's very hard to argue that even more colors could be necessary for a text medium.

The problem is that whatever new colour indexes are added have to be customizable. This is one of the most important requests in each colour discussion. Users want local use colour palette that they can modify to fit their schemes. There is not nearly enough granularity in your proposed palette to back off from customizable palettes, and therein lies the rub.

IF mIRC adds colour codes, they need to be private use. In other words, they should not be meant for sending data over servers. Frankly, I think we have enough colours in 0-15 to represent "colours" on IRC-- what we need is colours 16-98 that can be reserved for local client usage. That way, mIRC would not use 0-15 for echoing local data and instead use codes 16-31 (or fewer) to represent the various event types.

For instance, $color(info) would be mapped to 17 instead of 2, $color(ctcp) would map to 19 instead of 4, etc.-- this would allow every event type to have its own colour code, rather than multiple events sharing a single colour (like join/part/kick/modes). It would also let users change the event colours without affecting colours coming from users, since the indexes are separate. And being local only, it will have no effect on the existing control code support in other clients, since nobody else will be seeing codes above ^K16.

Of course, we could meet in the middle here and reserve a smaller set of values for "local use" while still extending the "remote colours" range to ~64 or so. 32 local colours should be sufficient for a client side scheme, although it does cut it a bit close (there are 20 event types in Alt+K, which would mean about 20 separate local use colours would be reserved for these events under my proposal, leaving only 12 for custom script usage).

Alright, I understand your thinking and can say that I mostly agree. One exception however: if mIRC ever does introduce private use colors, they absolutely should not use the ^K#[#],#[#] format. That would automatically harm future efforts to expand the over-the-wire IRC color palette, which would undoubtedly seek to use any or all of ^K's presently-free values. No client should hog a public resource to itself, even partially.

That being said, as long as a private use system wasn't limited to the boundaries imposed by the ^K#[#],#[#] format, it could be a true RGB system: perhaps using a format like ^K#FFFFFF (where # is literally the # symbol).

Ideally, both ideas could be implemented simultaneously. I still think the 16-98 palette idea I proposed above has merit in two ways: because (IMHO) 16 colors aren't enough, and mainly, because a non-customizable palette would at long last bring color consistency to IRC: knowledge that the colors you were sending out were being seen as you sent them.

(A thought: because the palette design I propose is still very granular -- multiple luminosities of all primary, secondary, and tertiary colors, it would also be possible to create a CTRL-SHIFT-copy function if both systems were simultaneously implemented. CTRL-SHIFT-copy would scoop up all ^K codes verbatim (as CTRL-copy does now). CTRL-copy however would be changed to assume you intend to paste what you've copied back into the channel/query window, and would replace every local ^K#FFFFFF code encountered with the ^K#[#],#[#] color having the nearest-matching hue. This would solve the problem of "how would CTRL-copy deal with local colors?".)

I suppose this is possible, but it would introduce backward compatibility issues. How wide-spread those issues would be remains to be seen, it would be up to Khaled to figure out if it's worth the effort or not. I personally don't mind a palette system, and, in fact, I think it's better than hardcoding colours, especially because one of the benefits of a palette is that it's tied to user settings, not the script itself. In other words, if a user wants to apply a different theme to their local colours, mIRC could theoretically reapply the new colour scheme to an existing window by redrawing it with the updated palette-- which would not be possible if colours were hardcoded by scripts. For that reason, I disagree with this on "best practice" rationale, not for technical reasons. We would be moving in the wrong direction if mIRC encouraged users to hardcode colour values in /echo and the like. Think about what would happen if a script hardcoded some shade of blue because the exact variant wasn't in the palette, rather than defining a special index for it. Then, if a user wanted to change their background to a similar shade of blue, things would get messy really fast. Hardcoding things always reduces customizability and resiliency to change. We want to avoid that as much as possible, and indexes are the best way to do it.

That said, I don't think we disagree about the need for a standard colour system for remote messages. This is exactly why I suggested we reserve only the indexes ABOVE 15 for local use. Users would no longer be able to redefine 0-15 (or whatever the remote usage palette size is), which would solve the "standardized colour scheme" problem, but would still allow scripts to have an abstraction for colour schemes that are not hardcoded to specific colours, which is important for scripts to coexist with user settings (and other scripts), as mentioned above.

Finally, the copy paste idea might work, but again, because I disagree with the benefit of rgb colour codes, I don't really see the value. 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. This is important since the users who use colours are more often the less technically inclined, and if you changed the behaviour and started throwing invalid colour codes into their copied text, we would start seeing messy invalid codes creep into public messages. Presumably, mIRC could auto-convert ^K#NNNNNN codes when sending outgoing messages too, but now we're adding extra layers of complexity into the program simply to solve the unnecessary complexity we just added.

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:


That's what I said. 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

$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.

I still disagree with your proposal of using only 0-15 for legacy compat. 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. Local colours are the issue, I think... and as I pointed out, there are already 20 local events that could benefit from having their own separate index, which is already more than the allocated space, and that doesn't even count any user defined colour codes. User defined colour codes being the most important part here.

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. Local changes can be made much more easily.

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.

I think an IO routine would be more appropriate though, and would be needed anyway, since those codes could leak out no matter what. For example, a script could accidentally or even intentionally send ^K<localuse> codes if that data is being shared for both local and remote usage -- see my example to Riamus a couple posts back regarding storing of user input variables.

Agreed, it wouldn't be worth it.


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.


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?


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.


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.)

A long time ago, I drew up a palette for 256 colors that expands on the standard 16 mIRC colors, and I'll just post it here as a possible suggestion. I'd like to see your opinions on it, positive or negative.

It adds in hexadecimal numbers and is numbered from ^K00 to ^KFF, but the original 16 colors remain in their spots, from ^K00 to ^K09 and from ^K10 to ^K15.

It has no duplicates or spaces left over, and has the following types of colors:
* 16 standard mIRC colors
* 216 6*6*6 RGB cube (aka "web-safe" colors)
* 6 tertiary colors of the rainbow
* 6 darker versions of the tertiary colors
* 12 quaternary colors of the rainbow
* 16 shades of gray

The set of colors was made by first inserting the mIRC colors where they would be if represented as decimal, at 0x00 to 0x09 and 0x10 to 0x15.

6*6*6 RGB colors were calculated and inserted at the end of the set, beginning on 0x28. The duplicate colors in the cube were removed, and replaced with 8 other shades of grays not already in the set.

Tertiary hues were inserted at 0x0A to 0x0F, and darker versions of these were inserted at 0x1A to 0x1F. Orange was replaced with the darker version of yellow at 0x0A, because that did not exist in the mIRC colors. Finally, the quaternary hues were inserted in the remaining spaces, at 0x16 to 0x19 and 0x20 to 0x27.



It's nearly fully compatible with the original ctrl+K colors and takes up the same amount of space, assuming you always used two digits for the colors.

However, it has a few disadvantages. It doesn't have any space for private indices (can get rid of the rainbow colors and shades of grey for that), lacks a transparent color, and a 6x6x6 RGB cube is probably not the best for displaying a large and perceptually uniform range of colors.

Normally I'd prefer a full 24-bit color set for IRC, as that's extremely simple to achieve, except that the IRC protocol has an imposed message length, and it would necessitate a new control code for them.

pishposh, I think your idea comes close to what should be done.

We need to keep things simple.

00-15 should be legacy. These numbers are already mentioned in the EGA Color Table.
Ignore the numbering scheme for the sixteen colours in the graphic.

16-63 should be the other 48 colours in the EGA colour table.
There is no need for redundancy in having the first 16 colours twice.

64-75 should be for shades of gray.
Since 000000 (black), 555555 (dark gray), AAAAAA (light gray), and FFFFFF (white) are already included in those 64 colours above, that leaves 12 shades of gray in 4-bit grayscale.
111111 ... 444444, 666666 ... 999999, BBBBBB ... EEEEEE

76-95 should be for local customizable colours.
Of course, some people may use them remotely, but oh well.
I do agree, 20 seems like a good number.

96-98 should be reserved, otherwise more local customizable colours.

99 should be for transparency.

+1 to Doomstars' proposal.

This could be done via how the browsers do it, say ^k#ff8d8t then mIRC could internally interpret the colorcode from that to display the text in that color within other mIRC clients.

Other clients would just simply show #ff8d8t as apposed to the actual color, so it would not break other IRC Clients, unless they standardized the colorcode format across their irc clients.

Well thats my 2 cents anyway.

No-- this would not be backwards compatible. This would break mIRC users as well.



Not properly displaying a colour is the definition of breaking a client. The idea that a client is not "broken" because it falls back to displaying regular text isn't exactly a good argument on a text-based protocol. This was the same argument made by MS Comic Chat, but that only led to the client getting kicked from every channel because nobody else could parse the gibberish coming from those users. It's just not a good experience for other clients.

overall reply:

I think at some point, mirc needs to break away from older clients so it can advance. It did it when breaking away from 16bit OS, it did it with codepages, and it's doing it with other things. Sticking to an antiquated standard just because it's the standard (and nobody cna agree on a new one) halts progress. This same argument was used for Italics and we have that now too. Personally, I think if mirc was the guiding light for colors, everybody else would quickly follow suit due to how popular the clieht has been for the past 20 years.

No, I don't code anything I need to support by millions and millions of users, but if I did, I would have the same approach, "In the future, here's how things will work. You have the choice of either upgrading (if you can), or staying where you are. In the case of colors and mirc, if it was me, I'd send a message, to all my registered users, with a website, which had a script that would work for older mirc's to take the new method and parse it back to the old method.

If mIRC is made to support 24-bit colors (^k#000000-^k#ffffff), then it ought to also support longer messages; much longer than the IRC protocol's limit of 512 characters and mIRC's limit of (somewhere around) 1000 characters. This is necessary for both 24-bit colors and Unicode text.

It's possible to write an IRC server that allows for messages longer than 512 characters (I have done this already), and most other IRC clients (X-Chat and irssi for example) support messages of arbitrary length. mIRC oddly enough does not.

This is patently false and also misleading. mIRC supports "arbitrary" sized messages, though if you have an on input script it would limit to 4k. mIRC will break up the lines into ~450-500 char chunks by default, but this can be disabled via options. What you are probably complaining about is the editbox beep that goes off when you go past the ~500 char length limit. This does not disable you from writing more, it's simply a notification that your line will either be truncated or split.

More important however, is the comment about servers being able to support >512 chars. Yes, you *can* write a server that supports arbitrary length lines. The reality, however, is that few servers actually modify this line length. Most networks limit lines to around 512.

Khaled doesn't control how IRC servers behave, so the idea making colour codes 6x longer on average is going to force IRC networks to increase their line length is false. It will simply mean users will only be able to fit a third to a sixth the number of characters in a message that relied on the heavy use of colours. It doesn't matter how long a line mIRC can send, because servers will still work the same way they have for years.

Here's a few screenshots to show what I'm talking about:

• mIRC: http://i.imgur.com/QDbXJDm.png
• X-Chat: http://i.imgur.com/tYaBzJt.png
• IRSSI: http://i.imgur.com/QVYmzEm.png

The mIRC in that screenshot is a freshly-installed one, version 7.29, with no scripts installed aside from the ones that come with it by default.

It turns out I was incorrect about X-Chat supporting messages of arbitrary length, but my point still stands. IRSSI shows the original message in its entirety, and mIRC truncated the message coming from the server to 983 characters.

I know this won't make existing IRC servers support longer messages unless the hosts decide to implement support, but it would be beneficial to those who do use servers that explicitly support messages longer than 512.

And it would encourage existing server owners to make their server support longer-than-512 messages, because more IRC users can view them.