Live data from Hacker News

Superfile – A fancy, pretty terminal file manager

github.com

61–70 of 219 posts

Re: Superfile – A fancy, pretty terminal file manager

#61

Looks nice! Not sure if it's enough to pry me away from MC, but worth a look.

very first impression after <30 sec: having to press ^F or any key to enable filename/folder search in a folder creates friction vs. MC's approach where typing automatically starts search of current folder so you can hit a couple of keys, press enter, etc. Would be nice if that were a mode here too.

Re: Superfile – A fancy, pretty terminal file manager

#63
post #28

If didn't read the docs, noticed hkjl moved around, and accidentally deleted 3 folders with ctrl+d seeing if I could scroll down faster. Scary defaults if you have Vim muscle memory.

So there's no confirmation for deletion? Oof, that's probably the most unsafe default I have seen in a while.

Re: Superfile – A fancy, pretty terminal file manager

#64
post #62

Love all the terminal tooling that's come out in recent years. I'm this close to chrome and rofi being the only gui I'm using on my work machine. This looks great!

Isn't the terminal program technically a GUI?

Technically a TUI?

Re: Superfile – A fancy, pretty terminal file manager

#65
post #56

Earlier quoted context omitted.

An operating system from 2018 which is no longer maintained by its vendor? https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php I think it's somewhat unreasonable to expect software released today will necessarily work on your environment without some legwork.

Is it though? I can run Windows programs from 20 years ago on my Windows machine just fine. Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorr…

You are talking about backward compatibility, the parent thread is about forward compatibility. You won't have much luck running a modern executable on XP unless the vendor went out of their way to make that happen.

> What's worse is that you can't even really statically link it without herculean effort.

The program we are discussing happens to be written in Go so it's trivial to build a statically linked executable.

Re: Superfile – A fancy, pretty terminal file manager

#66
post #59

Earlier quoted context omitted.

>… macos coworkers and they have a single application on fullscreen… They are probably recent ex-Windows users struggling to understand a superficially similar but profoundly different WIMP paradigm. >… then they shake their mouse or whatever and 20 windows fly over the screen The fact that they can’t handle Mission Control is another tell-tale

Mac OS itself confuses things by forcing apps to be full screen, rather than sizing to the content

> Mac OS itself confuses things by forcing apps to be full screen, rather than sizing to the content

I don't understand what you mean.

macOS has never forced apps to be full screen.

Re: Superfile – A fancy, pretty terminal file manager

#67
post #12

Brew install superfile Now guess what the executable is called…

Yes, I had the same question! (`spf` for the curious!) EDIT: To be fair, right at the beginning of the tutorial is: > First, if you want to open superfile by opening a terminal and typing spf.

A symlink would be a good solution.

Re: Superfile – A fancy, pretty terminal file manager

#70

Earlier quoted context omitted.

It's a slippery slope, once you've spent a year tailoring your setup it removes so much friction from those tasks you do 100 times a day. Sometimes I look at my macos coworkers and they have a single application on fullscreen and then they shake their mouse or whatever and 20 windows fly over the screen and then they scan them all to find the other window they are looking for, and I really wonder how they get work do…

> Sometimes I look at my macos coworkers ... and I really wonder how they get work done And I read the sentence before and wonder the same: > once you've spent a year tailoring your setup

In both cases during the "learn the tool" phase you end up spending time having to figure out how to do things, understand workflows etc.

In the TUI case though, you can usually tweak that workflow and configure it to match your brand of thinking. It costs a little more per instance up front, but after that year (or whatever time period), you get a much less frustrating experience, and the oddball things your particular workflow requires have been smoothed out - where in the GUI you'd still be frustrated and a bit fumbly or suboptimal, so you continue to pay the penalty for it over time.

It's really about how you amortize the total time put into using the tool.

Post reply on HN