-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Colour markup ignored after linebreak #1755
Comments
Please give version 10.16.1a1 a try:
Although you've definitely found a bug, your code is a little odd. Markup tags should really be closed. i.e. for every |
That works! Thanks for the speedy fix! Re. closing the tags, I think I just had brain fog and was thinking about ANSI/fish/tmux etc. where any new colour settings just overwrite the old ones. In other words, wasn't thinking in "markup" mode. I'm really glad there was a real bug and I didn't waste your time because of that. All the best, Will! |
Did I solve your problem? Consider sponsoring the ongoing work on Rich and Textual. Or buy me a coffee to say thanks. |
10.16.2 Fixed Fixed @ not being escaped in markup 10.16.1 Fixed Fixed issues with overlapping tags Textualize/rich#1755 10.16.0 Fixed Double print of progress bar in Jupyter Textualize/rich#1737 Added Added Text.markup property Textualize/rich#1751
Describe the bug
I'm using Textual to monitor the generation of a map for an experimental game in real time however this is an issue with Rich. I've found that Rich doesn't appear to output the requested colour after a linebreak.
Here is a minimal code sample to reproduce this:
And here is a screenshot of the output:
Most obviously you can see that the
[on orange4]
tag, which works elsewhere, does not set the colour at the start of the penultimate line. But you can also see that the tree at the start of the fourth line up is intended to be on a green background but is not. The common factor in many cases I've encountered is that the code immediately follows a linebreak. On the third line up you can see the difference when a space precedes the tree.A workaround is to end each line withUpdate: I couldn't, in fact, make this work nicely.[default on default]\n
(note the final space which starts the new line and makes following tags work). This adds a (default) left border and means resetting the actual desired colour anew on each line even where it hasn't changed from the end of the preceding line. This overhead adds a lot of bytes and complexity and makes Rich do unnecessary work processing the extra tags; on a fullscreen map refreshed every second in a live/Textual context this might become unpleasant.Platform
I'm on Linux. This happens in both
gnome-terminal
andalacritty
, with or withouttmux
running.(Thanks in advance and good luck with Textual; it's very exciting!)
The text was updated successfully, but these errors were encountered: