Please fix the ls situation.

[envygeeks]

I understand there is already a ticket open to improve the ls command but it would be nice if you guys could issue a hotfix (well as hot as gemcutter gets obviously) minor minor release to address the situation with ls because the lack of tabbing murders readability with sparse classes. It would be nice if you indent each line and (possibly) only \n if it has more than one or extends past the new term width.

As it stands right now, I think the new ls is a breaking behavior because it's absolutely unreadable.

[rking]

+1. Let's compile a few "what we have" vs "what would be ideal" examples. Really, I think the current output was made for ls _pry_ and not much more.

[envygeeks]

constants: 
ObjectExt  VERSION
Pry::VTermAliases.methods: 
aliases  create_aliases  run_command  term
instance variables: 
@aliases  @terminal

Looks better as:

constants: ObjectExt  VERSION
Pry::VTermAliases.methods: aliases  create_aliases  run_command  term
instance variables: @aliases  @terminal

But using the _pry_ example would look better as: (all methods are fake)

Pry#methods: 
  method1        method2        method3        method4         method5
  method6        method7        method8        method9        method10

instance variables: @var1 @var2

The idea is that if you have to split it up add an extra line so that it's easily noticeable but if you don't have to split it up the clarity isn't really much improved since the bold is easy to spot when it's all grouped up together like the "looks better as" example.

This is my personal opinion.

[rking]

Here's a real-life example of the output basically punishing a class hierarchy for being decently organized (in that there are many classes with fewer methods):

[rking]

• If you put stuff on the same line as the headings:
  • either you have to count the heading as a member of the column (making it very wide)
  • or you have complex logic, such as either displaying it all-as-one-line or as-a-block, depending
• If you put the headings on separate lines, it does the punish-for-good-practices thing a bit

[rking]

OK, so here's the 0.9.10 (previous release) output:

[rking]

Here's feature/ls-output-tweaks:

What do you think?

[rking]

Here it is with protected methods toned down more:

[ghost]

@epitron's screenshot is the best I've seen so far.

[rking]

@robgleeson What about it do you like?

[rking]

For others' reference, this is the one we're talking about:

[rking]

We could throw arity and ancestry in, sure, but I'd want to do that more as a pry 0.9.12 goal than as a 0.9.11.3 goal.

[ghost]

yeah, the arity is a nice touch but it also seems like it's the easiest one to read through.

[rking]

It's apples and oranges, comparing Object vs Rails stuff. Here's my ls Object:

Which, that's not even the same as his twacked out one.

[envygeeks]

Having arity in ls would be real annoying and it adds noise that can be gathered from show-source and friends.Thus far the best output is the last one that @rking put out, I even like the colouring because would be alright on both light and dark terminals.

[ghost]

@envygeeks I disagree with you. I think the arity is a nice touch.

[envygeeks]

@robgleeson Fair enough, but not if you force it on people as if everybody shares your opinion on noise.

[ghost]

@envygeeks I'm not forcing my opinion on anybody. I'm just expressing my opinion.

[banister]

@rking is this fixed yet? i pushed a new gem with some ls features, i assumed it related to this issue...?!

[rking]

@banister I think so.

@envygeeks Do you think so?

If you mostly-like pry-0.9.11.3's output, but want some tweaks, please create a new (less urgent sounding) Issue and close+comment this one with a link to that one.

[envygeeks]

The new version is absolutely superb and beautiful. So gonna close this ticket so that other people don't think it's an ongoing issue. Thanks @rking for fixing this issue so quickly.