Without a GUI: How to Live Entirely in a Terminal
linuxjournal.com
linuxjournal.com
>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.
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.
Have you ever tried MS Office + VBA for comparison purposes?
Microsoft does understand interoperability; Office suite integrates well together and applications respect power users. I like them for that.
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.
Ps I love working in the terminal too but see it hard nosed to do everything there.
I prefer terminal for git and file management; for programming sometimes i like ides more.
For what it's worth, it's a lot better now that it has a built-in terminal and async for plugins. Neovim has some nice features too.
I guess it's preference, but my preference is right.
> you are able to use vim inside emacs
It physically hurt to read this.
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.
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.
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.
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.
- https://github.com/justbur/emacs-which-key - http://spacemacs.org/
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):
https://magit.vc/screenshots/popup-diff.png
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.
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!).
- https://en.wikipedia.org/wiki/Canon_Cat - https://en.wikipedia.org/wiki/Archy - https://en.wikipedia.org/wiki/Ubiquity_(Firefox) - https://www.youtube.com/watch?v=BVVXNlOFqXA
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.
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...
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...
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.
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!
So yes, it's definitely inferior in this way.
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.
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.
Of course, we humans like short term returns and so most people don't make the investment to use a more efficient system.
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.
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.
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)
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?
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.
> old coot
checks out.
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.
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.
As in: what if.. you could use a GUI and type commands?
Some software, like CAD programs (AutoCAD, 3DS MAX) and games (HalfLife, Quake, etc) have been doing it forever, but all these solutions are ad-hoc.
We could have had this as a default.
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.
Where can I read up on this? I want to get more proficient with macOS and this sounds interesting.
guix: https://www.gnu.org/software/guix/ guile scheme: https://www.gnu.org/software/guile/
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.
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.
[1] https://repo.or.cz/elinks.git/shortlog
[2] https://github.com/andmarti1424/sc-im
[3] https://github.com/Canop/termimad
[4] https://github.com/visit1985/mdp
[5] https://github.com/jaspervdj/patat
Spreadheets[0], presentation[1], files management[2], true colors.
[0] https://www.gnu.org/software/emacs/manual/html_mono/ses.html
[1] https://orgmode.org/worg/org-tutorials/non-beamer-presentati...
[2] https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
> 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.
[1] - https://orgmode.org/worg/org-tutorials/org-spreadsheet-intro...
[2] - https://www.gnu.org/software/emacs/manual/; it also ships with Emacs, so you can read it off-line; just use M-x info.
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...
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.
I leveraged netcat to make an over-the-net backup of my modem in the process of converting it to OpenWRT, using busybox's netcat on the remote side.
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.
I've been collecting a minimal set of nicities for a while now, if anyone is interested:
https://github.com/ohazi/dotfiles
Giving the man page a cursory skim is recommended.
I wish TMUX would be capable of noticing and either fixing or suggesting a fix for that kind of garbage.
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.
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 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.
* 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/
* mutt: email, 'nuf said
* irssi: IRC
* surfraw; "elvi" providing CLI access to online tools and an Ecuadorian connection. https://wiki.archlinux.org/index.php/Surfraw
* wikipedia2text: Wikipedia on the command line. https://packages.debian.org/stretch/wikipedia2text
* tootstream: CLI Mastodon client. https://github.com/magicalraccoon/tootstream
* 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.io https://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.
* BSD Games. Because.
* Window manager: i3 or i3-gaps
* File manager: ranger or nnn
* Documents/Presentation: vim + markdown + pandoc. You can use pandoc to create both documents and slide presentations!
* PDF viewer: zathura
* Window manager: emacs
* File manager: emacs
* Documents/Presentation: emacs + latex mode
* PDF viewer: emacs
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.)
https://github.com/sdegutis/dotfiles/blob/master/.emacs.d/in...
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.
* Calculator: emacs (M-x calc)
* Mail reader: emacs (M-x gnus)
* Programming IDE and debugger: emacs
* Terminal: emacs (M-x shell, M-x eshell, or M-x ansi-term)
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?
https://github.com/emacs-evil/evil-collection https://github.com/noctuid/general.el
Now get off my lawn!
> I lasted all of ten days
> What follows are the applications I found myself relying upon the most during those fateful ten days
Why is this a new article now? What has changed since the original article series? https://www.networkworld.com/article/3085139/30-days-in-a-te...
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.
I don't have a problem if people want to use terminals in smaller windows.
I assume there are ways to fix this?
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).
CLIs are much easier to automate, though.
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.
--
[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.
mh and xmh
http://shop.oreilly.com/product/9781565920934.do
He's a co-author of the classic UNIX Power Tools
http://shop.oreilly.com/product/9780596003302.do
Add'l ORA pubs:
https://www.oreilly.com/pub/au/28#Books
"Power Tools" columns for Linux Magazine:
http://www.jpeek.com/articles/linuxmag/
Though I've not read it specifically, From Bash to Z Shell seems likely to focus on shell art and arcana most closely.
https://www.apress.com/us/book/9781590593769
His 1999 SVLUG talk was a classic, the slides don't give it justice, though there are some nuggets there for many users.
[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).
Why not go a little further and support variable width/pitch fonts?
Do you need to? Most likely no