They are not 70s products but they look like 70s products. See my original comment about how those TUIs look and feel worse than programs you'd see in DOS despite having a lot more power and features available to them - even if you confine yourself to the basic colors (but many modern terminals also support -simple, yet usable- graphics, more colors and more characters).
> Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general.
Yes, it is basically a matter of fashion and what baffles me is that fashion.
I mean, even if you consider that terminal-based applications are great, why limit yourself to what a beefed up VT100 could do? Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list), why not having a command akin to "cat" that can decode and display image files right in the terminal, why not have an over-time graph in "perf"'s realtime TUI mode, Emacs already supports different font sizes when running as a GUI program, why not have this in terminal mode too, Clang's static analyzer can show you data flow-based errors, why not have graphical arrows superimposed over your syntax highlighted code when you run it from the terminal (Xcode already does that but it is a GUI), etc.
These are just some examples from the top of my head, i'm sure i can come up with even more.
I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
Lots of terminals do support graphics in various ways, e.g. formats like Sixel (bitmap graphics), ReGIS (vector graphics), and others. Several have experimented with folder icons. Many support e.g. URL matching, and some support outright hyperlinks.
My setup does use a Sixel enabled (and ReGIS but the ReGIS support is poor) Xterm.
Here's the thing:
Years of experience is that the gain is very much marginal. I really want to do more related to this, and it can sometimes be useful. But unless you're sending images over an ssh connection, Sixel output to xterm is no easier than opening another window most of the time. My ls replacement locally already shows symbols and uses colours; the benefit of going to images instead of unicode characters is minimal. Drawing lines instead of using Unicode box drawing is similarly such a marginal improvement that for most things it doesn't offer much.
There are things where it can be nice, such as e.g. being able to plot a histogram from output from shell tools without opening a separate window (and making it work over an ssh connection), but even then you can mostly get there with unicode characters too, and then you don't have to worry about whether or not you'll need to use those tools from somewhere without a Sixel or ReGIS enabled terminal.
And there's the rub: these gains in functionality are so marginal that the benefit is very easily lost when you often work on multiple machines, because suddenly you have to distribute them to all the machines you work on, or juggle between multiple sets of tools.
Yes, terminals do support graphics like they do support applications that look at last as good as applications you'd find on DOS (if not better), my point is that the programmers who make those applications do not take advantage of those.
And my point is that a large part of the reason for that is that experience with the terminals that originally supported this functionality, and modern attempts to resurrect it, is that even when you do have programs that takes advantage, the benefit is smaller than you might think.
I still want to do more with it. I grew up with an Amiga where the terminal was a system service that could be trivially embedded in a window and co-mingled with gui elements. I still think parts of that design are ahead of modern gui's. But it's also an ecosystem thing. It's more important to have software that works together than to get those gains that individually are quite minor. You first get the full benefits when things start coalescing into a greater whole.
> Why when typing "ls" not also have a tiny folder icon near the directories
This is already reality. Tools like lsd do that by default.
> I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
No. One of the main reasons I like this "limited" UI is because it also means less clutter. No popups, no stupid notifications or animations, no useless and seemingly infinite menus. Just relevant information and nothing else. I can imagine a UI without these limits, I've used it for decades, and now I'm glad I can often stay away from it. If there wasn't a huge problem with horrible overloaded UIs we wouldn't have plugins for blocking ads and scripts on websites or distraction-free modes in text editors.
I'm not against displaying simple graphics in the terminal(e.g. like ranger does), but there's a point where a decrease in limitations only means an increase in eye candy.
> They are not 70s products but they look like 70s products
I'm not sure how you could have a TUI that didn't look old. For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Sure, some terminals can display bitmapped images with 24-bit color, but you can't depend on that, especially for anything running over SSH or within Tmux, screen, emacs, (neo)vim, or some combination of these. These can create some very obscure bugs related to colors and keybindings, so you can't assume every key will work as expected or that your users will have color at all (I disable Vim syntax highlighting over SSH because it tends to demolish its performance, for example). This is why many TUIs are 16-color and use just ASCII characters - you don't know if the user can display emojis or if it'll show up as a garbled mess.
GUI applications (including text-based ones like gVim and emacs) have a lot more flexibility because they can control more than they can in a terminal and can guarantee 8- or 24-bit color instead of having to hope for 16-color support.
> Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list)
That would probably break a lot of scripts. I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
> For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys.
Realistically, what are the chances of this happening nowadays and how worth is it supporting such users?
> That would probably break a lot of scripts.
If an icon would break scripts, so would having colors, but it doesn't since ls knows when it outputs to a terminal or to a pipe and adjusts the output accordingly. But this misses the point, it could be another commands like vls (visual ls) or whatever, the point is the ability to use more than ASCII text.
> I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
An icon is more distinguishable from a single letter and using the -l view would not take advantage of any horizontal space you have.
> Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general.
Yes, it is basically a matter of fashion and what baffles me is that fashion.
I mean, even if you consider that terminal-based applications are great, why limit yourself to what a beefed up VT100 could do? Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list), why not having a command akin to "cat" that can decode and display image files right in the terminal, why not have an over-time graph in "perf"'s realtime TUI mode, Emacs already supports different font sizes when running as a GUI program, why not have this in terminal mode too, Clang's static analyzer can show you data flow-based errors, why not have graphical arrows superimposed over your syntax highlighted code when you run it from the terminal (Xcode already does that but it is a GUI), etc.
These are just some examples from the top of my head, i'm sure i can come up with even more.
I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.