Order tree by size

[ccinelli]

This is a great tool.
Can you add an option to order the folder structure by size?

[darxtrix]

@wagoodman I am picking up this, do let me know if you already started working on this :)

[wagoodman]

@darxtrix haven't started yet, have at it!

[darxtrix]

Cool, thanks will send in a PR when done.

[darxtrix]

@wagoodman currently the file search is implemented at complete FileTree level and not at a particular FIleNode level, so are we going to implement the sorting operation on the FileTree level or FileNode level ? A FileTree level sort will be more resourcing consuming and I guess at a particular point users are mostly interested in sorting at a FileNode (directory).

[wagoodman]

I took this issue to be sort the current directory in the tree by size, but what you're really saying is globally sort the tree contents by size, regardless of which directory it is in? If that's true, then this is a heavier lift since it implies replacing the filetree UI (right pane) entirely.

Since each directory is showing the aggregated content size, would sorting the dir contents be good enough? Later tonight I can jump back on and go into a bit more detail.

[darxtrix]

Sorry for late reply. Timezone issues.

@wagoodman I was trying communicate the same as you mentioned. We should sort at the directory level instead of full tree level.

We might need to put some parameter representing the total size of the directory at the FileNode level otherwise we have to traverse down recursively each time. What are your thoughts on this ? Should we have to support both ASC or DESC sort, or the DESC is sufficient ?

[darxtrix]

Hi @wagoodman, just following up. Any thoughts on this ?

[wagoodman]

Sorry for the delay, you're right about needing to add a total size parameter on the FileNode struct... I'll call it branchSize here, or the total number of bytes on this tree branch --from this node and it's children. My first thought is to populate branchSize at either FileTree.AddPath or FileNode.AddChild. The upside is that this is the only place that we are affecting the tree structure. The downside is that there may be a performance hit when calling something like FileTree.StackRange.

The next problem to solve is ensuring that there is parity with rendering the tree string. Currently it presumes that each dir contents is sorted alphabetically (https://github.com/wagoodman/dive/blob/master/filetree/tree.go#L73), so now there will need to be a way to indicate the current sort preference and reference that here.

As for ASC/DESC, I'd start with DESC for now, we can always expand it to ASC later (this becomes more of a screen realestate problem than a technical problem... the bottom hint bar that shows keybinding hints is getting full).

[darxtrix]

Cool, I will go ahead and implement this. Thanks !