It does indeed also include other functionality that might traditionally be left to other tools (like filtering files). But this is nothing that GNU grep wasn't already doing itself anyway.

IMO, it's better to view the Unix philosophy as a means to an end and not an end to itself. And IMO, it's important to weigh the benefits of coupling to the user experience.

If they want something that is easy to use in a non-scriptable way, maybe they should replicate Norton Commander instead.

Not a big surface area, some easy improvements. A whole lot less stressful than rewriting grep (although I'm massively grateful Burnt Sushi did such a crazy thing)

Certainly I use these less than plain "ls," but digging through hidden files and folders and looking at timestamps is very important for me.

  $ man ls | grep '\--hyperlink' -A 1
  --hyperlink[=WHEN]
         hyperlink file names WHEN

You see, Genera knows the actual type of everything that is clickable. When a program needs an input, objects of the wrong type _lose their interactivity_ for the duration. So if you list the files in some directory, the names of those files are indeed links that you can click on. Clicking on one would bring up a context menu of relevant actions (view, edit, print, delete, etc). If a program asks for a filename as input then clicking on a file instead supplies the file object to the program. Clicking on objects of other types does nothing.

(Thinking it was Ubuntu server, but guessing someone will correct me)

I spend maybe 1% of my working hours (being generous) using `ls` and something like 50% (likely more) using my editor.

If there is some alternative to `ls` that makes my `ls` workflows 2x faster, my productivity increases by 0.5%. If I use a sub-optimal editor that makes my workflow 2x slower, I lose 25% of my productivity.

When I need to login to a remote box, I am also very likely to need to use `ls` since I am less familiar than on my own machine, whereas I am unlikely to do any sort of heavy development work (typically I just need to edit a couple configuration files, or do some git operations).

But before inviting others to use something, please think of how to make its use more clear. After all, I assume you post this so that people use it, not only admire your coding skills. There is a group of people who have learned to read and rely on man pages.

For example, the top-level README says:

> -s, --sort <CRITERIA>: Sort by "name", "size", or "date"

OK, does "date" refer to creation date, modification date, access date? I can understand "size", but does it produce smallest-first or largest-first? It might not matter if... ah, no, there is no -r/--reverse flag. Can I have more than one "criteria" (since the plural is used)?

Getting answers for such questions now means I have to go read the code in src/args.rs and follow to the implementation of the various functions. And in a few days, when I have the same questions again and I have forgotten the options, I will again have to dive into the code.

Please consider providing a short man page. It documents the "calling interface" to your program and makes it easier to use. I usually start writing one even before implementing the whole thing, to clearly articulate what I expect the program to do.

> more likely to just submit PRs and make such stuff built-in but maybe optional.

Which are more likely to just be rejected by the more conservative maintainers of the tool. That's the empowering beauty of plugins - no such barriers