Better documentation for CLI usage about parallel-disk-usage

[KSXGitHub]

While searching for tools like this one, while it seems impressive/interesting, I have noticed a lack of CLI docs/examples, or at least they're not as easily visible as other projects make them such as on the README.

There's a reason for this. The tool is currently not stable, features could be added and changed, which means I would have to update the documentation.

Personally, I'm looking for a CLI that allows me to break analysis down further by filtering to file types/extensions

This program currently doesn't do that.

I can raise a separate issue as a feature request for that if it interests you.

Please do. I would like you to specify how exactly it should work:

• Do you only filter files? What about directories?
• What is the syntax?

Keep in mind that I do not compromise performance to add new features (I accept compromise in binary size), so the feature would have to wait.

[polarathene]

There's a reason for this. The tool is currently not stable, features could be added and changed, which means I would have to update the documentation.

That's understandable. It does make me reluctant to trying it out and providing feedback though. I image other users may feel similar, it's not a huge amount of friction but it's there.

I don't mind if documentation for commands isn't updated and in sync all the time, especially when the lack of a stable API is communicated clearly. It's still valuable for getting a quick overview of what to expect.

Assuming your executable can output such so that there is some easy way to know how to use the CLI, you could print that output to a txt/md document with builds in CI or locally and commit that with a link on the README. More thorough documentation / examples could come later.

Keep in mind that I do not compromise performance to add new features

Do you see supporting an option to filter files by extension as a performance problem when filtering isn't used? I would have imagined any filtering logic wouldn't be run. I'm not familiar with the internals, but I envisioned the feature as opting in to check the file name or path against some condition, eg a regex pattern or list of extensions depending on how flexible you would allow it.

Performance degrading only when using such a feature is a non-issue in the sense that it has 0/no performance when the feature itself doesn't exist. I'd rather have access to a feature and accept the performance hit than not have the ability to do such in the first place, so long as it doesn't negatively impact anyone not using the feature.

---

I'll open an issue for the feature request (done. Up to you if leaving this documentation issue open is useful.