Show HN: Xplr – A hackable, minimal, fast TUI file explorer

And Sunrise Commander, the dual-pane dired that works even more like an orthodox file manager.

https://www.emacswiki.org/emacs/Sunrise_Commander

Ugh, I find dired incredibly annoying and avoid it at all costs in Emacs. You use it once and suddenly have a gazillion buffers open, it's just the worst! They don't even go away when you deliberately close them with q!

My favorite dired feature is that if you C-x C-q (the standard Emacs binding to toggle the read-only status of a file), it makes the directory buffer writable. You can then edit the buffer like a regular file, including changing file names (or symbolic link targets, or other things, I presume), and when you're done, C-c C-c and it applies all the changes as renamed files, symbolic link retargeting, etc etc. Very handy, since you can use all the usual Emacs features like query-replace or kmacros while doing it.

Also listed them https://github.com/sayanarijit/xplr/wiki/Alternatives

When you see a “Show HN”, the odds are very high that it is written in an ergonomic language such as Python, JS, Go, or Rust, rather than C or C++. Rust is the only one of these that has native performance, so I think this is useful information.

For software that isn't in the package repository of your distro written in Rust (or Go or any other language with something similar to cargo) means I can clone the repository, run a build command and it'll likely compile easily and successfully. As a user this is much better than hunting down dev package names and versions for a C or C++ source.

Great. Looking forward to hearing how it goes.

Same here, it's maxing out 3 cores for me.

Same here, I just play with it around 30s before I notice CPU problem.

You should be able to configure the key bindings like mc https://github.com/sayanarijit/xplr/wiki/Key-Bindings

Not yet. It's supposed to be minimal, so I doubt it'll ever support mouse, drap & drop and other GUI features. Although, the preview is in list as a potential plugin. See https://github.com/sayanarijit/xplr/wiki/Plugins and https://github.com/sayanarijit/xplr/wiki/TODO

Listed https://github.com/sayanarijit/xplr/wiki/Alternatives

Thanks for your comment. I realized that I missed clarifying the type of "minimal" I want to pursue. I have updated the wiki accordingly. https://github.com/sayanarijit/xplr/wiki/Features#minimalist.

This is a lockfile, not the manifest for dependencies, so it includes all the translative dependencies as well. The list of direct dependencies is significantly smaller: https://github.com/sayanarijit/xplr/blob/main/Cargo.toml#L15....

1000 lines of Cargo.lock is 100-200 total dependencies. Importantly, a "dependency" in Rust is a little more granular than in some other languages. A single dependency might have ~4 sub-crates which are there own "dependency".

I would guess the 1000 lines of Cargo.lock represent ~32K of Rust code. That is probably no longer minimal by most definitions, but having a dependency on libc is like 200K of C so an additional 30K seems not so bad (assuming the dependencies are well known).

Also, I don't think `Cargo.lock` is a valid measure of bulk as it contains both dev and prod dependency tree. For compiled languages, the binary size probably can be a better measurement, but that's also debatable since c and c++ use shared libraries while rust uses self-contained ones.

Ignoring benchmarking only deps, this crate has 10 direct dependencies and 60 in total. Through some of them are just internally split's of the same dependency, e.g.: pest, pest_derive, pest_generator, pest_meta. And some are build dependencies only.

So why is the lock file so big?

1. It also locks the test dependencies, i.e. the criterion benchmarking suite which is big and it's transitive dependencies (without it's ~750 lines in the lock file).

2. The lock file is human-readable formatted, because of this every "entry" takes at least 6 lines.

3. Each entry has one additional line per dependency, but dependencies are often shared internally (e.g. libc) so this can "bloat" the lock file without adding any additional dependency.

This “minimal” refers to minimalism according to the first line of the README: “Though xplr strives to be fast and minimalist, its speciality is its hackability.”

Minimalism refers to UI/UX and not LOC.

Linking to a computer generated file and saying "it's long" with no understanding of what is in it is just low effort trolling. Please don't do this.

I haven't tested it on Windows yet, but as per the following comment, it should work fine on Windows-Linux subsystem. https://www.reddit.com/r/commandline/comments/mjot3a/xplr_a_...

Revived with Unicode support[0], but nobody ported it to Rust yet.

[0]: https://github.com/magiblot/tvision

Haha. Missed this the 2nd time.

Feels like "(as a millionaire)" on YouTube.

- Cargo lock has a very verbose format.

- Cargo lock contains "test" dependencies, in this case the criterion benchmark suite. Without it it's ~750 lines.

- It's actually "only" 10 direct dependencies and including transitive ones 60.

- Some dependency are the same dependency split into multiple parts e.g. foobar and foobar-core count as two dependencies.

- Some dependencies are also build-only dependencies, e.g. derive related dependencies like `syn`.