You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 with [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. Update: I couldn't, in fact, make this work nicely.
Platform
I'm on Linux. This happens in both gnome-terminal and alacritty, with or without tmux running.
Although you've definitely found a bug, your code is a little odd. Markup tags should really be closed. i.e. for every [foo] you would expect there to be a [/foo]. Your code above has lots of overlapping tags.
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!
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: