-
Notifications
You must be signed in to change notification settings - Fork 137
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
HighLine#list formats columns too wide #14
Comments
That sounds right to me. Please prepare a patch and I'll take a look at it. |
That said, I think the old behavior does have some merit. Perhaps we could have an option to go either way? |
Can you come up with an example where the old behavior would be preferable? I'm sure one exists just at a loss for it right now, especially if we have a padding option. |
The current behavior would be preferable when the columns have similar max element widths. In that case, having columns with widths of However, where the columns have rather different max element widths - |
The example of |
Yeah, I think it's mostly taste. I fine the equal widths easier to grok quickly. Also, if it was numerical spreadsheet like data, lining up the numbers might look more natural. |
Taste plays a big factor. But what tends to happen in my example is that, because one column is wide (30+ characters wide, multiple times wider than any other column) and the rest are narrow, each line of the grid wraps around and fills up its own line plus half of the next line in the terminal. My terminal window is decently wide. But this makes the grid unreadable anyway. Not because there's too much data to fit in the grid, but because the grid is so sparse - because one column is multiple times wider than any other column, making every column in the grid display equally wide. I've got multiple columns which should be two characters wide each actually taking up 30-40 characters of screen real-estate simply because one of the columns is that wide. It's taste up until it forces a sparse grid to wrap. |
I totally agree with Greg, there's no reason we shouldn't patch it. I'm just suggesting we, go the distance. With one simple if, we can have it both ways, right? |
Having it both ways, controlled by an option of some kind, would be fantastic. That way, the default strategy for most programs would be to continue to assume the current behavior. But programs such as Best of both worlds. |
Agreed. It's an easy patch. Can you put it together for us? |
I added |
This patch seems to work fine in the usual case.
However, when there's bold formatting on the first row, it doesn't seem to work right:
|
One specific use case for this issue is the |
HighLine#list
in:columns_across
mode makes each column at least as wide as the widest element in any column.Some tables may have a single wide column (maybe 1/4-1/2 the screen) and many narrow columns. The method above is may work for a few columns of similar max widths, but it doesn't work very well for lists having a single wide column and many narrow columns.
Instead, this method should make each column as wide as the widest element found in that column only. As an example, the widest element in
columns[0]
has width8
, so the width ofcolumns[0]
overall should be8 + padding
. The widest element incolumns[1]
has width1
, so the width ofcolumns[1]
overall should be1 + padding
(rather than8 + padding
, which it currently is).The text was updated successfully, but these errors were encountered: