-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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] Putting a Rule in a Table cell interacts weirdly with table width and other column widths/ratios #2266
Comments
That was a very thorough assessment. I think the issue is that Rule is missing a If you were to add a It hadn't come up, so I guess nobody has tried putting a rule in a table. Would you like to submit a PR, since you got this far? |
Thanks. 😄 Partially this is just me finally learning how to properly use
I'll take a look. I'm short on time but it sounds like a straightforward fix... |
Closing, assumed fixed. |
I hope we solved your problem. If you like using Rich, you might also enjoy Textual |
Overview
There seems to be something weird happening when I put a
Rule
inside aTable
cell. Perhaps that's a weird thing to be doing in itself, but OTOH it feels like it should be possible, particularly asTable.grid
is proposed as a general layout tool forRenderable
s.The behaviour I'd expect would be that adding a
Rule
to a table cell doesn't modify the table or column widths from what they'd be without thatRule
being present — but that's not what's happening now, AFACIS.(Of course layout is a Hard Problem, so this might be one of those edge cases where you end up playing whack-a-mole...)
Anyway, here's the weirdness; there are three main things, but I guess they're related so I report them together:
A
Rule
in a table cell seems to effectively forceexpand=True
on the table — even if it's explicitlyFalse
.If a table has
expand=True
, a rule in some column causes that column to take up as much width as possible.Rule
, they'd be symmetric with it.(This one's real weird.) If a table of two columns has
ratio=1
for one column, and if the non-ratio
column contains aRule
, that completely squashes the first table column to a single character width (and we also get theexpand=True
forcing described above).ratio
don't seem documented in cases where some columns haveratio
set and some don't (?), but it seems like something sensible happens, at least when there are noRule
s involved, i.e.:expand=True
, columns with noratio
take up as little space as possible. Seems optimal. ✅expand=False
, theratio
s make no difference. Makes sense I guess.Example
I set myself up a playground for exploring this. The main thing it enables is the exploration of this space of options, in the context of a table with two columns and three rows:
Table.expand
isTrue
orFalse
.ratio=1
or noratio
set.Rule
or some text.Those were the main things; I also explore less fully:
min_width=10
or nomin_width
set.min_width=10
or nomin_width
set.Show/hide example source code
Output of example
Of course the example code uses
rich
, so... 😄Show/hide SVG output
Show/hide plain text output
Discussion
Tables which don't surprise me:
Table 1 — not much to say, not much going on here. 😄
Table 3 — makes sense that
ratio
is inapplicable if the table isn't expanded or has nomin_width
.Table 5 — also not much to say; nicely symmetric.
Table 7 — this shows
ratio=1
causing column 1 to take up as much space as it can, which makes sense to me if noratio
is set on column 2.Table 10 — this demonstrates that the
Rule
doesn't squash amin_width
column, which is a relief.Table 11 — similar to table 10, except here the
min_width
is on column 2, not column 1. OK.Surprises:
Table 2 — as soon as a
Rule
appears, it's as ifTable.expand=True
even though we set itFalse
. I'd expect this to look like table 1 but with a small rule in place of theXXXXX
.Table 4 — similar comment, but here we also have
ratio=1
so if theRule
being there did expand the table, I'd expect column 1 to take up the width, not column 2.Table 6 — I'd expect this have the same column widths as table 5.
Table 8 — this is the big one — here we've set
ratio=1
on the first column, and now the rule completely squashes it. This is the example I hit in my actual use case... a real WTF moment. 😄Table 9 — minor surprise here, and nothing to do with a
Rule
— just wouldn't expectmin_width
to cause asymmetric columns here. Maybe a separate issue report is in order here though...?Again, maybe all of this is basically expected behaviour; the
ratio
semantics seem loosely defined, and perhapsRule
is simply not intended to be in a table. But if the latter is true, it reduces the utility ofTable.grid
for layout.None of this is world-ending, but I thought it was worth exploring at least...
Finally, thank you 🎉 for such a useful and well-constructed tool; it really is great. I hadn't heard of
rich
ortextualize
until your interview on Talk Python To Me — really glad I did! 🙏🏻Platform info
Show/hide platform info
I'm on macOS 12.3.1 (21E258) on a MacBook Pro (13-inch, M1, 2020). I'm using iTerm2 build 3.4.15. And as the example code shows:
Diagnostics
and:
$ pip freeze | grep rich rich==12.4.1
The text was updated successfully, but these errors were encountered: