eza: add options

[refaelsh]

Add more commonly use options

Description

The following options were added:

1. --all
2. --ling
3. --extended
4. --header
5. --classify

Checklist

• [x] Change is backwards compatible.

• [x] Code formatted with ./format.

• [x] Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• [x] Test cases updated/added. See example.

• [x] Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

Maintainer CC

@cafkafk

[refaelsh]

Thank you very much for your comment @teto. I agree with your statement on a sentimental level. When you say: A list of string is enough, what exactly do you mean? Please provide an example in the context of the current PR. Also, how would you imagine this module be looking like with A list of string is enough?

[rycee]

Overall I agree with @teto that we should be restrictive about the number of options as it introduces maintenance complexity. These flags seem somewhat restricted in scope, though, so I could live with it as long as @cafkafk is OK with it and eza upstream don't consider these flags unstable or experimental.

[cafkafk]

Overall I agree with @teto that we should be restrictive about the number of options as it introduces maintenance complexity. These flags seem somewhat restricted in scope, though, so I could live with it as long as @cafkafk is OK with it and eza upstream don't consider these flags unstable or experimental.

They're not "experimental", but may be broken in future breaking releases. They will be marked as breaking changes in both our changelogs and by the major bumps (0.y.z, where y is acting as major here), as we conform to a stricter semver that gives the guarantee that we will not introduce breaking changes in patch versions, even if we're not 1.0 yet.

That said, it may be the case that these do incur too big of a maintenance overhead, I perhaps suggest that module maintainers should get final say on this, or that the author of the PR commits to potentially fixing breakage.

(even then, I wonder how this will be kept in sync when there is breaking changes, as eza updates come from nixpkgs, the nescesarry module option changes can't be "transactionally" added with new eza versions, the interface does seem somewhat brittle)

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the PR

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.