Bleeding note colours onto basic text

I've noticed it before at times, but it seems to have gotten a little worse with this update.

When you do a world.note, or even a world.send that outputs in (?almost any) colour, the next line can have it's colors altered slightly.

The hilite code seems to go missing or turned on inappropriately at times, and if the basic text is non-ansified, then it changes into the color of the prior client output.

I know one of the times I've always seen it happening is when I have client output, then gag the next line. The one following that(the first one appearing) will show up with it's ansi altered.

I'm pretty sure the mud I'm connected to sends it's ansi data at the beginning and end(or across lines where appropriate), so there's nothing strange going on there that could affect it.

If anyone else has noticed this, please drop a post.

Yes.. Common problem. I fixed it where I was bothered by using a last colourtell or note that sent a space with the attributes set to the clients ansi settings for low-white on black. (This means reading these settings, since in a plugin the client's settings for 'normal' background and white may be changed by the user). I was not aware of the hi-color/lo-color glitch though.. :p The problem seems to be that mud designers often get lazy and make some lines send without leading ansi, assuming that the prior line 'must' have ended with ESC[38;40m. The problem is that world.note and the like commands do not terminate what they send with such a sequence to return to the 'normal' colors as mud sent lines do, so the next line 'inherits' any color settings, including the 'bold' attribute that sets the colors to the hi-color mode.

Perhaps world.note and world.colournote should act as though they where sent by the mud and set the current color to the NormalColour(8) on NormalColour(0) settings of the client? It imho makes no sense for the client to handle such things by ignoring the 'standard' method of terminating lines with such a return to the basic colors. Of course this 'could' cause side effects on muds where they cheat in the 'middle' of a paragraph, so maybe a 'reset to last color attributes' would be better, since then even if they set things to green on yellow the next line after the note would end up being the right color. In any case, the fact that it doesn't correctly terminate with a reset of the attributes is an inconvenience at the very least and 'non-standard' behaviour with respect to how ansi is normally handled.

Well, not really. I had a bug report a while back because I was resetting colours to defaults on a new line, when the MUD had set (say) green on black, and expected it to stay that way while it drew a nice big ASCII picture.

MUSHclient is supposed to remember what the current colours are, however I will admit that in situations where you sprinkle in world.notes, and then add to the confusion by omitting lines, perhaps it gets a little lost.

Strictly speaking, in a sequence like this:


blah blah - ends in blue on grey (from the MUD) <-- not omitted
blah blah - ends in red on green (from the MUD) <-- omitted
A world.note here in some strange colours
xxxx new line - should still be in red on green


However having said that, I can now reproduce a problem where in that situation above the last line (without ANSI codes) is actually carrying forward the world.note colour, not the last output colour. I will investigate this forthwith.

Thanks.. This one has been around for some time now and was mildly annoying. ;)

I think I found it at last. It was another instance of where there was a newline (\n) inside a single packet, the code did not correctly restore the line colour after a world.note. However it would work if the line was in a new packet.

I have moved the code which is done at the start of a packet, to a separate spot, and do it in both cases now.

This should hopefully fix up those annoying and occasional problems. Please let me know if it doesn't.

I've been able to replicate the instances in which I've seen the bleeding colors previously and I'm happy to say that no more bleeding is occuring at this time.

Thanks Nick. As usual, great job. :)