Without a GUI: How to Live Entirely in a Terminal(linuxjournal.com)
linuxjournal.com
Without a GUI: How to Live Entirely in a Terminal
https://www.linuxjournal.com/content/without-gui-how-live-entirely-terminal
157 comments
> 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.
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.
> 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.
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.
"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?
Have you ever tried MS Office + VBA for comparison purposes?
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.
Microsoft does understand interoperability; Office suite integrates well together and applications respect power users. I like them for that.
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.
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.
What’s odd is why anyone would want to live in a terminal? It would be great if somebody can articulate that crisply.
Ps I love working in the terminal too but see it hard nosed to do everything there.
Ps I love working in the terminal too but see it hard nosed to do everything there.
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.
Lower cognitive load iif the terminal interface is good. Thats a big if.
I prefer terminal for git and file management; for programming sometimes i like ides more.
I prefer terminal for git and file management; for programming sometimes i like ides more.
I'm just gonna drop this here... vim is better. Surprising some one hasn't started the obligatory flame war all ready.
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.
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.
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.
Fair enough. I just don't get the idea of emacs replacing a shell.
> you are able to use vim inside emacs
It physically hurt to read this.
> you are able to use vim inside emacs
It physically hurt to read this.
> 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.
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.
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.
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.
- https://github.com/justbur/emacs-which-key - http://spacemacs.org/
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/
> 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
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.
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.
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!).
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.
- 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
- 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
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.
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...
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...
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...
Ah, that might be what he meant. Still not sure I agree, but it makes more sense than the "real men use ed" alternative! :)
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 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!
So yes, it's definitely inferior in this way.
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.
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.
Most CLI/TUI programs have integrated help.
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.
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.
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.
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.
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.
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)
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?
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.
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.
I tried to `curl -Method Post -Headers ...` my answer but it was too much work. Impressive.
Love the username!
Windows updates install automatically. What's the point of using a shell to install them? It's not like you're saving yourself from a clunky GUI.
What's the point of using automatic update? It's not like Microsoft hasn't bricked devices with it in the past.
You set up a backup for that extremely unlikely case.
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.
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.
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.
[deleted]
What would those principles be, that don't exist in current UIs?
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.
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.
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.
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.
The text editors all have that, afaik.
Because talking to the computer via text, perhaps over an RS232 or similar link, will be there when all of the more sophisticated systems go tits up.
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?
Also, why presume a terminal must have columns and rows? Maybe that started it.
> 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.
Where can I read up on this? I want to get more proficient with macOS and this sounds interesting.
Look at AppleScript or the new scripting bridge. Each app in macOS exposes an object model that you can call as if it were a Smalltalk object.
I don't really know much about Smalltalk, but guix is a linux distro that allows for impressive customize through Guile Scheme.
guix: https://www.gnu.org/software/guix/ guile scheme: https://www.gnu.org/software/guile/
guix: https://www.gnu.org/software/guix/ guile scheme: https://www.gnu.org/software/guile/
> 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.
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.
[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
[6] https://github.com/vifm/vifm
[7] https://github.com/termstandard/colors/
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
[6] https://github.com/vifm/vifm
[7] https://github.com/termstandard/colors/
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
[1] https://orgmode.org/worg/org-tutorials/non-beamer-presentati...
[2] https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...
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...
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.
[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.
> 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.
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.
+1 for patat. If you can live with its limitations, it is by far the most pleasant presentation writing experience I know of.
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...
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.
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.
Netcat (and. socat) are tremendously underappreciated.
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.
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.
mplayer works in the framebuffer
Also mpv, which has (generally) greater capabilities, and is what mplayer is increasingly mapped to on systems.
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.
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.
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
Giving the man page a cursory skim is recommended.
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.
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.
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.
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 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.
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.
I use ctrl-_ which is generated by "ctrl 7" or "ctrl /" on the terminal emulators I use (xterm and iTerm.app)
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
* 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.
* 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.
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
* 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
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
* Window manager: emacs
* File manager: emacs
* Documents/Presentation: emacs + latex mode
* PDF viewer: emacs
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.)
https://github.com/sdegutis/dotfiles/blob/master/.emacs.d/in...
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...
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.
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.
* Spreadsheet: emacs (M-x org-mode or M-x ses-mode)
* 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)
* 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)
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?
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?
Give Doom Emacs [0] a try. Lighter than Spacemacs.
[0]: https://github.com/hlissner/doom-emacs
[0]: https://github.com/hlissner/doom-emacs
Install evil-mode and evil-collection. I use general.el to configure a leader key and make my a personalized, stripped-down spacemacs. It's heaven.
https://github.com/emacs-evil/evil-collection https://github.com/noctuid/general.el
https://github.com/emacs-evil/evil-collection https://github.com/noctuid/general.el
I haven't used it but I hear that vim people like the EVIL package.
Try Spacemacs
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.
i3 is great because it lets you live entirely in a terminal until you need a window.
[deleted]
My first Linux computer was a 386 "laptop" with 4 megs of memory. It did not run X.
Now get off my lawn!
Now get off my lawn!
> 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...
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 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.
[deleted]
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?
I assume there are ways to fix this?
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.
[deleted]
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.
WordGrinder and Finch are user interfaces though? How is that "Without a GUI"?
They're not GUI, they're TUI.
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.
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.
Keyword being graphical.
The user interfaces have graphical components and menus if you bothered opening the link.
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
2: https://en.wikipedia.org/wiki/Text-based_user_interface
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
2: https://en.wikipedia.org/wiki/Text-based_user_interface
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.
--
[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.
What do you mean? Emacs way is strictly superior to ncurses here.
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)
If we're that pedantic, then any visual representation of plain text is also "graphical".
Another piece of software worth mentioning in this space is pianobar, which is a terminal based client for Pandora.
Similarly, tizonia[1] which is amazing for Spotify and Google Music and much more.
[1]http://tizonia.org/
[1]http://tizonia.org/
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)
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.
Larry Peek's book and tutorials on mh and nmh, as well as his shell wizardry generally, are very highly recommended.
I'm not familiar - I'll definitely check it out :)
Correction: Jerry, not Larry.
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.
http://www.jpeek.com/talks/svlug_19991103/
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.
http://www.jpeek.com/talks/svlug_19991103/
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).
[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).
> 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?
Why not go a little further and support variable width/pitch fonts?
Easy to VPN from another location. Just ssh to your remote Virtual Machine in another country.
Can you?
Yes
Do you need to? Most likely no
Do you need to? Most likely no
rerpha(5)
>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.