It's odd to me that Emacs wasn't mentioned at all. I use it for most of my computing (email, music, file management, etc.) and it works well enough in the terminal if the Meta-key works properly, as opposed to needing to use Escape.
>Luckily, people were emailing each other from UNIX/Linux machines long before modern graphical email clients (or webmail) even existed.
I suppose this is technically true, due to the use of ''modern'' here, but I find it important to note that graphical interfaces for things such as email have existed for decades. Using terminals shouldn't be an ideal.
I find the native terminal emulation provided by the Linux kernel and OpenBSD to be lacking. There's not much of a good reason to query terminfo or termcap when every terminal you're reasonably going to use supports a superset of ECMA-48. However, I've found that even basic sequences such as SCROLL UP and SCROLL DOWN aren't supported in the native terminals. So, you get the choice between your program not working in those, making it inefficient and jittery for every terminal, or building a querying infrastructure; the first option is what I've chosen. If I'm wrong or anyone has any advice for this, I'd be interested in it.
I wouldn't be writing a terminal program in this age if the GUI facilities of modern systems were decent and I could build up my own abstraction for that, but the terminal, with all of its added faults, is at least the simpler option. It would be nice to have facilities GUIs enjoy that let me express simple concepts such as ''The interface must be at least this large.'', though.
> It's odd to me that Emacs wasn't mentioned at all. I use it for most of my computing (email, music, file management, etc.) and it works well enough in the terminal if the Meta-key works properly, as opposed to needing to use Escape.
Yes, and literally every point on his list has something in Emacs to handle it -- it is my favorite operating system, just needs a good text editor, as the old joke goes.
Sure, not all of the in-emacs tools are as nice as some of things like `w3m` and `w3m-image`... but they are all there, for every facet listed, and some of them are even better in Emacs.
Old joke aside, I bet Emacs' text editing and word processing abilities (with some packages installed) are as good as or better than those found in WordGrinder.
Emacs plays nice with `tmux`, but also provides its own in-emacs windowing.
You can even run full ANSI terminals within Emacs and then run anything (such as `cmus`) that might not have a direct in-emacs integration within an Emacs terminal buffer.
Even if not, interoperability is the killer feature of Emacs as a platform. Just try to shuttle data between spreadsheet, e-mail and web-browser with the tools mentioned above. In Emacs it's trivial - and not only that, it's also trivial to write snippets of elisp that shuttle the data for you or otherwise automate whatever workflow you have.
Ironically though in this case, emacs doesn't play nearly as nice itself though when run without X or it's GUI. I used nox-emacs for years before finally giving up and switched to the GUI. For instance, w3m will only display images when you are in a GUI window, where I've gotten w3m from a proper frame buffer displaying fine.
Running emacs in a terminal defeats the entire notion of "without a GUI"
Emacs in a terminal is still a GUI, its just one that is poorly drawn using characters for every cell rather than using pixels. If you're going to use a GUI then why not use one that can render at a pixel level.
Any sort of "curses" interface in a terminal is a GUI.
I find programming arbitrary combinations of programs to work together (i.e. processing information through some flowchart) much more productive and easier with terminal interfaces than GUIs. Terminal interfaces are also easier to use remotely, in my experience. Otherwise, they're good or bad depending upon the program implementation in question.
Emacs and vim are entirely different things. I wouldn’t want to use vim for some of the things you can do in emacs(although technically possible). Vim is a better text editor, but fortunately you are able to use vim inside emacs.
> Alt-N goes to the next "window", Alt-P to the previous and so forth
Thanks to this sentence, it dawned on me that even if you're a l33t hax0r, GUI and mouse-based interfaces have the advantage of not requiring you to remember how to use a program. How many program interfaces can you keep in your long term memory? Is it even worth it to waste your precious (human) memory space in such a thing?
Sure, TUIs and UNIX commands can be really useful and efficient once you learn them, but GUIs are useful even if you've never used the program. They give you an acceptable level of productivity right off the bat, and most of the time it's not worth it to waste your time learning the superior UNIX/terminal version.
> They give you an acceptable level of productivity right off the bat, and most of the time it's not worth it to waste your time learning the superior UNIX/terminal version.
The problem is, GUIs usually give you ridiculously low ceiling for productivity. So you're forever stuck with the level of productivity you get right off the bat. It used to be that GUI software had keyboard shortcuts for most operations (in particular, Windows made it really easy to do, and expected you to do it) - but then the web came and it all flew out of the window.
So part of the reason to use TUIs and Unix commands is because modern GUI philosophy makes my mind throw exceptions from boredom in the middle of doing something.
> How many program interfaces can you keep in your long term memory? Is it even worth it to waste your precious (human) memory space in such a thing?
Quite many. Human memory has natural garbage collection, so don't worry, you're not wasting anything. In this day and age, you're not really using your memory to its full natural capacity anyway.
And before someone says that learning a tool takes time, try this experiment: pick a tool with shortcuts you don't like, and spend one Pomodoro trying to operate in it. 25 minutes. There's a good chance you'll be past the mental block in that time, and the new navigation will already start to feel natural.
That natural garbage collection happens during sleep, you need to sleep on it a couple of times. So make that a staged 25 minutes, i.e. 10 mins one day, 10 mins the next, then 5 mins on the third day. Only then will the mental block be gone -- as long as there's only about 7 shortcuts you don't like (and that's plus or minus 2, probably minus).
Oh, and that's a good night's sleep, not a programmer's every-other-night sleep, so better stage that 25 mins over four days, not two.
While I agree that a GUI can be a bit more discoverable in general, I don't think CLIs (and more generally, terminal-based programs) are necessarily for the l33t crowd. We've just been conditioned that way by the fact that most user-facing applications these days are GUI based.
But think of the DOS-based programs of yore, like WordPerfect 5, and the Turbo C/Pascal IDEs... they had menus on screen, easy-to-access help screens, etc. to guide the novice. (What's the Web-app equivalent to the F1 key?) History shows that WordPerfect was fine to use as a non-technical person. (I wish our modern word processors were so simple to use as WP 5, actually -- modern app-design trends have bloated the word processor into a confusing mess, IMO, and I think the average office worker who has worked in both generations might agree.)
I really like the approach taken by the 'which-key' extension for Emacs, which is particularly well used in the Spacemacs distribution. Pressing the space bar pulls up a very nicely organized menu of actions, including access to help. It's extremely helpful both as a memory aid, and also for discovering new features.
Obviously a nice menu doesn't get the user fully past the initial Emacs learning curve, which supports your argument. But for the next level of user -- from novice to initiate -- it's a tremendous productivity boost.
> I really like the approach taken by the 'which-key' extension for Emacs, which is particularly well used in the Spacemacs distribution. Pressing the space bar pulls up a very nicely organized menu of actions, including access to help. It's extremely helpful both as a memory aid, and also for discovering new features.
It's even nicer than that (in particular, when you're not using Spacemacs): Emacs has a lot of multi-key commands (just like Vim). Whenever you pause in the middle of such command for a brief while (0.5 second by default), it'll pop up a sidebar listing you keys you can press to continue along with the command they execute. So e.g. there's a command you want to invoke, you remember it was under C-c something, but don't remember the exact combination. With which-key enabled, you just press C-c and wait until a list of available continuations shows itself. It's also useful for command discovery (what's there under C-c? what's under C-c C-v?).
Speaking of similar techniques, I like the way Magit works even better. Most commands involve several key presses, like "d d" for diffing against the thing you're pointing at, or "l l" to show current log. So whenever you press "d", a popup like this appears (bottom 2/3 of the screenshot):
It immediately shows you all the different keys related to [d]iffing, including some sequences that set flags (like e.g. -f). It disappears as soon as you press the key. The principle here is that you'll quickly memorize most frequently used commands and type them so fast you won't even notice the popup, but whenever you don't remember something or want to explore, there's always something showing you the next steps.
Totally agreed. Magit's interface feels like the "curated" approach -- they laid out all the options precisely to optimize your use of the tool. This is great to have in small, task-dedicated parts of Emacs. But then we also get complete, "uncurated" discoverability such as in your C-c example.
I think that Spacemacs is a decent compromise between the two, covering a large swath of functions with a loosely organized menu structure. Although they occasionally clobber some key bindings in an annoying way (org-mode and magit come to mind), it's nice to be able to find "text" things under the text menu, even when you don't remember the key-binding at all. It's surprising how well the three modalities (curated magit, general which-key, and semi-curated Spacemacs) work together, and stay out of each other's way (for the most part!).
Also, natural language can be quite discoverable if designed properly. Jef Raskin and his son Aza did quite a bit of work in this area. Things like Alfred on the Mac, and a bunch of different IDEs nibble around the edges of this concept with EMACS Meta-X taking it the farther than the others.
We acquired language so that we could express ourselves better than we could pointing and grunting. Learning a new word was always tricky- we could sometimes model it with existing words we already knew, but sometimes we would only learn it by practicing its use in different ways to see what works. When we might meet another person with another language, we may resort (at some point) to pointing and grunting again, but knowing language we feel the pains trying to convey anything beyond the most basic wants and wishes when resorting to such a crude tool.
So it is with text-based interfaces like unix. I learned unix over thirty years ago, and thirty years of practice with a language gives me a great deal of comfort learning the occasional new word in unix. Conversely, every time I point and grunt, I don't feel like it's an even remotely "acceptable level of productivity".
I do however think these TUI things are abominations combining the worst of both worlds.
Surely TUIs for editing text (nano, vi, emacs) are better than using something like `ed`. There's something to be said for having two dimensions to navigate in!
Not the parent but I took his comment to be a response to a comment above that mentioned DOS apps that had menus, used standard function keys, had "form controls" (e.g. buttons, lists), etc.
I think of a TUI not so much as a 2D text interface but more like text interfaces that work with a mouse, use similar constructs as GUI's like menus and form controls and standardize on conventions for displaying information in a uniform way across different applications.
Like I said, not the parent, so I may be wrong but there's my two cents...
Vim still qualifies as a TUI under that definition (since it supports using the mouse to select text, change or resize windows, etc), though I think Vi would not.
Agreed, although I'm glad Bram, et el. have not tried to add a text based "toolbar" or menu to Vim like in GVim.
But yeah, to this day after using Vim for years and years I still get a little surprised when I absent mindedly click on a Vim session in a terminal window and it moves the focus to whatever buffer I happened to click on.
I'm so used to ^W-^W that I forget this is even possible. Same with moving the cursor, selecting text, scrolling up and down, etc...
There is le editor. F10 brings up a menu. Shortcuts all around. It's nearly like an old turbo c/ pascal app, but it's available with a simple apt install le.
I've read many comments like yours over the years, but I've never understood how a GUI precludes using a language, whereas a text based interface means giving up the features of a GUI.
I wonder if there are many people that are as young or younger than the personal computer, who are stuck on the idea that a GUI is somehow inferior. Because I was about 7 when the first ones were available, so anything before that seemed like an obsolete relic.
I think you're trying to read me too narrowly and make a strawman out of what I said: My finding incredible value in text doesn't mean that I see no value in pointing and grunting. Besides the example I gave (having no common language), another good use is when precision isn't desired: I can freehand draw with a greater approximate precision than I can write a program to draw what I have in-mind. There are others as well.
But our grandparent poster said:
> > > GUI and mouse-based interfaces have the advantage of not requiring you to remember how to use a program. ... Is it even worth it to waste your precious (human) memory space in such a thing?
And my point is, if I spend my time learning a graphical workflow, I will undoubtedly have wasted it, for learning a textual workflow isn't much more work and the knowledge will pay dividends. I believe I am not unique in these regards, so yes, I don't think it's just worth it to me, but to lone_haxx0r (and you) as well.
Here's an example: I watched a graphic designer once doing a lot of work manipulating assets. He had spent the last hour translating all these artefacts for the web, so over the next 5 minutes or so, I learned some new unix words and wrote a little shell script to do that translation. The script ran quickly taking maybe another minute or so to do what would've been at least another hour of work the other way.
> stuck on the idea that a GUI is somehow inferior.
A GUI (and these TUI) will always require a coding of every workflow, and that workflow is undoubtedly written in text: Despite many efforts over many decades to tell the computer what to do purely graphically, we haven't begun to approach within an order of magnitude, the precision and productivity of textual interface. It's not turtles all-the-way-down!
This is probably part of why people like programs that follow a set of conventions. If all of my programs use vi keybindings, there's not much left for me to remember. This also covers GUIs to an extent; if every program had its own ideas about how scroll bars should be placed or work, or what each mouse button meant, then we'd struggle.
Anyway, I have to remember most of CSS, HTML, JS builtins, all kinds of syntax, posix API, std. C library, so bunch of shortcuts or commands in some weird ass MUA like mutt (I probably use 10-15 commands/shortcuts regularly), really doesn't add much.
The problem is that GUI/web programs are typically not easily extensible or composable. Though thanks to popularity SPAs, at least some web programs can be integrated with via internal REST APIs.
CLI tools don't usually have this problem.
Even if GUI tools have some scripting, it usually is ad-hoc and may not integrate that well with the rest of the system.
On the CLI side, you have a scripting system (shell) in which you're able to run and combinine all your tools.
Discoverability is discoverability, no matter whether you're operating in a text interface or a graphical one.
Look at nano for instance: all the essential commands are there, always displayed at the bottom of the screen. Nothing to remember.
This morning, it took me a solid 20 minutes to find the page on Amazon.com where I could tell them that my book marked as delivered wasn't, and that I needed them to send me a new one. This is something I've done many times before, within a GUI, but the feature is hidden away because the company wants it to be - the graphical nature of the interface is irrelevant here.
There's a tradeoff to be made between efficiency and ease of learning. For my environment that I use every single day, I'll go for efficiency all the way.
Of course, we humans like short term returns and so most people don't make the investment to use a more efficient system.
> How many program interfaces can you keep in your long term memory?
Infinity. A practical one. You can keep as much as you like.
> Is it even worth it to waste your precious (human) memory space in such a thing?
We do not know what is waste of memory and what is not. Really no one knows exactly how human mind works and how diversity of your motor skills influence your mind in general. It even could be that it have no impact at all!
> most of the time it's not worth it to waste your time learning the superior UNIX/terminal version.
You never know. The more commands you have learnt, the easier learning become. The learning is a recursive thing, you can learn to learn. So if you didn't learn to use TUI, you couldn't measure the difficulties of learning one more utility.
There's some level of GUI compitency or fimilarity - we have an understanding and expection of where menus should be and how they should work. I'd argue this is also the case with ncurses like software too - in fact a lot of programs support emacs style keyboard shortcuts.
You're also missing the distinction between keyboard shortcuts for a TUI and a CLI. Given a level of terminal compitency I'd argue that a CLI isn't any harder or is often easier to become compitent thanks to the UNIX philosophy.
Having a good shell (like zsh) that shows available flags with descriptions when hitting tab goes a long way toward not having to remember tools' flags.
These realizations are humorous to software folks of my generation who started on Punch Cards, then IBM 3270s, then VT100s and/or teletypes and Decwriters.
I see kids look at my two screen setup, which is on Windows 10, but basically a bunch of terminal windows open and think I'm some sort of l337 h4x0r when really I'm just an old coot who can't deal with change.
Even on Windows, I do everything in Powershell. Even things like installing Windows Updates. (Get-WindowsUpdate)
> These realizations are humorous to software folks of my generation who started on Punch Cards, then IBM 3270s, then VT100s and/or teletypes and Decwriters.
As someone who is also old enough to have used all these ancient technologies, I'm mystified as to why people today would want to go back to doing everything from a command line interface. Some things are really better done in GUIs. For example, why should I use diff if I can use kdiff3 instead?
I think a lot my nimbleness comes from avoiding the mouse...which can also be done fairly well in most GUIs.
In the case you mention, I'd reach for vimdiff. Maybe it's a career thing, but I've been shifted to enough different environments that I couldn't consistently learn and use the same GUI diff tool (commandline servers, Windows, macOS, Linuxes where I can only install new things to my homedir). It's also very nice to have your editor right there.
I work in VFX. Obviously all of the tools effectively require a GUI, but when dealing with large projects requiring a lot of files and servers I can't imagine only having a GUI.
Here are a bunch of use-cases that come to mind:
- We deal with a lot of image sequences; numbered files for each frame of video. Each piece of software has their own interface for "squishing" them down so you're looking at a list of file sequences instead of 1000s of individual files. Renumbering, renaming, or even sorting through them sucks in Windows Explorer, Finder, etc. A few simple commandline tools, many of which ship with any Linux terminal, make that easier. Although, I have found it much easier to use the GUI to pick out outliers (random frames that are 0-size, a grouping with a similar timestamp, random frames that are solid black). It's faster than building up a `ls -l | sort | grep | head`
- Remoting into servers. Just logging into 10 servers to see if a local file was installed or what Nvidia driver they're running. Remote desktop would be miserable or you'd need special tools. ssh in a for loop does this trivially--if you have more than a handful use GNU parallel or a flavor of ssh that does it concurrently.
- Most project files are ascii and there are a lot of situations where tweaking one or more of them saves a lot of time. For 1 file you can use a gui, if it's like 3 files you can use a macro in your IDE, 10-100 files you /can/ probably use an IDE but setting up a project and confirming it worked has more overhead than commandline tools.
- I still don't like any GUI file search tools in practice. I think it's because of the guardrails and optimizations? `find`, `grep`, and `locate` work way more predictably on system files, network paths, and USB drives, where GUI tools seem to have way more limitations.
But I'm the fist to admit I don't think it's the best way to work for everybody.
Why do we assume that there has to be this separation? Yes, we're used to it on Unix because Unix perpetuated the mistakes from OS/360 and had a special job control language as the user interface shell and made no attempt to really integrate a graphical environment when it came along.
But imagine someone whose programming career was spent on Smalltalk, who would feel quite confused by this. Or even someone who is truly proficient with NeXT or MacOS and able to use the object APIs that applications expose to script their environments efficiently. This would seem rather nonsensical to such a person.
> Why do we assume that there has to be this separation?
Because the GUIs of Smalltalk/Lisp era have mostly gone the way of the dodo. Unless you're writing software in Smalltalk or Common Lisp, you're unlikely to see truly powerful GUI principles any time soon.
The kind of UIs I think about have text commands and GUI commands being essentially the same; your clicking issues commands, but you can also start typing and then use mouse to select GUI elements as arguments - because things drawn on screen are first-class objects, not just their rendering.
Think e.g. of typing "ls" (or pressing a button) to be shown directory listing, on which now you can click, drag&drop, etc. You start typing "rm", and now all entries can be clicked to add as arguments. Or, you start typing "find -mtime" and now you can click on any of the visible timestamps, etc.
That's more of an implementation detail than a principle to me. Some graphics programs have CLIs. Lots of GUIs have CLIs with various levels of integration. And as you say, we've had that forever so it's not something that's, say, in a Smalltalk system that doesn't exist now.
That's a very parochial view. Why do you assume that text and RS232 are natural things? Remember when you booted a computer by entering initial instructions on a switch panel to get to reading a first instruction on some medium?
> Or even someone who is truly proficient with NeXT or MacOS and able to use the object APIs that applications expose to script their environments efficiently.
Where can I read up on this? I want to get more proficient with macOS and this sounds interesting.
> Wouldn't it be great if there was something like Pidgin, but entirely command-line based? [...] It turns out there is. It's called Finch, and it's made by the Pidgin folks.
Finch is not "command-line based"!
Finch is terminal-based, but it takes over your terminal and you interact with it like a mini windowed environment. These are not the same thing.
Software is "command-line based" if it's driven from a command line (gdb, ed, mail) or driven from the shell (nmh, git's cli).
Years back I actually threw together a libpurple client that decomposed the various actions into utilities that could be run from the shell, to experiment with some UI thoughts. Code is on github (https://github.com/dlthomas/genies/tree/master/msgg) but I don't remember what state it's in. Happy to dig in enough to answer any questions posed.
Elinks was still quite active[1] until 2 years ago any contributions were stopped.
For spreadsheets there is sc-im. For presentations in terminal there are termimad (in Rust)[3], mdp[4], and patat[5]. For files management vifm[6] is the best one, if you got used to Vim already.
And one more important thing - don't forget to setup true colors[7] in your terminal.
Also web browsing, mail reading/sending, authoring. Emacs can handle essentially everything in the article. It's a perfect middle ground - not 1D like pure CLI, not "bitmap" like TUIs (ncurses-based in particular), which are essentially rendering bitmaps on the screen, but in ASCII, not a point&click GUI. Emacs gives you a 2D text GUI, in which almost everything interoperates with everything else, and things like searching through or editing whatever 2D interface you have on screen aren't weird, but normal.
wow ses really blew my mind. I didnt know that emacs has a spreadsheet buitin. where do you find all those hidden goodies? is there a lost manual of emacs where they are listed?
See also Org Mode, which has basic[0] spreadsheet capabilities[1].
> is there a lost manual of emacs where they are listed?
That first link GP posted is literally a link to the Emacs manual[2]. Emacs and its info pages are something I also ignored for years, but one day I finally realized that I'm doing a disservice to myself by not reading manuals. Nowadays, I try to always read whatever official documentation there is for anything I work with more frequently; in some cases cover to cover. It's worth it.
--
[0] - by basic I mean basic, until you learn enough Emacs to supercharge them; then there aren't so basic anymore.
For nearly a decade I did most of my online reading through Elinks. It was comfortable for me to read things and always have a consistent font, size, color and no distractions. Sadly I haven't been able to as much in the past few years as more and more sites require JS or some TLS that isn't supported.
I've been a minimalist since my college days. Spent most of my time in college in the terminal and my first several jobs were mostly terminal (DNS, bash/perl scripting, firewalls/proxies). I lived on Sun Solaris using Netscape Navigator as my only real GUI product. I then moved to Linux running FVWM and Firefox.
Fortunately I can use Linux at my job and do so, using Remmina RDP to get into the Windows Servers when I do have to touch them. Still favor vim for config files and nano for personal notes. My wife walks by my laptop at home and wonders, "What's all that grey text in the black windows?" "That's work getting done, girl!" She rolls her eyes and walks away...
All CLI browsers I know are out of date, just don't work well, they contain unfixed vulnerabilities, or they're called Browsh.
Terminal: Alacritty
Browser: Browsh
Email: Mutt, Aerc
Remote SSH: Mosh
Discord: 6cord
IM: Bitlbee
IRC: Irssi, Weechat
Package manager:
Reverse engineering: Radare2
Network client: Netcat
Vim and Tmux with plugins are insanely powerful and customizable. I guess what I miss is a video player which just works in the terminal (without using ascii/ansi).
PS: I like Bash, never used Zsh, but I prefer Fish.
When I was in college several years back, the NVidia card on my only computer, a Dell laptop, failed. X stopped working but framebuffer driver still works. I was not tech competent back then and didn't know exactly what went wrong. I spent more than 1 month with only CLI.
Perspective from a CJK user:
- To show and type Chinese, you need tools like zhcon/fbterm.
- You'll need to deal with encoding issues when ssh to remote server, or telnet to a terminal based BBS. luit is a good tool for that. GNU screen also have this built-in and in some cases better than luit.
Honestly if I had one complaint about terminals, it would be any time, every time, and how often a CLI program decides it's talking to xterm-color and the renderer deciding for some reason that it doesn't like talking xterm, and somehow the character stream decides to "clear" the screen and move the cursor to 0,0, and none of the characters get erased and suddenly nothing is readable. It happens far too often.
I wish TMUX would be capable of noticing and either fixing or suggesting a fix for that kind of garbage.
Completely agree. The problem is that there are half a dozen ways for a program to figure out where it's running, but (poorly) pattern matching on $TERM is way easier than checking for individual features with termcap.
It's also almost impossible to validate a program against different environments other than just manually trying as many as you can tolerate.
Also there are lots of systems with broken/incomplete/incorrect termcap databases, so now you're looking at kludgy exception lists anyway.
Tmux switched from using xterm- to screen- and then tmux- as its $TERM at some point, and adding a proper termcap entry, and it's mostly been a net positive, but some things definitely break as a result.
The most annoying thing is that $TERM is inherited over ssh, but the termcap db isn't, so it's not enough to have your local programs configured correctly, you need to have the same config (or at least a workaround) available on all of the remote systems you use.
Tldr: xterm- is ossified, and trying to do anything else, even the correct way, is a nightmare and often can't realistically be made to work.
You should take a look at the changes made for tmux 3. They’re going to break quite a few configs. It might also represent a new era for tmux, though, as it seems like the creator is adding some text UI primitives to it (eg the right-click menu). I also really love byobu, so it would be great to make it more powerful, too.
Yeah, I've had to maintain multiple config files because Amazon Linux, Debian stable, Debian testing, Ubuntu, Raspbian, various Fedora versions, etc. have all had different tmux versions at different times, and upgrading locally involves some termcap stuff that wasn't always reliable.
I fully expect to have to revisit this again soonish. But most of the tmux changes over the years have been clear positives, despite the config churn.
I see you're using the default prefix (C-b), with C-a being the 'recommended' alternative. I don't understand why it's so popular, as it breaks emacs-style navigation in readline applications, which is great for fixing typos/changing something in one of the previous commands.
I remapped my prefix to C-q. It's a relatively useless key (who needs flow control these days?) and it's close to the number row — you can press it and then quickly get to a number key.
C-a also breaks Emacs-style navigation in readline applications (jump to beginning of line, a pretty useful function). And of course it breaks navigation in Emacs too (which I frequently use over SSH). C-q is also useful in Emacs, so my tmux is remapped to use C-^ as the prefix key. Nothing useful sits there for other programs, and I personally don't need the tmux prefix often (I do 90% of things straight from Emacs, and it has its own windowing capability).
screen uses ctrl-a, so it was easier for people switching to tmux. Never did figure out why it was chosen for screen back in 1987. Emacs was around for 10 years by then but GNU Readline wouldn't be released for a few years yet.
* ranger is vim-inspired file manager with built-in viewers and extensive capabilities. In addition to POB (plain old bash) and mc, it's a go-to for me. https://github.com/ranger/ranger
* TWIN is the Text WINdowing environment. Yes, it's a full-on windowmanager for console. Somewhat rusty, but if nothing else, a novelty. https://sourceforge.net/projects/twin/
* mpv and mps-youtube: play media (audio and video) in console. mpv supports many sites and formats, while mps-youtube specialises in everyone's favourite video monopoly. Both offer numerous compelling advantages over Web UIs, starting with no comments or recommendations. mpsyt's search and locally-managed playlist features are a real treat. https://mpv.iohttps://github.com/mps-youtube/mps-youtube
* xine and mpv framebuffer and ascii-art (aalib) modes. Play full-screen video in console, either as framebuffer graphics, or rendered as text characters (not great, though novel). Bonus: try the 'bb' aalib demo.
* bc, dc, units, and ipcalc; all forms of calculators, from general to RPN to units-aware to IP functions.
Emacs is actually a surprisingly good file manager. Dired + Ivy + knowing a few obscure shortcuts, and it's significantly simpler, faster and safer than either using Finder or Terminal.
I've recently dusted off Emacs again after a few years of VS Code, indenting to use it for some JavaScript/TypeScript client work. If anyone's interested, here's my Emacs setup. If you temporarily move ~/.emacs.d and clone this there, and open Emacs, it'll setup the rest for you. (Although it's a bit bare-bones so it presumes you're already familiar with reading Emacs config files and figuring out how to use it.)
Fun dired trick: dired is essentially a styled, read-only output of `ls`, but you can use standard Emacs combination for switching buffer from/to read-only mode, C-x C-q. Once you've done that, you can literally edit the output of ls (or most of it) to make it reflect the desired state, and then press C-c C-c to commit, and dired will apply the changes.
I use it almost daily, it's particularly useful for batch renaming files - and since you're working with an editable text buffer, you can use whatever tools you like - like copy-paste, regex search&replace, multiple cursors, etc.
It's also smart enough to know to use a temporary intermediate filename when you rename multiple files to use each other's names, e.g. swapping a.txt and b.txt.
I tried emacs for about a week, but ended up just going back to vim because I'm comfortable with it.
However - over the years, I've realized that its not vim that I want, its really vim keybindings that I want. I have them built into pretty much everything (file manager, browsers, PDF navigation, etc). I like the workflow.
Can you recommend any good 'vim to emacs' conversion guides that keep the same vim keybinding workflow?
i3 (or something similarly light weight) really changed eveything for me. Especially the difference in both productivity and battery life over all other solutions I tried is something I can highly recommend. It completely turns ‘battery life is bad under Linux’; I consistently get far more hours under Linux with i3 than using ‘normal’ WMs or Windows.
Considering that his experiment failed, I'm not sure how he can still claim "Quite honestly, it is entirely possible to live completely without a GUI (more or less)—even today, in 2019". Maybe it is true, but he hasn't demonstrated it.
I would have found it more interesting if he had focused more on how you could efficiently use cli etc, instead of finding most gui-like ncurses clones of popular applications.
That screenshot of Wikipedia as rendered by w3m makes that browser look like it has some serious problems with Unicode text -- note how all the accented characters in the name "Slobodan Milošević" are rendered as question marks.
I just visited the Wikipedia page of "Slobodan Milošević" on w3m and it rendered fine. I imagine the terminal problem is that either the font that was used didn't support those characters, that the system locale encoding wasn't setup to support those characters, or that the terminal emulator didn't have support for the encoding used.
In the 1990's, I did some contract work while "in between computers". I had an amber-screened WYSE WY-50 terminal (library discard freebie), a US Robotics 14.4 kbps modem, and a phone line. That was the extent of my data-processing equipment.
Not as awesome as CLI, which features stuff like user action history, but you still get to use the terminal, so you get stuff like being able to use it inside `tmux`, or recording what's happening with `script`, or copy any text without the interface being able to disallow it, or pasting a generated set of user actions (when you skip terminal pasting protections) to automate your use of the program, or being able to safely automate its use with something like tk's `expect`, which allows you to factor-in whatever the program outputs (something you can't do with GUI without something like OCR).
There may be a general misconception of GUI[1] vs TUI[2] nowadays.
The requirement for a Graphical UI (GUI) is that the user interacts with it via graphical icons and visual indicators. These can exist within a terminal. So, personally I would say WordGrinder and Finch are GUIs in this literal sense. However, your typical lay user may not interpret it this way.
TUI is a sort of abstract term. Sometimes people mean Text UI and sometimes people mean Terminal UI. I don't think these are mutual exclusive. I would understand a text-only UI to be without any visual indicators, whereas terminal UI could be either text or visual. I guess its also worth noting that the phrase 'TUI' was coined after 'GUI'. Perhaps TUI was coined to differentiate the traditional GUI application (a window drawn on a screen with sliders/buttons) from the traditional terminal application (text-only commands). But nowadays, we have libraries like ncurses, that allow us to draw things within a terminal.
There are also at least two "types" of TUI; one is exemplified by ncurses-based apps - they're essentially GUIs that render to ASCII instead of bitmaps. Another is exemplified by everything that runs on Emacs as a platform - there, all[0] text in TUI is bona-fide data; you can search for it, jump to it, copy it, read it from other programs running on Emacs, etc. The latter style enables levels of interoperability unseen in GUIs and regular TUIs of today.
--
[0] - Almost; some modes use "graphical" indicators like horizontal lines which are really just decorations. You can mess with them if you try hard enough, but by default they'll be ignored by usual operations like navigation, search or copy/paste.
What exactly is stopping Emacs from improving its rendering and bringing it on par with "GUI"-like ncurses apps? They already support multiple on-screen windows, a global menubar and all sorts of "widgets" for interactive use.
oh give me a fucking break you know what it means, stop being obtuse. “how to live entirely in a terminal”. the author is talking about using terminal-only applications (which of course have interfaces and “graphical” components)
My favorite mail experience, by some margin, was using nmh (https://www.nongnu.org/nmh/). I recall it taking some doing to set up and then some aliases and such to make it usable - but then it was very usable.
I did that for about 7 years [1] and don't want to do it again.
[1]: including a few years on an actual terminal, not a computer running an application emulating a terminal, (connected to a modem, which in turn connected to a Unix computer on which I had an account, which in turn was connected to the internet).
Yesterday, I had to analyze some tabular data. Basically, I was given some CSVs and I had to return different CSVs derived from them. It was a lot of data, and what I had to do was a little complex. Took me a third to half a day.
Turns out the CSV files they gave me were wrong and pretty much unfixable. They'll have to create them again and I'll have to redo the work. Having done it in the terminal instead of a GUI allows me to simply re-execute my actions from my shell history, and do the same work in a few minutes.
Had I done this work in a GUI spreadsheet program, for example, ignoring the fact that it would probably freeze a lot on this amount of data, it would have basically meant redoing the same work by hand and take around the same amount of time. There is no history for GUI actions. I can't tell the computer to redo an arbitrary set of clicks and opening menus and dialogs and typing in fields that I did yesterday.
As another example, right now I'm monitoring the logs of a type of system running on all company branches, and I'm doing it with a simple:
for ip in "${ips[@]}"; do
ssh "$ip" 'tail -F path/to/log' | sed -u "s/^/$ip: /" &
done | tee combined.log
wait
Every time something new happens in any branch, I get a line about it, telling me what's up and where it happened. I can resize the terminal to any size; the whole of the screen realstate it occupies has only the information I need. I'm also simultaneously saving these log entries I'm monitoring for now.
The GUI version of this would be to install a graphics server on these servers and logging in with some remote desktop protocol to all of them at the same time. That's a lot of video feed streaming to my machine at once, in comparison to plain text. I guess I could set up the remote desktop windows in a grid and open some specialized file monitor GUI program (I don't know of any such equivalent to `tail -F`), and look at them separately. To save the logs, I guess I would have to record my desktop, producing a video file. Too bad I can't do much with it. I can't search the text that appears in it, like I could with the combined.log by grepping it.
GUIs rock when playing 3D games, editing images, watching video, etc, but they suck at pretty much everything that doesn't imply graphics. In my case, most things I do don't imply graphics, so living entirely in a terminal is a huge win for me.
I prefer a TUI to play video on the computer hooked up to my tv. The video is graphical of course, but the UI is good ol' mplayer in a tmux over ssh. Unlike every other media remote, when I need to type something I can use my tablet/laptop's decent input capability instead of pushing arrow keys on a remote to select a key on the TV's on-screen keyboard (the worst UI for anything I've ever had to deal with; other than my smart speaker with 6 buttons, 3 of which when accidentally touched seem to activate special modes in which no sound is produced and the meaning of the other buttons is changed, with the only feedback being the volume stripe emitting led patterns that I believe are a reference to Close Encounters, but don't get me started on that).
I prefer GUIs, preferably multi-windowed, to navigate and organize/edit/maintain complex hierarchical structures like filesystems or things that fit that model. Drag-and-drop in this type of situation is very helpful.
I've found `find`, zsh's extended glob, and its autocomplete menus, brace expansion, and the various file related shell utilities to be so useful, GUI file managers seem so useless to me now.
Yeah, you have a point. I've known people that type and execute potentially dangerous stuff without re-reading it or understanding what the command is supposed to do.
I just read and make sure of what I'm about to execute when I'm working with potentially dangerous commands. I can't remember a time where I've done something as disastrous as your example.
Then again, the same is possible with GUIs. People can select stuff without meaning to and deleting them without making sure of what they're doing.
That mistake would only cause minor inconvenience if you're using a snapshotting filesystem. If you aren't, there are lots of ways you can lose data, GUI or not.
I think a better analogy, though maybe not perfect, is a knife vs a tomato slicer[1].
Tomato slicers are safer, their features are more discoverable, and they're even easier to use, but they're bulky and less versatile.
Having gotten comfortable with a knife, I like that it's easier to keep clean, takes up less space, has far more uses than slicing tomatoes, and doesn't require complicated mechanisms to adjust the width of slices.
Knives are dangerous, yes, but I think most of us already easily handle that level of danger every day.
I'm in love with this analogy. Too many modern GUI applications are the software equivalents of 'unitasker' kitchen gadgets. However I must note that not all GUI applications have this problem; a few exceptional examples stand out as being knives, not unitaskers. Excel is a classic example. In fact, I consider Excel proof that when programmers of GUI applications don't sneer down their noses at users who aren't professional programmers, it is possible to create very powerful and flexible GUI applications that empower those non-programmer users to implement their own custom solutions to novel problems.
Sometimes I wonder if Excel could even be invented in recent years. Could you ever get an application like that past "UX experts" who think users should to be treated like idiot children?
Following the same analogy, I think Excel would be a rice cooker. You can do lots of things with it, like cooking rice, steaming vegetables, making soups, etc. You're right that it's not a unitasker, but in contrast to CLI utilities, it's not meant to be composable. With CLI, each tool specializes in doing one thing well and composing with other tools to do more complicated things. Using CLI equates to making your rice, soups and steamed vegetables with a stove, pots, lids, and steam baskets. The benefit being that you can use each of those things for more than just making your rice, soups and steamed vegetables, specially when composed with other tools, things that the rice cooker isn't prepared to do.
If you ever wish to fry some food, you can't with the rice cooker, but you can with the stove. You can compose it with a pot or a pan depending on your need.
Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line. *nix CLI for example is not an ideal of uniformity ([0]) and simplicity. It's not at the same level of simplicity as your common household knife, at least.
[0]: `--opt=val`, `--opt val`, `-opt=val`, `opt=val`. First two are usually interchangeable but sometimes not. Third one was completely unexpected for me (clang uses a mix of first, second and third). Forth one is easy, only `dd` uses it.
> Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line.
The way you write that makes it sound like you're taking several seconds to read and re-read commands you've written tens of thousands of times before. It doesn't have to be like that. Not every command is risky, and checking for mistakes takes an instant. If you're paying attention to what you're typing, you can know what you've written is correct even if you're not looking at the computer or keyboard. It's just about practice. The more you use the command line, the less mistakes you make.
Also, I find that use of GUI also carries significant cognitive burden, because there's is more room for human error, and I can't always rewind what I've done to recheck. With the CLI, I can scroll up or check my history to see exactly what I asked the computer to do, but when using a GUI, things are more manual, and there's no always-available equivalent to scrolling on the terminal or checking history, as if I had a Tivo on my desktop.
For example, using sqlite on CSVs versus working those CSVs on a spreadsheet program. Let's say I want to remove rows where a certain column is a certain value. In sqlite, I would just translate that last sentence to SQL and tell it to sqlite, leaving it in history and my terminal window like a chat conversation between me and my computer. In a spreadsheet, I think the natural thing to do would be to sort by the column, select the range of fields I see that have the mentioned value in the mentioned column, and delete them. Let's say I save, turn off the computer and leave. Then the next day, I would wonder if I could have possibly moved the mouse a little more than I should have, selecting one more row than I should have and deleted something I shouldn't have. Spreadsheets have undo/redo (by per-app convention only), but it probably doesn't save that undo history across reboots. So that information is lost. I'd have to compare the CSV I saved with the original. In a CLI, I would just look at the history of what I did yesterday and read (in SQL) "remove rows where a certain column is a certain value", and with that I can be sure that that mistake would have been impossible.
In other words, with CLI, I just need to make sure I'm translating what I want to code appropriately, and I'm free from the burden of caring about the possibilities for human errors, like those possible when working manually with data in a GUI.
> nix CLI for example is not an ideal of uniformity [...] `--opt=val`, `--opt val`, `-opt=val`, `opt=val`.
That's very rarely a problem. I don't forget the syntax of tools I'm using day by day. It could only happen on new tools or ones that I haven't used in a very, very long time. If I really am not sure of something like the syntax of options, I'll just give a quick check in the manual. Takes less than 5 seconds.
Also, I think GUIs are even less uniform. For example, it used to be that by convention, every GUI program had a menu-bar at the top, but for Firefox and Chromium now, probably the most used GUI programs worldwide right now, the menu-bar is basically non-existent. We now get a hamburger button or a vertical ellipsis button to our right. The interface is very non-standard. The guys who built Blender, the 3d modeling program, were also very creative in how they designed the GUI, with their splitable tiling subwindows. I don't know of any other interface like it. Gimp is also very unique in having different windows for differing things in the same running instance of the program. MS Office introduced the ribbon interface to replace the toolbars it had before.
Honestly, in comparison, I think CLIs are very uniform. The interface is much more restrictive, and doesn't allow for as much creativity.
> simplicity. It's not at the same level of simplicity as your common household knife, at least.
I think you're confusing simplicity with ease of use. CLI is simple like a knife and GUIs are easy to use like a tomato slicer. A knife is not easier than a tomato slicer, and a tomato slicer is not simpler than a knife.
Why is a CLI simpler than a GUI: Because for any one task, a GUI program's code will be mostly about the management of the GUI and have little to do with the task it's supposed to do, while a CLI program's code will be mostly about the task itself. The reason for that is that a CLI is super super simple. You take a list of string arguments, maybe read from stdin, maybe write to stdout or stderr, and return a status code. That's basically it. A GUI on the other hand, needs to create windows. redraw them regularly, listen for input, decide to play an animation over widgets when some event happens like when you hover over a button with the mouse, etc. If you check what a CLI program asks of the OS while it's running (via strace for example), the requests are normally very relatable to what the program is supposed to be doing. If you did that with a GUI program, you're going to be bombarded with the amount of system calls it makes for GUI shenanigans.
A second reason why a CLI is simpler is that CLI tools are composable while GUIs are not. This means that CLI tools can be made for very fine-grained functionalities. For example, you can't split a basic GUI file manager into multiple GUI programs, but can make a bunch of CLI utilities that handle the various tasks of a GUI file manager. Because they're so focused on a granular task they can solve it better. I mean, who's going get a better solution for the searching of files? A GUI file manager developer that needs to also cover many other things like file copy and move, or a CLI utility developer that is making a utility like `find` that is solely focused on finding files? CLI utilities are simpler because they're focused because they're composable.
CLIs are very much like knives: simple, versatile, composable.
using a mouse involves "aiming" which is both non-deterministic and unhealthy (for those whose work involves mostly typing: movement of mouse-hand back to keyboard, repeat until injuries arise).
keyboard based workflows are deterministic (read: faster and more reliable) and healthier (no weird lateral hand movements).
>Luckily, people were emailing each other from UNIX/Linux machines long before modern graphical email clients (or webmail) even existed.
I suppose this is technically true, due to the use of ''modern'' here, but I find it important to note that graphical interfaces for things such as email have existed for decades. Using terminals shouldn't be an ideal.
I find the native terminal emulation provided by the Linux kernel and OpenBSD to be lacking. There's not much of a good reason to query terminfo or termcap when every terminal you're reasonably going to use supports a superset of ECMA-48. However, I've found that even basic sequences such as SCROLL UP and SCROLL DOWN aren't supported in the native terminals. So, you get the choice between your program not working in those, making it inefficient and jittery for every terminal, or building a querying infrastructure; the first option is what I've chosen. If I'm wrong or anyone has any advice for this, I'd be interested in it.
I wouldn't be writing a terminal program in this age if the GUI facilities of modern systems were decent and I could build up my own abstraction for that, but the terminal, with all of its added faults, is at least the simpler option. It would be nice to have facilities GUIs enjoy that let me express simple concepts such as ''The interface must be at least this large.'', though.