In stark contrast to most GNU/*nix tools, I really liked MS-DOS's edit.com text editor. Unlike emacs or vim or even nano, it didn't have a bunch of invisible shortcut keys, just a Windows-like drop-down menu system (but rendered in DOS).
You could easily browse through the menu hierarchy, but still memorize certain shortcuts that you often use (just like Windows). In later versions you could even use the mouse to select things if you wanted to. It didn't try to force any one particular method onto you, but let you use the input you're most comfortable with.
So many CLI tools are incredibly idiomatic and require you to do something in a very particular way with no on screen hints. Even the help screen is normally hidden behind some key combo. TUI or not, that seems unnecessarily elitist.
I think some of the old telnet MUDs or BBS games are nice to learn from, whether they used helpful text prompts (you are here, this is what you can do) or just rendered graphical menus in ASCII with colors. For some reason I still don't quite understand, games still seem to have more UI focus than productivity apps. Maybe cuz they tend to target the general public instead of B2B users?
Another pattern I really like: In more modern GUI IDEs and editors like Sublime or Jetbrains or VScode, you can usually launch a floating command input bar that will search through available files, commands, settings, etc. That lets you quickly find the thing you want without knowing the key combo for it (like format code, or forking a branch, or turning off word wrap). It would be cool to have a LLM layer in there that could parse natural language (instead of a basic keyword search) and execute commands based on that.
I can't think about QBasic without thinking about that game with primates throwing bananas across a city at each other. Like a simpler version of Scorched Earth.
I'm also a fan of the TUI from Qbasic, it also appeared in Microsoft Works for DOS, Microsoft Word for DOS and probably other places.
The UI was refered to as COW character oriented windows. It would be good if it could be open sourced, for historical reference.
There were other interesting TUIs, the one in Defrag in DOS, and the Antivirus would change characters on the fly to generate a mouse cursor.
The TUI in DOSSHELL.exe would use customise some characters to draw icons.
Maybe Scott Hanselman could be persuaded to work on open sourcing all the COW apps.
(Honarable mention for EDIT in DOS7, which appears to be a rewrite, supporting long filenames).
In the modern era, there is YEdit from the author of YCmd, which implements a similar looking UI, in Windows http://www.malsmith.net/edit/
Some other TUIs of note included the ones in Wordperfect, Norton Utilities, and of course TurboVision (though the last has implementations in modern environments).
Not only that, I found it much easier to create TUIs on DOS than on a UN*X system. I still have a hard time with curses. Zortech c on DOS had a small set of screen functions, disp_*().
These are enhanced printf(), scanf(), getc() type functions by adding cursor positioning on an 80x25 screen. Pretty basic but you could create nice applications with these basic functions in Zortech c.
Granted, on DOS the screen size did not change as it does in UN*X, making TUIs easier.
On the systems (minis) I worked on decades ago, TUIs were far easier then anything I have seen since.
haha never put 1 and 2 together. i guess these days its either something CSS or curses. cursed style sheets? :') maybe someone can do everyone a solid and make a GUI to design TUIs ? hahah
MS-DOS also supported the 80x43 or 80x50 screen modes for extra information density. On later hardware you would have SVGA-based or VESA-based text modes with even more density, though by that time DOS itself had mostly fallen out of use.
If you loaded ANSI.SYS in your config.sys, then the procedure is exactly the same.
I think this will demonstrate color with ANSI.SYS and/or VT-color:
$ cat rgbdemo.sh
#!/bin/sh
alias p=printf
N=$(p \\033) N="$N[" x=30
for a in Bl R G Y B M C W # Black Red Green Yellow Blue Magenta Cyan White
do eval $a='$N'"'"$(( x))"m'" \
b$a='$N'"'"$((60 + x))"m'" \
${a}bg='$N'"'"$((10 + x))"m'" \
b${a}bg='$N'"'"$((70 + x))"m'" # bX=bright Xbg=background bXbg=brgt bgnd
x=$(( x + 1 ))
done # https://en.wikipedia.org/wiki/ANSI_escape_code
N=$N'0m'
echo "I am $Wbg$R red, $G green, $B and blue $N on a white background."
> Unlike emacs or vim or even nano, it didn't have a bunch of invisible shortcut keys, just a Windows-like drop-down menu system (but rendered in DOS).
really? the apex? that's an interesting perspective, to me.
there have been lots and lots of advancements in IDEs since then, are none of those advancements useful to you? not everyone needs or wants a lot of those things, i'm sure, but they have utility which the Turbo* console IDEs lacked.
Regarding the shortcut navigation, I use an extension called which-key[0] on Emacs for that. I believe there is a similar package with the same name for vim / nvim too.
That's ridiculous! The only invisible things in Emacs deserve to be so. For everything else, there is a menu bar which is also visible in terminal `emacs -nw` mode. Just add `(xterm-mouse-mode t)` to ~/.emacs to make sure the mouse works properly. Very pointy, very clicky, and nice pretty menus that tell you the shortcut of each function.
To enable the helpful mouse interface, run with this mode and add this to your hidden config file. What's a mode? How do I edit the config file until I fix my editor? This is such a unix answer.
To be fair if you're trying to start Emacs in a terminal instead of letting Emacs control its output on its own you've already gone off the beaten path.
The thing you want (the helpful mouse interface) is the Emacs default. The funny command-line flag is what makes it weird. Just don't use that flag.
"TUI" is "text(ual) user interface", not "terminal user interface". If the UI is (primarily?) made of text (which it is in Emacs' GUI mode) then it doesn't need to be in the terminal.
I really wish edit.com still existed for Windows and was built in. Every now and then I need to do some stuff on a Windows machine and find myself wishing for a simple terminal editor.
> "Thank you so much to everyone for engaging with this feature exploration! Your passion has generated a ton of excitement in our own team, and I’m happy to share our proposed direction, which is that we will work with Malcolm Smith (malxau), the maintainer of Yedit, to ship Edit in Windows! We plan to do this by forking the Yedit code to a new OSS repo on GitHub, under Microsoft (like terminal or powertoys)."
YEdit being an MIT licensed open-source recreation of the MS-DOS 5 editor, by a Microsoft employee: http://www.malsmith.net/edit/
Yeah, the Unix tools' unfriendliness comes from their history of being developed for a literal teletype, i.e. the computer's output would come out on a roll of paper, not a screen. In that environment you want to be very conservative with your output and can't really show a help screen. At least Vim tells you a couple of basic commands to get started with on its splash screen - ":q" to exit, ":help" for help. It still suffers from really poor discoverability and the fact that if you don't get you have to type a colon first, but interpret it as part of the help phrase and just press "q" on its own, you enter macro recording mode. Or bring up the history with "q:". Thinking about it, it should be pretty easy to add a menu bar showing the GUI entries, but experienced users obviously have zero incentive to do that.
You could easily browse through the menu hierarchy, but still memorize certain shortcuts that you often use (just like Windows). In later versions you could even use the mouse to select things if you wanted to. It didn't try to force any one particular method onto you, but let you use the input you're most comfortable with.
So many CLI tools are incredibly idiomatic and require you to do something in a very particular way with no on screen hints. Even the help screen is normally hidden behind some key combo. TUI or not, that seems unnecessarily elitist.
I think some of the old telnet MUDs or BBS games are nice to learn from, whether they used helpful text prompts (you are here, this is what you can do) or just rendered graphical menus in ASCII with colors. For some reason I still don't quite understand, games still seem to have more UI focus than productivity apps. Maybe cuz they tend to target the general public instead of B2B users?
Another pattern I really like: In more modern GUI IDEs and editors like Sublime or Jetbrains or VScode, you can usually launch a floating command input bar that will search through available files, commands, settings, etc. That lets you quickly find the thing you want without knowing the key combo for it (like format code, or forking a branch, or turning off word wrap). It would be cool to have a LLM layer in there that could parse natural language (instead of a basic keyword search) and execute commands based on that.