Closed vlad-shatskyi closed 7 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.
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
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.
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.
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.
hey look
Awesome. Waiting for the merge.
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:
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.
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?
Two part question:
--git
get removed from -T
? I wasn't aware of -T
until today and am super excited, as it's almost (see question 2) replaced my use of the tree
utility. But my output is the same regardless of --git
or not, even though --git
works just fine without the -T
.-T
without -l
similar to just the standard tree
command? This would fully replace my use tree
and would be awesome :)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!
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!
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.
You can now --tree
without --long
as of e1f4ea92151901d97bfe042564342bc62ef442e5.
Awesome! Thanks for adding that :)
This is inching closer and closer to completion! I have recurse working, now for tree:
It was a big change, way bigger than I thought it would be.
Got there in the end
Playing with the (amazing) tree view, I've noticed a couple of places for improvement:
Option --tree is useless without option --recurse
. I think we could imply--recurse
then.-T
limiting the nesting level, similarly totree -L 2
.