Let's say I had a script that ran print("\x1b[46;34mText"), you would assume that it would print blue text with a cyan background colour. Instead, I get white text (the text colour of the terminal) on a cyan background.
If I were to instead flip the order of the arguments and run print("\x1b[34;46mText"), the reverse problem happens where the text is blue but the background colour is black (the terminal background).
This problem applies to all types of ANSI formatting (3/4-bit, 8-bit, 24-bit).
Let's say I had a script that ran `print("\x1b[46;34mText")`, you would assume that it would print blue text with a cyan background colour. Instead, I get white text (the text colour of the terminal) on a cyan background.
If I were to instead flip the order of the arguments and run `print("\x1b[34;46mText")`, the reverse problem happens where the text is blue but the background colour is black (the terminal background).
This problem applies to all types of ANSI formatting (3/4-bit, 8-bit, 24-bit).
<img width="236" height="191" alt="Image" src="https://github.com/user-attachments/assets/4b7fee85-7261-4b25-a6a7-688385be2858" />
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Let's say I had a script that ran
print("\x1b[46;34mText"), you would assume that it would print blue text with a cyan background colour. Instead, I get white text (the text colour of the terminal) on a cyan background.If I were to instead flip the order of the arguments and run
print("\x1b[34;46mText"), the reverse problem happens where the text is blue but the background colour is black (the terminal background).This problem applies to all types of ANSI formatting (3/4-bit, 8-bit, 24-bit).
Makes sense. I think the ANSI engine is made to only process one thing at a time.