(put 'dired-find-alternate-file 'disabled nil)
Or: you can use a file manager that isn't made by crazy people, which is what I do. I say this as a loyal Emacs user: there are so many things in Emacs that are amazing (org-mode and magit are the two famous ones obviously, but a personal favorite is Emacs calc, which is just a work of art), but dired is not one of them.
I like that it opens multiple windows it makes it easy to quickly jump between directories. I dont worry about having a clean list of buffers though but it never gets in my way
- With the regular buffer list, if you keep typing letters, the view will restrict to buffers containing that string
- All the usual selection narrowing options, e.g. Helm, work here
- You can rebind 'q' to 'kill-buffer-and-its-windows
- A lot of people like ibuffer, which allows you to group kinds of buffer in its buffer list, e.g. all dired buffers
> just having it open and doing nothing with it, it has extremely high cpu usage
> it's maxing out 3 cores for me
But it will have to be pretty good to replace mc for me. It's not that mc is very good, because it's not. It's just that its keystrokes are deeply ingrained in my muscle memory :)
But this looks good and quicker to use (navigating the menu in mc takes a lot of keystrokes)
OTOH the highest voted comment as of this writing is comparing it to dired, so it's no worse than the competition I guess :)
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.
Oh man, I do have some bad news for you if you start counting the lines in the libc or the libc++.
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).
I feel you mischaracterise my GP comment though, it talked about different kinds of minimalism and said this is one valid kind.
Minimalism refers to UI/UX and not LOC.
Maybe replace minimalist with modern for a more correct description of software with 100s of dependencies? (Joke!)
Nitpicking aside, The app looks good and I do like this TUI trend!
Porting it to Rust wouldn't produce the same developer experience, unless one wants to see Rc<RefCell<>> and . clone () everywhere.
> cargo.lock has 1100 lines
- 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`.