ogham / exa

A modern replacement for ‘ls’.
https://the.exa.website/
MIT License
23.63k stars 660 forks source link

On the -T option #24

Closed vlad-shatskyi closed 7 years ago

vlad-shatskyi commented 9 years ago

Playing with the (amazing) tree view, I've noticed a couple of places for improvement:

ogham commented 9 years ago

I think I'm going to relent and make --tree automatically add --recurse. So many people have complained about that not working that I'm going to go with popular opinion.

vlad-shatskyi commented 9 years ago

I guess you're reluctant because it doesn't fit into your design, right?

May I suggest you to separate "effects" from options? I haven't really read the code, so I may say stupidest things, take it with a grain of salt.

Like each option would be a list of "effects". For example (pseudocode):

Option tree = [Tree, Recurse]

And then you could change the presentation based on the list elements. It's not me, who invented this approach, it's the way cat is implemented by Richard Stallman.

I did the same, and it worked perfectly for me. https://github.com/shockone/coreutils/blob/master/src/cat.hs#L54

ogham commented 9 years ago

I'm not reluctant - I'm definitely going to do it. It was just that I was 100% sure that that was the best way to do it, and then it turns out that everyone thought differently!

I do have a kind-of-similar thing going on in options.rs, where instead of just putting all the options into a struct, only the applicable ones are actually stored in the struct that gets passed to the program. There's a DirAction enum that says what to do when we encounter a directory (list it, recurse, or tree). All I have to do is change which of those gets picked when --tree is passed in.

vlad-shatskyi commented 9 years ago

Works perfectly, thank you. Do you consider adding a possibility to limit nesting?

On Feb 23, 2015, at 18:10, Ben S notifications@github.com wrote:

Try ea1b3ca https://github.com/ogham/exa/commit/ea1b3caefad39b7f794cd99112600528eb237d15: it allows --tree without --recurse.

— Reply to this email directly or view it on GitHub https://github.com/ogham/exa/issues/24#issuecomment-75572915.

ogham commented 9 years ago

That's definitely something I want to add!

I also want to add Git information to the tree view, as you suggest, but I'll need to think a bit harder about how to do it.

ogham commented 9 years ago

hey look

screen shot 2015-02-24 at 14 45 09

vlad-shatskyi commented 9 years ago

Awesome. Waiting for the merge.

ogham commented 9 years ago

I made some structural changes to the way tree-ing is done that allows the Git column to be added, and it looks like this:

screen shot 2015-02-26 at 14 38 08

I've looked at it for a while, and I think the "--" in the Git column combined with the "--"s in the tree hierarchy is a bit confusing, especially in the source directory. Also, it's a bit odd to have the M flag in both the 'src' directory and the 'src/main.rs' file - it's the same change twice. I mean, it works, and I'd like to have the functionality, but can you think of any way around these? I'm not sure what to suggest.

vlad-shatskyi commented 9 years ago

Are you sure you aren't overthinking it? It looks really simple to me: if the content of the directory is displayed, don't display the modified flag on the directory itself.

It's true that all the editors mark both entities as modified, but I guess it's done because of folding - a user should be able to quickly find modified files even if it's deep down the hierarchy.

On the other side, we always know if the directory is open or closed. And it's also more accurate. From git's perspective only the file is modified.

As for the dashes, why would you print them in the first place? They aren't any more informative than spaces.

What do you think?

kbknapp commented 9 years ago

Two part question:

As a side note, I rather like the M being displayed on both the directory and file that's been modified as well. This way if I'm using something like -L I know there's at least one or more files inside a particular directory that have been modified.

And I don't find the -- confusing at all :)

Keep up the awesome work, I've been using exa for quite a while and love it!

ogham commented 9 years ago

Did the --git get removed from -T?

I'd really like to have the Git column in the tree layout, but it's not there for technical reasons: I've got two local stashes (neither of which now merge...) that put it there, but stat each file twice in every case, which I'm not happy with. Unfortunately (here come the technical details) Rust doesn't let you Copy the results of a stat call, and I haven't found a way to reference the results in a way that doesn't change the entire program. So it's something I want to add, but it's still a work in progress.

Is it planned to allow -T without -l similar to just the standard tree command? This would fully replace my use tree and would be awesome :)

I suppose there's no reason why not! It just never crossed my mind to do so. Doing that would be a lot easier than trying to get the Git column to work.

This way if I'm using something like -L I know there's at least one or more files inside a particular directory that have been modified.

Whatever I end up doing, I promise that it'll respect --limit, because I use that option all the time.

Keep up the awesome work, I've been using exa for quite a while and love it!

Thank you!

ogham commented 9 years ago

Also, you've indirectly highlighted that I didn't reply to @shockone earlier in this thread. It's been, what, four and a half months? I'm so sorry!

Actually, one of the aforementioned stashes dates back to the beginning of March, which is why I was able to post that screenshot and then never merge the results.

Are you sure you aren't overthinking it? It looks really simple to me: if the content of the directory is displayed, don't display the modified flag on the directory itself.

Oh, I probably am overthinking it, don't worry. Displaying it both times is technically easier to do, but might be redundant, but it also might help the user. I'm still not sure.

As for the dashes, why would you print them in the first place? They aren't any more informative than spaces.

They mostly help me keep each entry in its own row as my eye scans across the table, that's all.

ogham commented 9 years ago

You can now --tree without --long as of e1f4ea92151901d97bfe042564342bc62ef442e5.

kbknapp commented 9 years ago

Awesome! Thanks for adding that :)

ogham commented 7 years ago

This is inching closer and closer to completion! I have recurse working, now for tree:

screen shot 2017-08-31 at 22 15 59

It was a big change, way bigger than I thought it would be.

ogham commented 7 years ago
screen shot 2017-09-02 at 22 38 29

Got there in the end