brew install superfile
  (ok)
  superfile
  (not found)
  find superfile
  (not sound)
  cd /usr/local/Cellar/superfile/1.1.2/bin
  ls
  spf

There's some stellar libraries in Go for terminal stuff, in particular anything from charmcli. They have an elm style TUI framework called bubbletea (which superfile uses), a styling library, prebuilt components, it's really incredible. I'm building a multiplayer tetris you can play through ssh, which is using bubbletea and another lib of theirs called wish.

they have a lot of stuff you can just use in regular shell stuff too: https://charm.sh

The color scheme matches the color scheme I set. They cannot change the font size nor the the font. They cannot spawn windows that will steal focus. They can run inside tmux which has advantages for my workflow.

Hotkeys are a first class citizen and not an afterthought when it comes to terminal uis.

That being said, I don't hate GUIs. I just hate a lot of them for doing things that annoy me.

It's like if every single GUI program included easy recording of macros and had built-in tools for munging of data to input fields and from text information.

There is a really solid place for GUI tools though and that's where the task is inherently visual (nontrivial tabular data, anything with images or video, etc) or where discovering your features and guiding people through a workflow is more important than it playing a part in a text processing pipeline.

Honestly, file managers are probably a good example of something that really ought to be a GUI and I've always considered it a bit zealous of people to want a TUI for it. Just look at this thread alone - people accidentally deleting files because navigation and actions are so undiscoverable that if you don't just blindly copy vim, even highly technical people will have no idea how to use your tool.

> Just look at this thread alone - people accidentally deleting files because navigation and actions are so undiscoverable that if you don't just blindly copy vim, even highly technical people will have no idea how to use your tool.

But is that even a problem? If you are going to use a tool for years, does it matter that in the first few hours it's not super discoverable?

I do wish and hope more apps become like Zellij, though. With possible keybinds on the bottom, etc. I tend to avoid TUIs because i can't be arsed to remember the keybinds and prefer to just use CLIs since those are in my history.

TUIs work better when you're committed to the workflow. Discoverability is not often one of the key features (although most seem to have great help pages and manuals). You chose one, take the time to learn it, configure it the way you want and it's better (not prettier) than most mouse based workflows.

I think the average GUI was designed for mouse-first and the lowest common denominator, so it'll generally never be as good. It's similar to how irssi and weechat are top-tier chat programs, but nothing in the XMPP or Matrix world really seems as good.

Space for example opens a list with ten or twenty commands that remind you how to open the file picker, open editor list, problems window, etc…

For me, hotkeys are the main selling point. I don't want to operate my machine with one wrist and one finger. I have a panel of switches in front of me, why should it be a typewriter 100% of the time? Moving to keyboard focused interaction, particularly vim keys but anything really, it makes me feel like in operating my machine with my mind, it is orders of magnitude less cumbersome once you're past the learning curve, such that when I have to use a traditional stacking, mouse focused environment I feel like I'm on a dial up connection with my hands amputated and cataracts.

press a single key

enter part of a name

get a fuzzy match for any file on your system in a separate tab (which you can return to later if needed)

sort by path/size/image width to filter further

press a key to preview file content or copy a file or delete it

All that with immediate visual feedback

What's your terminal day solution to this?

> if something fails you can see the error,

Or you can't, it just silently deleted the wrong files and you're non the wiser since you don't even see that your filter mismatched

> With the terminal you can just take 2 minutes to write a burner script and use it and be done in seconds.

How would you pick the audio times? In audacity you can easily play on cut thresholds to hear that they're correct, what's your "seconds" solution to that?

Because GUI design today is very bad and only getting worse.

What you describe is pure fad-chasing, so I hope it swings back the other way while I’m still around to enjoy it.

I use i3 and have 5 credit-card sized terminals open at any given time without taking up much screen real estate, and it's so great.

Takes some getting used to though.

And I read the sentence before and wonder the same:

> once you've spent a year tailoring your setup

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.

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

I don't understand what you mean.

macOS has never forced apps to be full screen.

I suspect most Linux users don't "hate GUIs" but hate the garbage that GUIs enable, like pointless/stupid transition animations, hard to see flat UIs, dumbing down of preference/setting dialogs, etc.

Most GUI design is focused on dumbing things down for first time and beginner users, and most Linux users don't fall into that demographic.

If a GUI helps me get my work done faster then I'm all for it. If the GUI gets in my way and wastes my time then I'm not going to use it.

UX design is a real and valuable discipline, but it has been largely supplanted by what amounts to a fashion show.

Like, you can pipe CLIs together, and some TUIs accept a command and exit, allowing you to chain things together.

On the web, your best bet might be playwright, but that’s about it. Imagine having GTK and QT applications able to be chained and exit automatically.

On MacOS/iOS it’s not much better, even if Apple Shortcuts can feel ok sometimes, assuming the devs thought about allowing some actions to be available through shortcuts.

On Linux, I think dbus was supposed to become the universal bus onto which all GUIs could provide services and do things together. It hasn’t panned out IMO.

None of the tools on display here are composable either, in fact almost all modern TUIs are literally indistinguishable from GUIs, using the same widgets and user paradigms you'd find in a desktop app, but reimplemented on top a text rendering engine, they're not CLI tools.

It's basically the same thing we did on the web where webapps sort of pretend that they're not sitting on a text protocol but at least there it's out of necessity. On top of a functioning graphic stack there's no point for TUIs to exist.

My default assumption about TUI programs: they'll work everywhere I work.

Information density and shortcut availability are two of the big ones.

But the biggest for me is composability. I can query any data using their cli and open it in visidata nearly instantly. Just pipe it in. The interface is awesome compared to other query viewers I’ve found. It makes it easier to drill in and see results. Quick pivoting, Filtering and more

Typically, because we find them inferior to CLIs/TUIs. A few possible reasons:

* Graphical programs tend to use more memory/CPU for the same task.

* Graphical programs are more likely to prefer/require the mouse.

* Graphical programs seem to change their interface more frequently.

* Graphical toolkits all seem to suck, in ways that vary by toolkit and version, and this suckage tends to make us actually notice more than ex. new versions of ncurses changing things under the hood.

Don't get me wrong, there are plenty of GUI programs that are great - some of them even better than CLI/TUI alternatives - but the odds seem to be stacked against them.

However with material design being the norm in gui there is nowadays barely any visual difference between a TUI and a GUI so it only come down to preferences: app optimized for keyboard or mouse use.

I think that a lot of people are drawn to the idea of being able to customize their UI the exact way they want it and have it be that way everywhere.

There are compromises with TUIs but that idea of a universal interface is very alluring to some people who want to optimize that part of their life.

I've heard of a setup relying on Unity's old global menu feature that then lets you use something like rofi to search all the menus in a GUI program at once, but sadly never got it working. Sounds like a dream. You didn't have to actually use Unity, just make programs think you were, presumably so they'd expose the information the right way.

Now, "on average" does all the talking here, like, even putting the cli vs tui categorization aside (otherwise the "average" would support no nav, just some text flags), you can't really pick a small niche of TUI apps and compare it to the whole GUI, pick the same niche, and then you'd get categorically comparable keyboard support

Flat... Whitespace. In modern graphical applications, nothing is broken up in your field of view, everything is an object on a slate. There's no organization, no context grouping objects together that help you understand how to interact with them, they're not ergonomic. Contrast that with this, while it's not a perfect example, there are clear borders, clear sets of interactions, the mind can formulate a procedure by looking at the organization of everything in front of them. It's almost like fonts, some fonts are better for readability, others are just ideas people had that might help that don't work out, and others are just there to look fashionable. UI maps and interactive flows can be easy to understand at a glance or look pretty but not give the user much of a clue what to do with what they're looking at.

Which are invisible. Unlike with the menus that show you keybinds right next to a command, and have Accelerators where you can use keyboard to navigate the list visually with the keyboard instead of having to remember all of the keybinds. (unless you mean web apps, but then this app doesn't run on the web, so that comparison is moot)

(by the way, "most" clis don't support any keybinds, they're using command line flags)

> Contrast that with this

I have, taking a very common app for comparison - Windows File Explorer. It has borders (and nicer ones at that as they don't need waste the width of the whole char of space because they're not text), and also same groups (left pane)

> clear sets of interactions

Can you list a clear set of interactions with the Clipboard panel in the bottom-right (can you rename a file from there? drag&drop it away? delete a file / delete from the clipboard), and where this clarity is coming from

> Flat... Whitespace

Seriously, this file manager is a flatly designed app!, just go through the checklist:

Flat design is a modern design style that consistently maintains minimalist, 2D features. Here are six signs that what you’re looking at is flat design.

Contrasting colors: often bright colors, flat design relies on distinct contrast to send visual cues to users.

2D styling: simple shapes and no realistic images.

Simple typography: typically sans-serif fonts are the choice of flat design. It loads fast, it fits with minimalist style, and it’s easy to read.

White space: negative space helps designers indicate which part of the page they want users to focus on and makes the website more readable.

Grid-based layouts: usually flat design is symmetrical and uses a grid for the layout and hierarchy.

Simplicity: symbolic icons, abstract forms, no textures, and no gradients.

https://careerfoundry.com/en/blog/ui-design/what-is-flat-des...

With the exception of borders, which are less common in other flat designs

Linux users don't hate GUIs. I say this as someone who's used Linux as a daily driver for 15 years! GUIs have their place, but they aren't for everything. There's are two main issues here

1) The terminal is far more flexible and lightweight. I can do so much more in my terminal and get far more done in less time by using the terminal. Learning a little bash can greatly increase your productivity. And on top of that, I can do this with little cost to resources. I live in the terminal not because it is pretty but because it's faster and more efficient. Yes, there's a learning curve but it pays dividends.

2) customization. Don't confuse this for aesthetics. Those do matter but you should see yourself as an expert craftsman. Your carpenter, engineer, etc all build tools, jigs, and other things to help them, especially with organization. Like them you should create the best environment for you. I know you were told I'm programming classes that the magic is to not keep writing the same lines but to wrap those up. This is the same thing. The aesthetics are so I can see the things I care about the most, not because it's pretty. The aliases and scripts I built are to prevent me from wasting time relooking up things I do intermittently but not frequent enough to memorize. Customization is incredibly hard in GUIs. Dragging and dropping things and half the time the whole fucking screen scrolls because it's hard to not do this. And even then, it gets corrected cluttered and you end up with this long tree of menues. But wait you say, just give it a macro! And at that point, what's the difference? In the terminal we recognize something fundamental: to know it's name is to have power over it.

Yes, this isn't everyone. Every person is on a different part of their journey. And like I said, the customization is about making you productive not trying to find the most optimal, because that idea is laughable. There are good defaults but optimal is personal.

This is why I'll always trust someone more when they live in the terminal. The GUI person might be faster at times but they're limited. The person who will fuck around and find out is the person who will eventually understand more about the complex things they work on. They're more likely to dig deep. And this is the thing silicon valley has lost, the sense of creating what can be, not what is, not someone else's vision but yours.

GUIs can be fine, but they are hard to get right, most are meh or just bad, and they are human resources sinks.

Is excrate some new jargon meaning to take something out of a crate? Or just a boring typo for extract?

So there's one factor to cut the search-space in ~half :)

I'm recently trying out worker[0] and so far it's great.

[0]: http://www.boomerangsworld.de/cms/worker/index.html

- power user workflows may differ from typical dev workflows. Imagine things that a point-and-click file manager solves quicker than the command-line. Example: manually organizing a bunch of .mp3s, or cleaning out misc downloads. A TUI file manager makes these tasks quicker too.

- quick directory navigation. cd is slow. There's solutions for a better cd, involving z or fzf or whatever. But a file manager should solve it too.

- a file manager, especially a two-pane view, is cognitively easier. Better UX. Example: Having a src/ pane on one side and dst/ on the other, selecting a few src/ files, then performing a copy command. You get instant visual feedback to confirm that the files appeared in dst/. Compared to ls, cp file1 file2 file3 dst/, ls dst/. I always feel the need to ls after commands because the command-line doesn't give much feedback.

tldr: speed, ux, comfort. But if you're already comfortable with your tools, I think that's the most important thing.

It's all about what you're used to and what you know. If you grew up in the age of the point-and-click GUI you might feel more comfortable using visual metaphors and stateful UIs for your intended actions. Others prefer to issue orders and have them obeyed without the song, dance, and lightshow.

The way I do it is a bit nuts though, and you're right, the above is much more consistent and has its advantages

I’m really curious about this, not to derail the thread.

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.

Where does it get installed? Will the user consent?

I did not use a Nerd Font until I tried superfile out today. It was not hard to build my own nerd font version of Berkeley Mono with font forge.

I'm on Linux Mint 19

You'll have to compile from source, or update your distro to a maintained version. Ubuntu 22.04 ships glibc 2.35, and so Mint 21 should work.

Mostly commenting because while this isn't really a tech support channel, being able to identify glibc version mismatch errors comes up extremely often, even in this day and age.

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 sorry state of affairs.

Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.

- any given release of a Linux distro will probably work on hardware released five years earlier -- one factor that reduces the cost of upgrading the OS (there are many more obvious factors)

- Microsoft is highly motivated to get customers to upgrade to the new Windows at the time. The legacy support is well-known as a "bone" (or: "a factor that reduces the cost of upgrading the OS")

- binary backwards/forwards compatibility is less of an issue in an environment that doesn't treat source code as a secret

- why run old versions of software? In other words: xterm is older than Windows and also as new as Windows

Also, I've always found it amusing that I have much less trouble running old windows software on a Linux (wine) than on new versions of windows.

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

With Go on Linux libc is only needed when the libc DNS resolver is used (instead of Go's built-in one) or if C libraries are used. superfile doesn't need either of these so it's very simple to build it as a pure Go executable which will be statically linked and contain no C code at all.

For example, you could write 'gum choose foo bar baz' to get a nice picker over the three provided options.

Their repo has a ton of examples: https://github.com/charmbracelet/gum

https://www.nerdfonts.com/

And here's an example of ligatures (see the image on the right - you type what's on the left, and the right image is what shows in your editor): https://hilton.org.uk/blog/fira-code

I think but am not sure as I haven't looked in a while, that the folder and file icons are part of the nerdfonts as well, that regular fonts would just show as the generic "missing glyph" symbol.

Is there any technical reason the font can't be shipped in the binary and installed automatically?

- this is what a package manager is for

- installing the font/s (from the application?) would be a bit of a dick move and also presents a technical challenge (in other words: that's what a package manager is for)

- concerns about the efficiency of many applications all shipping duplicate assets (package manager again)

- concerns about distribution rights

- not all users will want to use the same font and this is an unsolvable problem -- do you ship: no fonts | one unwanted font | the user's preferred font that they already have installed plus all the other user's fonts

Looks nice. I dig the nerd font thing, I'd never used them because all of my TUI stuff is ncurses and the like, it's a nice thing to be able to do. I like the outline. I don't like a few things.

- Ctrl keys galore. I'm partial to vim keys, a lot of the keybinds on here are vim style, why not make it all of them?

- some of the defaults are weird or potentially dangerous. There's no confirmation for deletion for example, PageUp and PageDown don't work, cursor auto wraparound is a little confusing for something like this, and the cursor isn't a highlight, just a >.

- Bubbletea always seem to have a minimum terminal size which drives me nuts. Btop and other programs I've used have this problem.

All in all I like the ability to open multiple panes, the ability to open network drives, see ongoing/completed processes and see the clipboard. I find I virtually never need more than two panes though, and there are plenty of CLI utilities for FTP and stuff. I'm probably going to stick with an old school dual pane like vifm or MC. I'll keep this on my machine and test it out some more next time I need to connect to an ftp server or something, I like that it provides most of the functionality that graphical file managers like Nautilus have, I do miss some of that stuff in my terminal oriented environment, but not enough to go full mouse, so it's good to know I have an option that gives me some of both.

By contrast, in macOS all the window/UI keybindings are typically Cmd (Cmd-W) which means that GUI applications attempting to layer on vi keybindings don’t have to also audit all the Ctrl keybindings that might be doing something wildly different compared to what vi users expect.

Cmd for UI and Ctrl for terminal just makes for such a nice default convention.

So the Cmd/Ctrl split on Mac maps nicely to the Win/Ctrl split on Linux.

For the reasons you suggest (WMs often heavily using the super key), I would not want it to be used in the macOS way as I have a few dozen keybinds I'd lose or have to remap then. Stuff like focusing or moving windows or workspaces. Emacs can also make use of the super key, though I don't know if it has anything bound using it by default.

The macOS approach is cool and makes some sense, but I wouldn't want it forced on me, and I'm kinda glad I didn't imprint on it.

But it seems that this hotkey is not good for many people. It may be changed in the next version. Thanks for your feedback.

But the good thing is they are just defaults. Hopefully there are already no legions of users resistant to any changes to defaults.

     Error downloading theme: Get "https://github.com/MHNightCat/superfile/raw/main/themeZip/v1.1.2/theme.zip": dial tcp: lookup github.com on 8.8.8.8:53: dial udp 8.8.8.8:53: connect: network is unreachable

1. Create a recursive symlink to itself: `ln -s test test`

2. open superfile and navigate to it.

3. Observe crash

Of course there are also entitled and rude people. But we should not set the standards based on a-holes.

> not a pile of discouraging issue reports

This is such a strange way to look at software development. Discouraging?

I would not expect someone to get familiar with my young code base and fix the issue themselves.

If you're taking suggestions, making file copies use rsync under the hood would be great. I used to copy files over sshfs with ranger a lot and then found out the hard way that it was occasionally failing/being interrupted and then silently moving on in the transfer queue, so I had partial and corrupted video files it took months to notice. I do also use rsync for transfers a lot of the time, but sometimes you wanna move a bunch of files to different directories, and something like ranger is just faster and easier. Especially when you don't want everything from the source on the destination for space reasons, so can't just rsync whole dirs to grab the new stuff.