Skip to content
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

Closed
yfeldblum opened this issue Aug 2, 2011 · 13 comments
Closed

HighLine#list formats columns too wide #14

yfeldblum opened this issue Aug 2, 2011 · 13 comments

Comments

@yfeldblum
Copy link

HighLine#list in :columns_across mode makes each column at least as wide as the widest element in any column.

> list = %w(1 2 3 4 a b c d asdf1234 f g h)
> puts HighLine.new.list(list, :columns_across, 4)
1         2         3         4
a         b         c         d
asdf1234  f         g         h
 => nil

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 width 8, so the width of columns[0] overall should be 8 + padding. The widest element in columns[1] has width 1, so the width of columns[1] overall should be 1 + padding (rather than 8 + padding, which it currently is).

1         2  3  4
a         b  c  d
asdf1234  f  g  h
 => nil
@practicingruby
Copy link
Collaborator

That sounds right to me. Please prepare a patch and I'll take a look at it.

@JEG2
Copy link
Owner

JEG2 commented Aug 2, 2011

That said, I think the old behavior does have some merit. Perhaps we could have an option to go either way?

@practicingruby
Copy link
Collaborator

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.

@yfeldblum
Copy link
Author

The current behavior would be preferable when the columns have similar max element widths. In that case, having columns with widths of [8, 9, 7, 9, 7, 8] might be a little distracting, while forcing the widths to [9, 9, 9, 9, 9, 9] might be less distracting.

However, where the columns have rather different max element widths - [8, 36, 1, 1, 10] - it is better to keep the widths rather than to force them to [36, 36, 36, 36, 36].

@yfeldblum
Copy link
Author

The example of [8, 36, 1, 1, 10] is based on a real-world example from the knife-rackspace gem for the command knife rackspace server list (the ui method returns a HighLine instance).

@JEG2
Copy link
Owner

JEG2 commented Aug 2, 2011

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.

@yfeldblum
Copy link
Author

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.

@JEG2
Copy link
Owner

JEG2 commented Aug 3, 2011

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?

@yfeldblum
Copy link
Author

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 knife rackspace server list that know their grid columns can have highly variable widths can customize the behavior to suit.

Best of both worlds.

@JEG2
Copy link
Owner

JEG2 commented Aug 3, 2011

Agreed. It's an easy patch. Can you put it together for us?

@JEG2
Copy link
Owner

JEG2 commented Nov 5, 2011

I added :uneven_columns_across and :uneven_columns_down as modes for list().

@JEG2 JEG2 closed this as completed Nov 5, 2011
@yfeldblum
Copy link
Author

This patch seems to work fine in the usual case.

ruby-1.9.2-p180 :007 > a = %w(Blah a b c ad e fs f g)
 => ["Blah", "a", "b", "c", "ad", "e", "fs", "f", "g"] 
ruby-1.9.2-p180 :008 > puts ui.list(a, :uneven_columns_across, 3)
Blah  a   b
c     ad  e
fs    f   g
 => nil 

However, when there's bold formatting on the first row, it doesn't seem to work right:

ruby-1.9.2-p180 :009 > a = [ui.color("Blah", :bold), ui.color("a", :bold), ui.color("b", :bold), "c", "ad", "e", "fs", "f", "g"]
 => ["\e[1mBlah\e[0m", "\e[1ma\e[0m", "\e[1mb\e[0m", "c", "ad", "e", "fs", "f", "g"] 
ruby-1.9.2-p180 :010 > puts ui.list(a, :uneven_columns_across, 3)
Blah  a  b
c             ad         e        
fs            f          g        
 => nil 

@yfeldblum
Copy link
Author

One specific use case for this issue is the knife-rackspace library. Example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants