Description

Our ANSI markup tag processor was buggy—the handling of low vs high intensity colours was flipped. E.g., [color=green] resulted in high intensity green (light green), and [color=light-green] in low intensity green. I noticed this about a year ago, but kinda glossed over it. People somehow got used to this weirdness and marked up brown dutifully as [color=light-yellow] in the MORE command, for example. Err... 😐

Also, the colour tags used the standard symbolic ANSI colour names which I found quite confusing even with the flipping corrected:

• [color=yellow] would need to be specified for "brown".
• [color=light-yellow] would need to be specified for "yellow".
• [color=light-white] would need to be specified for "white".
• [color=white] would need to be specified for "light gray".
• [color=light-black] would need to be specified for "dark gray".

As I see it, using the symbolic ANSI colour names has no benefits; it only creates a lot of confusion and their use is rather pointless as we're operating in a DOS context where CGA colour names are the norm. Therefore, I'm switching to using canonical CGA colour names as well. For reference:

I used the attached remap-colors.sh script to remap all [color=XYZ] tags automatically to the new schema:

./remap-colors.sh src 
./remap-colors.sh include
./remap-colors.sh contrib/resources/translations

Script (change extension to .sh after downloading it): remap-colors.zip

Manual testing

Ran INTRO, HELP, MIXER /?, and MORE FOO.TXT to test.

Checklist

Please tick the items as you have addressed them. Don't remove items; leave the ones that are not applicable unchecked.

I have:

• followed the project's contributing guidelines and code of conduct.
• performed a self-review of my code.
• commented on the particularly hard-to-understand areas of my code.
• split my work into well-defined, bisectable commits, and I named my commits well.
• applied the appropriate labels (bug, enhancement, refactoring, documentation, etc.)
• checked that all my commits can be built.
• confirmed that my code does not cause performance regressions (e.g., by running the Quake benchmark).
• added unit tests where applicable to prove the correctness of my code and to avoid future regressions.
• made corresponding changes to the documentation or the website according to the documentation guidelines.
• locally verified my website or documentation changes.