[HN Gopher] Show HN: Xplr - A hackable, minimal, fast TUI file e...
___________________________________________________________________
Show HN: Xplr - A hackable, minimal, fast TUI file explorer
Author : sayanarijit
Score : 188 points
Date : 2021-04-06 05:01 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ruph123 wrote:
| You forgot ,,written in Rust" for a 10x upvote multiplier.
|
| Looks great!
| sayanarijit wrote:
| Haha. Missed this the 2nd time.
| sayanarijit wrote:
| Updated :)
| ruph123 wrote:
| Nice!
| nikeee wrote:
| Feels like "(as a millionaire)" on YouTube.
| GekkePrutser wrote:
| Interesting, I will try it!
|
| 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)
| sayanarijit wrote:
| You should be able to configure the key bindings like mc
| https://github.com/sayanarijit/xplr/wiki/Key-Bindings
| [deleted]
| sim_card_map wrote:
| > minimal
|
| > cargo.lock has 1100 lines
| dathinab wrote:
| - 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`.
| smusamashah wrote:
| There is also broot https://dystroy.org/broot/
| sayanarijit wrote:
| Listed https://github.com/sayanarijit/xplr/wiki/Alternatives
| PestoDiRucola wrote:
| Ahh yes, written in Rust, my favorite feature.
| woah wrote:
| 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.
| laurent123456 wrote:
| Meanwhile, in the comments below:
|
| > just having it open and doing nothing with it, it has
| extremely high cpu usage
|
| > it's maxing out 3 cores for me
| sayanarijit wrote:
| I'm aware of it and will start working on it shortly.
| https://github.com/sayanarijit/xplr/issues/10
| sayanarijit wrote:
| Fixed here
| https://github.com/sayanarijit/xplr/releases/tag/v0.3.3
| conradludgate wrote:
| This is really cool! I use a similar tool for fuzzy cd[0]. At the
| moment I'm trying to use broot[1] as my directory browser but I
| might consider trying this too
|
| [0]: https://github.com/b4b4r07/enhancd [1]:
| https://github.com/Canop/broot
| shomyo wrote:
| 'written in rust' is new 'Tips Fedora'
| the8472 wrote:
| But does it support mouse control, and drag&drop or media content
| preview?
| sayanarijit wrote:
| 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
| ducktective wrote:
| There is also nnn and Vifm (C), lf (Go) and ranger (Python)
| sayanarijit wrote:
| Also listed them
| https://github.com/sayanarijit/xplr/wiki/Alternatives
| ducktective wrote:
| Nice project btw! Were you experienced in C&C++ before
| learning Rust?
| sayanarijit wrote:
| Thanks. I only have some competitive programming experience
| with c++ and Java. I used Python and Elm in my last job.
| pjmlp wrote:
| I guess it is time to revive Turbo Vision.
| drran wrote:
| Revived with Unicode support[0], but nobody ported it to Rust
| yet.
|
| [0]: https://github.com/magiblot/tvision
| pjmlp wrote:
| I am aware of it. :)
|
| Porting it to Rust wouldn't produce the same developer
| experience, unless one wants to see Rc<RefCell<>> and . clone
| () everywhere.
| anhanhanh wrote:
| > written in rust
|
| Most important. Go get those sweet sweet internet points
| fulafel wrote:
| The file specifying the dependencies is over 1000 lines long
| (https://github.com/sayanarijit/xplr/blob/main/Cargo.lock) -
| there are different types of minimal of course, and a small
| amount of code leveraging a lot of deps is valid, but is does
| make one think.
|
| OTOH the highest voted comment as of this writing is comparing it
| to dired, so it's no worse than the competition I guess :)
| sayanarijit wrote:
| 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.
| __jem wrote:
| 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.co
| m/sayanarijit/xplr/blob/main/Cargo.toml#L15....
| fulafel wrote:
| Yep, it's true that there's a shorter list of the direct
| dependencies. But surely the transitive dependency set is the
| better signal about the actual amount of 3rd party code
| pulled in.
| shakow wrote:
| > But surely the transitive dependency set is the better
| signal
|
| Oh man, I do have some bad news for you if you start
| counting the lines in the libc or the libc++.
| dathinab wrote:
| 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.
| thethirdone wrote:
| 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).
| sayanarijit wrote:
| 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.
| [deleted]
| gpm wrote:
| 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.
| fulafel wrote:
| It seems quite human readable, but please be more specific if
| there are aspects you think I misunderstood.
|
| I feel you mischaracterise my GP comment though, it talked
| about different kinds of minimalism and said this is one
| valid kind.
| gpm wrote:
| I probably should have said discussion instead of
| understanding, but as someone else said it specifies a
| total of 60 dependencies (I didn't check their work), if
| you knew that just saying "1000 line" instead is downright
| misleading... If you didn't I don't buy buy that you really
| understood it.
| vonwoodson wrote:
| 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.
| apabepa wrote:
| Minimalist as in the README does not specify that it refers
| to the UI though.. If I read minimalist software I would
| assume a more holistic interpretation unless otherwise
| specified.
|
| 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!
| tartoran wrote:
| I use Ranger but the hackability potential in this is very
| promising, I'll definitely give it a spin. Thanks for posting!
| sayanarijit wrote:
| Great. Looking forward to hearing how it goes.
| resoluteteeth wrote:
| I like it, but just having it open and doing nothing with it, it
| has extremely high cpu usage.
| hundchenkatze wrote:
| Same here, it's maxing out 3 cores for me.
| sayanarijit wrote:
| I'll start working on it shortly.
| https://github.com/sayanarijit/xplr/issues/10
| [deleted]
| sayanarijit wrote:
| Fixed here
| https://github.com/sayanarijit/xplr/releases/tag/v0.3.3
| codychan wrote:
| Same here, I just play with it around 30s before I notice CPU
| problem.
| windowsnoobz wrote:
| Noob question: How can I use this on Windows?
| sayanarijit wrote:
| 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_...
| sayanarijit wrote:
| i.e. use the Linux binary on WSL
| smitty1e wrote:
| "Cool," said dired.
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
| OskarS wrote:
| 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!
| globular-toast wrote:
| Why do you care about open buffers? When I first started
| using emacs I cared because other text editors force you to
| care by displaying "tabs" or the like for each open buffer.
| But emacs is better than that. The only time I ever see all
| open buffers is if I do M-x list-buffers, and I never do
| that. Other than that, open buffers never get in the way. I
| do use midnight-mode to kill all "old" buffers in the middle
| of the night to stop the memory usage growing indefinitely,
| though.
| chalst wrote:
| A buffer per directory is just the right thing for dired to
| do, for the same kind of reason that it is right that git has
| a staging area. Your problem is that this behaviour causes
| friction with how you prefer to manage buffers. Some
| suggestions:
|
| - 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
| satish-setty wrote:
| Of course, it can be customized. (put
| 'dired-find-alternate-file 'disabled nil)
|
| https://www.emacswiki.org/emacs/DiredReuseDirectoryBuffer
| OskarS wrote:
| This does not solve the issue, if you enter a folder with
| RET (a slightly more obvious key than `a`), it still opens
| a new buffer for every directory. What you would have to do
| is to remap the key in dired's keymap. Which still doesn't
| solve the issue that it keeps the buffer open even though
| you close it with `q`, which requires some other fix.
|
| 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.
| mouldysammich wrote:
| I wouldnt say dired is made by crazy people, It just
| doesnt fit your expectations
|
| 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
| [deleted]
| kqr wrote:
| And Sunrise Commander, the dual-pane dired that works even more
| like an orthodox file manager.
|
| https://www.emacswiki.org/emacs/Sunrise_Commander
| gerikson wrote:
| The name itself a reference to Midnight Commander, inspired
| by Norton Commander...
| catern wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-06 23:02 UTC)