
Without a GUI: How to Live Entirely in a Terminal - janvdberg
https://www.linuxjournal.com/content/without-gui-how-live-entirely-terminal
======
verisimilitudes
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.

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

~~~
TeMPOraL
> _and some of them are even better in Emacs._

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.

~~~
perl4ever
"Just try to shuttle data between spreadsheet, e-mail and web-browser with the
tools mentioned above"

Have you ever tried MS Office + VBA for comparison purposes?

~~~
TeMPOraL
I did! Elisp is a better language :).

Microsoft does understand interoperability; Office suite integrates well
together and applications respect power users. I like them for that.

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

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

\- [https://github.com/justbur/emacs-which-
key](https://github.com/justbur/emacs-which-key) \-
[http://spacemacs.org/](http://spacemacs.org/)

~~~
TeMPOraL
> _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):

[https://magit.vc/screenshots/popup-
diff.png](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.

~~~
gmfawcett
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!).

------
fortran77
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)

~~~
greenyoda
> 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?

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

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

~~~
TeMPOraL
> _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.

~~~
pvg
What would those principles be, that don't exist in current UIs?

~~~
romwell
One principle is that text/command interface and graphical user interface
aren't separated.

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.

~~~
TeMPOraL
Close, but this is still but a shadow.

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.

------
dllthomas
> 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](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.

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

[1]
[https://repo.or.cz/elinks.git/shortlog](https://repo.or.cz/elinks.git/shortlog)

[2] [https://github.com/andmarti1424/sc-
im](https://github.com/andmarti1424/sc-im)

[3] [https://github.com/Canop/termimad](https://github.com/Canop/termimad)

[4] [https://github.com/visit1985/mdp](https://github.com/visit1985/mdp)

[5] [https://github.com/jaspervdj/patat](https://github.com/jaspervdj/patat)

[6] [https://github.com/vifm/vifm](https://github.com/vifm/vifm)

[7]
[https://github.com/termstandard/colors/](https://github.com/termstandard/colors/)

~~~
ethelward
And Emacs (can work in console mode) offer alternatives for nearly everything
you mentioned :)

Spreadheets[0], presentation[1], files management[2], true colors.

[0]
[https://www.gnu.org/software/emacs/manual/html_mono/ses.html](https://www.gnu.org/software/emacs/manual/html_mono/ses.html)

[1] [https://orgmode.org/worg/org-tutorials/non-beamer-
presentati...](https://orgmode.org/worg/org-tutorials/non-beamer-
presentations.html)

[2]
[https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...](https://www.gnu.org/software/emacs/manual/html_node/emacs/Dired.html)

~~~
fxj
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?

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

[1] - [https://orgmode.org/worg/org-tutorials/org-spreadsheet-
intro...](https://orgmode.org/worg/org-tutorials/org-spreadsheet-intro.html)

[2] -
[https://www.gnu.org/software/emacs/manual/;](https://www.gnu.org/software/emacs/manual/;)
it also ships with Emacs, so you can read it off-line; just use M-x info.

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

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

~~~
roryrjb
mplayer works in the framebuffer

~~~
dredmorbius
Also mpv, which has (generally) greater capabilities, and is what mplayer is
increasingly mapped to on systems.

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

------
ohazi
tmux is a godsend, but there are a lot of things broken by default.

I've been collecting a minimal set of nicities for a while now, if anyone is
interested:

[https://github.com/ohazi/dotfiles](https://github.com/ohazi/dotfiles)

Giving the man page a cursory skim is recommended.

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

~~~
TeMPOraL
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).

------
dredmorbius
A few other mentions:

* 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](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/](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](https://wiki.archlinux.org/index.php/Surfraw)

* wikipedia2text: Wikipedia on the command line. [https://packages.debian.org/stretch/wikipedia2text](https://packages.debian.org/stretch/wikipedia2text)

* tootstream: CLI Mastodon client. [https://github.com/magicalraccoon/tootstream](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://mpv.io) [https://github.com/mps-youtube/mps-youtube](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.

------
groovybits
Might I suggest some alternatives:

* 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

~~~
tines
Here's the setup I like to use. A little complicated for some but I really
like it:

* Window manager: emacs

* File manager: emacs

* Documents/Presentation: emacs + latex mode

* PDF viewer: emacs

~~~
groovybits
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?

~~~
zaiste
Give Doom Emacs [0] a try. Lighter than Spacemacs.

[0]: [https://github.com/hlissner/doom-
emacs](https://github.com/hlissner/doom-emacs)

------
davidw
My first Linux computer was a 386 "laptop" with 4 megs of memory. It did not
run X.

Now get off my lawn!

------
zokier
> _About three years back_ , I attempted to live entirely on the command line
> for 30 days

> 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...](https://www.networkworld.com/article/3085139/30-days-in-a-terminal-
day-1-the-essentials.html)

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.

------
oarabbus_
I think terminal usage should be maximized, but certain tasks are done more
efficiently with a GUI

~~~
dllthomas
> I think terminal usage should be maximized

I don't have a problem if people want to use terminals in smaller windows.

------
smacktoward
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 assume there are ways to fix this?

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

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

------
jessmay
WordGrinder and Finch are user interfaces though? How is that "Without a GUI"?

~~~
dubcanada
Keyword being graphical.

~~~
jessmay
The user interfaces have graphical components and menus if you bothered
opening the link.

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

1:
[https://en.wikipedia.org/wiki/Graphical_user_interface](https://en.wikipedia.org/wiki/Graphical_user_interface)

2: [https://en.wikipedia.org/wiki/Text-
based_user_interface](https://en.wikipedia.org/wiki/Text-based_user_interface)

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

~~~
0815test
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.

~~~
TeMPOraL
What do you mean? Emacs way is strictly superior to ncurses here.

------
dllthomas
Another piece of software worth mentioning in this space is pianobar, which is
a terminal based client for Pandora.

~~~
buzzert
Similarly, tizonia[1] which is amazing for Spotify and Google Music and much
more.

[1][http://tizonia.org/](http://tizonia.org/)

~~~
dllthomas
Neat! Do you know offhand whether tizonia can read from a fifo? (or otherwise
easily have commands thrown at it from the shell / my wm)

------
dllthomas
My favorite mail experience, by some margin, was using nmh
([https://www.nongnu.org/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.

~~~
dredmorbius
Larry Peek's book and tutorials on mh and nmh, as well as his shell wizardry
generally, are very highly recommended.

~~~
dllthomas
I'm not familiar - I'll definitely check it out :)

~~~
dredmorbius
Correction: Jerry, not Larry.

 _mh and xmh_

[http://shop.oreilly.com/product/9781565920934.do](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](http://shop.oreilly.com/product/9780596003302.do)

Add'l ORA pubs:

[https://www.oreilly.com/pub/au/28#Books](https://www.oreilly.com/pub/au/28#Books)

"Power Tools" columns for _Linux Magazine_ :

[http://www.jpeek.com/articles/linuxmag/](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](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.

[http://www.jpeek.com/talks/svlug_19991103/](http://www.jpeek.com/talks/svlug_19991103/)

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

------
amelius
> w3m supports inline images (...)—seriously, a web browser with image
> support, inside the terminal. The future is now.

Why not go a little further and support variable width/pitch fonts?

------
ape4
Easy to VPN from another location. Just ssh to your remote Virtual Machine in
another country.

------
galkk
Can you? Yes

Do you need to? Most likely no

