Feature idea: files count

[aldanor]

Idea: a flags that enables reporting total file count for directories,

Could be especially useful with #84, so you could report files count like

├─ a (123.45 MiB, 123 files)
│  ├─ b (67.89 MiB, 67 files)
├─ b (234.56 MiB, 234 files)
│  ├─ c (56.78 MiB, 56 files)
│  ├─ ├─ d (8.90 MiB, 8 files)

This might be somewhat confusing because it's not the number of files in a given directory but rather total files in this directory and all subdirectories (but is otherwise consistent with total file size being reported recursively).

[bryceberger]

Just to flesh out the idea some more:

• Why recursive file counts? There's not a technical reason it has to be like that, and you stated that a recursive count could be confusing.
• Would directories be counted?
  • Given the following tree: A/B/c A/D/e, would A have 2 children (just the files c and e), 2 children (just the folders B and D), 4 children (B, c, D, e), or no children (no files as direct children)?

How would this interact with files ignored via glob or gitignore? Right now, ignored files are treated as if they do not exist, and not counted for file size -- presumably this would mean they're not counted for number of files either.

[aldanor]

How would this interact with files ignored via glob or gitignore?

Well, that's an easy one, for consistency purposes, whenever +x is added to the subtree size (of the node and parent nodes), it could also add +1 to the file count?

Why recursive file counts?

While I've mentioned myself it may be somewhat confusing, I think it would be consistent with how sizes are computed. Otherwise you'd end up with different conventions for accumulating sizes and counts which may also end up being confusing, but in a different way. Perhaps a better name could be files in tree, but it's too verbose. Another thought, could have a flag flipping behaviour to 'files in this specific folder' to 'files in this folder and the subtree'.

Re: using the same convention - even if you have a complicated tree of folders, you could simply take the size value, divide it by the files (i.e. files in the subtree) value and obtain an average size of a single file that contributed to size within this tree.

Would directories be counted?

Intuitively, I'd expect them not to, unless you name them "node counts" or "subtree counts" or something like that. Files are just files. Again, consistent with the existing logic? I.e., directories don't contribute to the logical file size?

[solidiquis]

What do you guys think of something like:

foo (9 B, 1 directories, 2 files)
├─ nyarlathotep.txt (4 B)
├─ cthulhu.txt (5 B)
└─ bar (6B, 1 file)
   └─ yogsothoth.txt (6 B)

I imagine the --size-left view would look something like:

    15   B  foo (1 directories, 2 files)
     4   B ├─ nyarlathotep.txt
     5   B ├─ cthulhu.txt
     6   B └─ bar (1 file)
     6   B    └─ yogsothoth.txt

Additionally, any thoughts on if we should handle symlinks to directories in any special manner?

[solidiquis]

So I gave this a solid effort and I left not being a huge fan of how cluttered it all looked, especially with the --size-left option. In the mean time I added a -c, --count option here to see aggregate data at the foot of the output but until someone offers a better suggestion for how the UI should look this is what I'm going to stick with for the time being. I'll leave this issue open.

[solidiquis]

#131