Bold color remaining even after darker color specified

This is a relatively minor thing, but annoying nonetheless. When a color is set to bold and shown on screen, a color after that that "inherits" the bold setting, even if it doesn't have the bold flag itself.
Example:

In a ProtoMUCK server & MudOS server running a LIMA mudlib, the usual "standard" ansi flags are esc-char [ then color setting. \[[1;37m in protomuck for bright white. So if you have a sentence that starts with \[[1;37m Hi!, the word Hi! will be white. But if you go after with \[[32m, which is dark green, it will show up as bright green, as if bold was never shut off properly. Using the reset ([0m) -does- let it use dark colors, but you must use it everytime. It just seems to me that if another color is chosen, the client should forget the previous color setting after that new color is chosen.

Wrong..

There are numerous reasons for it working the way it does. One such reason involves the 'pre-ansi' hardware which actually hard the data for each line limited to a specific numer of characters 'and' attributes. If you wanted a line to be green and flashing then you could do it, same if you wanted part to be blue and part green, but every 'change' you made in the formatting required an imbedded code that took up a space in the screen. No color ascii art on those systems...

Later when ANSI was introduced the implimentation was changed so that the memory was 2 bytes per letter (3 for systems that allowed a background color). I.e. 1-2 bytes to store color attributes and one to store the letter itself. This is how the original hardware based ANSI works 1 bit for bright/dark and 7 bits for color. Other specialized displays would give you italic and other things, but at the expense of not being able to have anything but one color for all text. However, they still chose to make it so that attributes once set/reset would continue on to the next change. Thus allowing you to use 'bold italic', then 'unbold' and still have 'italic' working. They made colors work the same way and for the same reason.

Changing the way it works in Mushclient would break any of the uncountable muds or other telnet locations that use the existing implimentation. This is not after all something Nick invented or has any control over and it has worked this way for at 25 years or more.

Wrong? Why is mushclient the only client I've seen that exhibits this behavior, then? I don't understand your reasoning that it would break countless muds and other telnet locations, when it would break nothing. Here's the problem, if something comes after the bold attribute is turned on, then it always keeps that attribute until the entire string is "reset". But when you choose a non bold color, it -does- reset on the server. When the server shows it to you, it's showing you the dark color. But the client itself is showing the bold color only. There are any number of ways to show this, not the least of writing a muf program on a muck server that spits out a string of ansi color codes, bright AND dark mixed, then check with various other clients. Even the standard telnet client resets the color -on your screen- properly. MUSHClient is the only one that I've seen do this, so how could it possibly "break" anything to make the client reset itself when it gets a new code?

Umm. Ok. Then maybe something is going on here. But [32m is technically just specifying a 'color change', it does not include the 0; or 1; needed to change modes. Technically it should not change both the color and font attribute when you only specify color. DOS ANSI didn't work like that, nor did 'any' application used to access BBSs or telnet that I am aware of. If other clients are doing it, then they are 'not' following the ANSI specification and neither is the muds they are being used with. ANSI does not turn off any font attribute that has been set unless 'you' specifically tell it to do so. It was always well understood that all ANSI lines should terminate with \[[0;37m to restore the default ANSI color. Not \[[37m, but \[[0;37m. If ANSI is being used correctly now, then why does every single program from as far back as 20 years ago and every manual I ever read that describes using it say that you should do that?

However, this would not be the first time the developer of some mud or muck assumed that they had correctly implimented something because the designers of most clients are too damn lazy to properly follow the specifications of the protocal. This may sadly be the same sort of side effect that you get with MXP clients that show the invalid tags, instead of correctly rejecting them because they are invalid and some fool didn't bother to use &lt and &gt. But I will leave Nick to argue any more about this, since it isn't up to me how to handle broken implimentations from people that code a program without bothering to read the protocal specifications. All I know is that it 'is' broken based on the standard set down for ANSI.

Hmm.. Ok, I think I get what you're saying. In the source code for ProtoMUCK (which is what I mostly work with) all of its predefines for colors exclude the 0 in most cases, unless you specifically tell it to "parse" a certain type of ansi code. I'm sorry for wasting people's times on this forum, and for seeming irate. I was a bit confused. Well, more than a bit, heh. In any event, thanks for the responses, though I was a bit knuckleheaded in my reply.

I'm not sure if this has been totally resolved, but perhaps I can comment on the "bold" aspect. Initially MUSHclient not only changed colour for the "hilite" code but also switched to a bold font. If this is what is bothering you, you can turn that off.

Failing that, if you can specify the exact sequence you are trying (preferably in an easy-to-reproduce way) like MUSH codes, then I can try it and compare various clients.

However I agree with Shadowfyr that the "hilite" code is supposed to persist until either an ANSI reset (zero) or a "turn off bold" (code 22).

For a discussion on that, see:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=1777

I have been testing this and all the clients I have tested so far exhibit the same behaviour as MUSHclient. I don't want to spend all day on it, but so far "terminal" on OS/X, MudMaster GUI, and zMUD all do the same thing - once something has "hitlite" turned on it stays on.

A bit more research has revealed that there *is* potentially a way of making the effects replace and not accumulate, as was originally described in this thread. There is a control sequence, that it isn't totally clear what it is, but may be:

ESC [ 21 l

(That last letter is lower-case L).

That resets the GRCM (graphic rendition combination mode) flag. After receiving this the client should take each code as replacement and not cumulative.

There is also another sequence:

ESC [ 22 h

That sets the GRCM flag, so it would do what MUSHclient currently does. Suffice to say that I hadn't heard of these before today, and MUSHclient ignores them. However after experimenting a bit with a test program, all the other clients also ignore this flag. I can't find a single client that will switch to light green under the conditions originally described, with or without the "ESC [ 21 l" code.