This is nice, but a poor substitute for what Genera was doing.

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.

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

Will definitely prioritize optimization in the next releases. Planning to benchmark against ls on various systems and file counts to get this properly sorted.

But it’s written in rust so it’s super fast. Did you take that into account when running your benchmarks? /s

"Always" is just 4 years? Lc is also one of these new tools

> 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

I assume this is tongue-in-cheek, but I don't think the comparison works at all.

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).

I’ve been on machines in the last few years that didn’t have screen either. Maybe it was a minimal install or something, but I specifically remember having to install it to get some long running stuff going.

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

Haha! Aren't all rust rewrites about colors take `bat` for example! Btw "!!" are from the git plugin, a quick way to see my workspace git status

You can still chain ripgrep. I specifically designed it so that you can chain it just like you would a normal grep.

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.

They don't do one thing well since it's all text, not structured data, which makes chained analysis a challenge, which leads to the desire for integration

vanilla ls has never been particularly chainable - https://mywiki.wooledge.org/ParsingLs

If you like that philosophy check out nushell. They go pretty hard core on that and they can because of structured output

I agree with this.

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

I think the standard ls doesn't have much in terms of color/icons, so its simplicity probably makes it a great side project for improving on.

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)

Well, recursive display is nice, I guess, as well as searching on partial filenames

> I barely ever even use the -la options.

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

Oh, of course the development is fun and exciting and a learning experience.

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.

While a man page or good documentation is maybe not too intriguing for you I consider it essential for other users to adopt. Maybe there are new or modern ways to create man pages that can be stimulating for your learning experience?