Bug #144

ANSI colors aren't processed correctly

Added by Francisco Del Roio over 1 year ago. Updated over 1 year ago.

User interface
% Done:


Contact person:
Additional contact persons:



I see that when the `rich text` and `Screen Reader support` checkboxes are enabled an disabled, respectively, the ANSI sequences aren't processed correctly, at least for the MUD I play.

For example, I have this line:

* Pies: Par de Botas de Guerra \x1b[31mSangrientas\x1b[0m.\x1b[0m

If I open the client the word 'Sangrientas' is not red-coloured as in my original client.


Associated revisions

Revision dc5fb9be (diff) View on GitHub
Added by Francisco Del Roio over 1 year ago


  • Method `OnMessage` rewritten completely.
  • Method `OnPostMessage` adapted for changes I did in `OnMessage`.

I think that these changes fixes #144.

Revision dbdcf21d View on GitHub
Added by vincent-lg over 1 year ago

Merge pull request #15 from francipvb/i144

Tiny changes for #144


#1 Updated by Vincent Le Goff over 1 year ago

That's one feature which I had trouble developing, so it can be off or not even working properly. You will find it in source:src/accesspanel/extensions/, if you ever want to check it and try to modify it.

#2 Updated by Francisco Del Roio over 1 year ago


I was playing with this some time but I didn't figured out how to do this.

I coded some working solutions, but they are too slow to be usable, at least for me.

The best approach would be a stream way (without regular expressions), but we'll need to recode the entire process from scratch.


#3 Updated by Vincent Le Goff over 1 year ago

If it's not working, it doesn't bother me to take it down. It's an AccessPanel extension because AccessPanel used to be a standalone library (it's still on Pypi as a matter of fact). However I kept it in CocoMUD itself this time because it's not easy to port anyway. So if you want to take the extension down and create something else (either another extension, or another system altogether), don't hesitate. It has never been a side of the client I could extensively work on but it is still useful. With ANSI support we might like to add Xterm support in the end, but that's not for today.

#4 Updated by Vincent Le Goff over 1 year ago

BTW: if you want to talk on the chat, we can do so, no problem, we'll just need to schedule a time because we might not be on the project at the same time!

#5 Updated by Francisco Del Roio over 1 year ago

Hello again,

I was thinking so much about this issue. Initially I thought that the process of taking ANSI codes needed to be just at client in Client.applicationDataReceived, but this approach could be problematic and would lead to so much code complexity.

I'll try to play again with the ANSI extension and see if I can fix those problems.

OFF-TOPIC: What is your timezone? Please tell me when you have some time to chat.


#6 Updated by Vincent Le Goff over 1 year ago

I would prefer editing the ANSI extension if possible, since extensions are here for that, though I agree it could be somewhere else. This has the advantage to not slow down CocoMUD in non-rich text window (which is the advisable setting for accessibility if you don't care about the colors). I know regexes aren't that fast, but I don't know if you really can tell the difference with the way the extension uses them. Of course, if you find something more optimized, this would be great altogether.

I'm in GMT + 1, so any time this afternoon (for me) would be okay (it's about 1:30 PM right now). I will have to pause in 4 hours, since I have a meeting on another topic, but apart from that, you can just tell me what works for you.

#7 Updated by Francisco Del Roio over 1 year ago

  • % Done changed from 0 to 90


I think that it's solved, but needs more testing to confirm that it works perfectly.


#8 Updated by Francisco Del Roio over 1 year ago

  • Status changed from Open to Closed
  • % Done changed from 90 to 100

#9 Updated by Vincent Le Goff over 1 year ago

  • Status changed from Closed to Feedback
  • Assignee set to Francisco Del Roio
  • Sprint/Milestone set to 16
  • % Done changed from 100 to 80

It has been merged into master in commit 05cb04d96c46d77cb369709110e37da518262385. I cannot test much for the time being, but if you have the opportunity to test it more, we'll close this and move the issue to the current sprint. The most important things to check are:

  • Are colors positioned right? Check that colored words begin and end where they should, this includes when the colors are on the first line of output, or the next lines. Unfortunately new lines tend to pose an additional challenge.
  • Is it still true after receiving many messages? Again, due to the new line codes, sometimes colors shift after a few messages.

If you have the opportunity to test in several MUDs too, that would be great, just to make sure it keeps on working. I will run a test on several MUDs I know but I'm not sure if they have a lot of ANSI coloring as is.


#10 Updated by Francisco Del Roio over 1 year ago


I've tested my last changes and them solves the problems at all. I don't play other MUDs, unfortunately, but the MUD I play applies colors extensively for all things.

In the original message, the word is now red coloured, excluding the space and the period symbol at the end of the line.


#11 Updated by Vincent Le Goff over 1 year ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

Great, closing this then! Thanks.

Please register to edit this issue

Also available in: Atom PDF Tracking page