How I use my terminal

As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.

We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.

Kudos to the people that would rather experience that, I guess.

Zoomer terminal maximalist here.

My thing is that most UIs use such poor use of the screen real estate. I get it, pretty is the priority. But when I want to do work, the padding on everything gets to be excessive. Additionally, it’s really nice to be able to host my dotfiles in GitHub and I can be in a 100% familiar environment within a couple minutes. I have a variety of machines I work on. Same thing goes for mouse usage. I’m much faster operating the keyboard, whereas I switch between mice and trackpads and sensitivities when I switch devices. Keyboards are mostly the same. Maybe it’s a skill issue on my part but oh well ;)

The point isn't really the lack of graphics, it's more about the use of a keyboard and text as a universal data format.

Graphical programs look nice but are a nightmare for interoperability.

Having said that, as an Emacs user I'm surprised that anyone goes to this much effort to not use Emacs. This is what it's made for and it's all built in the most hacker-friendly way imaginable.

Easily solved with scripting languages and REPL environments.

No need to experience like MS-DOS, CP/M, VMS and UNIX without X, is all that we can get hold of.

Same here. I'm also amused that the people that do like the experience haven't by this time replaced the protocol (termcap entries, escape sequences, etc) now that memory sizes and network speeds are many orders of magnitude higher than they were when the protocol they are using was designed.

It's difficult to express how amazing Emacs is to someone that hasn't used it long enough to really learn it. I used vi for 20 years before switching, and I'll never go back, but the me then just didn't realize what Emacs could do for me.

My issue with the terminal is the exact opposite, everything is monospaced, hard to read, and space-inefficient due to that. Keyboard use is not a terminal-only thing either, it's a problem with some modern UIs that are hostile to power users. I feel it's at least partly because power users that create their own tools removed themselves from serious GUI development and are too busy with fancy TUI doodads and dark themes instead.

I started coding using Borland Pascal on DOS. I went through many tools and in the end split the terminal / UI work depending on whether the language is actually bound to an IDE or a build system.

E.g.: not using Xcode for iOS dev doesn’t make much sense to me. At work we have a fully set-up IDE that works with our build system. I like QtCreator for C++.

But for web dev, scripting and blog writing, I find programs like VSCode extremely slow even with just minimal plugins. After a couple of years I got fed up and went back to vim in terminal.

I don't understand either. My theory is that working all the time in the terminal makes some devs feel like true hackers.

The horse and car comparison really doesn't work since if anything terminals are higher performance and efficiency than guis. They just have a learning curve and no eye candy.

> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.

Except that if you've ever seen someone who truly knows how to use a terminal, you'd be surprised how many times faster he can work than with any other UI-based workflow.

This may change with AI, but so far I'm not holding my breath.

On case per case basis, depending on what tools one makes use of.

I have been around in this world since the 1970's, and have been coding since 1986, I have seen my share.

Sure there are bad clis and good guis but that's the minority from my experience

Yeah, I've given up trying to be evangelical about Emacs. It makes me think of the red pill in the Matrix: noone can be told what Emacs is, you have to see it for yourself. People who want to take the pill will find someone like me to help them, but it has to start with them, not me.

Back in '05 I realised how crazy it was that everyone was using these shitty editors built in to bloated IDEs, all slightly different from each other. It's all just text! This caused me to discover vim and Emacs. This was about 10 years before editors like Atom and then VS Code caught on.

I tried vim for a while, did the tutorials and tried to believe that if I practised the keys I'd become a wizard. But it never paid off. But I'm glad I learnt to enter insertion mode and exit vi/m at least.

Emacs was not presented as well back then. It had (has?) a terrible looking GUI by default. But once I'd switched that off the keyboard interface and major/minor modes made so much sense. No surprise that VS Code uses the same model.

But then when I got into Elisp I can say I truly fell in love. I liked GNU/Linux before, but Emacs is what Free Software was always meant to be. Not just technically hackable but practically so. How many people edit their VS Code plugins to do exactly what they want? With Emacs you can hack everything right there in Emacs while it's running and then just go right back to where you were.

> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.

Most alternatives are much faster, easier to use, and more reliable than the horse. Just like the terminal, in fact: your metaphor was prefect, you just had it the wrong way round :)

Now extrapolate the experience to a complete operating system, instead of only the editor.

This is what systems like those from Xerox PARC, TI, Genera, ETHZ, Inferno had to offer, and we aren't still quite there in mainstream systems.

What languages are these systems based around? Maybe Lisp has something to do with it? I've been drawn to things like Guix and stumpwm for this reason. It would be a dream to have an entire OS built on a Lisp.

Literally twenty minutes ago, I had to submit several hospital invoices for insurance claims. The website, despite claiming it'd accept PDFs, didn't consider the PDFs I uploaded valid, but somehow PNGs worked. My first thought was 'let's script the conversion', but then I realised there were only six PDFs, so I opened Acrobat, and used keyboard navigation to run through the menus to export all PDFs to PNGs. Done in two minutes flat.

Had I chosen to script it, I would probably still be hunting for the CLI to convert PDFs to PNGs. Sometimes, the trade-off is not so clear.

I feel like the point of monospace is to be easier to read in text dense environments. I find it much easier to read a monospaced font in the terminal and it makes editing commands much nicer to work with.

Depends on what you do, really. If I need to edit a photo, of course I’ll use gui. For any kind of text manipulation, including coding, tui is simply superior.

There are plenty of good guis, they just tend to be for things other than programming. That said they do exist.

> As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.

GUI is not a superset or complete replacement of TUI. For many reasons, one of the reasons is that GUI is much harder and finicky to automate.

What makes TUI easier to automate?

Every command can be manipulated as text and repeated as many times as you wish. Every command is also stored in the history, can be saved to any notepad for future, shared with the community.

Every GUI automation is highly non-standard, ad hoc, finicky (usually, depends on exact pixel positions), possibly Turing complete, but even if it is, it's harder to use compared to writing a script.

The point of monospace is easy vertical alignment in code, tables, logs, and many other types of text. But you definitely lose fast visual shape acquisition and potential density of proportional fonts. CLI is fine conceptually, I'm talking about TUI which is different.

Wait, you're describing CLI: command line and infinite history. TUI is a distinct thing, it exists on an addressable 2D character grid instead of the bitmapped canvas. For example top and mc are TUI applications, but there's no command line in them (unless you count passing different parameters from the external CLI or a script, which you can also do with a GUI application as it's separate from the interface).

> Every GUI automation is highly non-standard, ad hoc, finicky (usually, depends on exact pixel positions), possibly Turing complete, but even if it is, it's harder to use compared to writing a script.

The same applies to TUI applications. How do you automate top or mc? Don't conflate presentation (which is silly to even attempt automating) with internal logic.

The entire reason for TUI to exist is that TUI apps can be used in a terminal window, alongside CLI, so you don't have to switch to a separate window. But fundamentally it's just "GUI on a character grid".

>the trade-off is not so clear.

Assuming very basic knowledge of CLI on Linux

    for i in *.pdf; do convert "$i" "$i".png; done

10 seconds flat

If you've never heard of convert (part of imagemagick) then:

    open chatgpt/gemini/claude/whatever, enter prompt:

    linux cli tool to convert pdf to png

Adds 30sec tops

Thank you for making my point for me.

fd -e pdf -x magick {} {/}.png

Took less than a minute to write, test, and get the right dependencies (nix-shell -p imagemagick ghostscript). Scales to any number of pdfs.

The terminal just wins probably 95% of the time as long as you know about available tools.

I think horses are the wrong comparison.

I think its more like walking. For some things walking is preferable to driving there. its even less effort for things that are nearby, it uses fewer resources, I can do it after having drink, I can go through places that are not accessible by car (foot paths)....

Agree, tho, on their defense, they look super cool and hackerish.

Now, velocity and confort, they don't beat any top IDE.

Working in the terminal gets you to make the best use of a single most efficient input source, the keyboard. Which, coincidentally, is what you need for coding. In visual ides (pretty much all of them), some actions can only be performed by using a mouse (because, well, it exists). In editors like nvim that's not the case and everything is accessible via keyboard, usually in some pretty logical and structured way, so that eventually you get used to longer key chords etc for doing various things.

That, plus the terminal (itself) is at your disposal because, uh, you're in it.

That, plus vim emulation in all major ides be it vscode or jetbrains is pretty wonky and not comparable to the real thing.

Not much to do with 'true hackers', it's sad there's people who actually think that.

(all of the above being purely subjective ofc; this can be an infinite argument)

You can't possibly argue that a terminal is easier to use than a GUI.

It's literally what brought computing into the mainstream, so you can click options that are presented to you rather than memorize a bunch of incantations.

I keep checking in on Mezzano, a Lisp-based OS. It only runs in a VM right now, but someday... who knows?

I beg to differ.

Smalltalk, Lisp, Cedar, Oberon, Limbo.

So I, running Windows, using PowerShell, already knowing CUA shortcuts, generally familiar with Acrobat and its features, having to eventually use the mouse and keyboard anyway to navigate a JS-heavy insurance website, additionally have to:

1. Install sh/bash to get `for`, or convert your 'handy one liner' to PowerShell, and verify it works

2. Install ImageMagick, then ask an LLM to tell me what to do

2.5 And somehow LLMs don't present `convert`, but `pdftoppm`, or worse, both, and give me one giant essay, without my pre-configuring the system prompt to be concise and not overly wordy and avoid meta-sentences like 'if you want more help let me know';

3. Then navigate to my website anyway, and upload everything.

So no, point not made for you. With my existing environment and existing knowledge, it took me two minutes to get the work done. Even the slightest search would have brought me above that measure. There is a local minimum for a certain n at which discoverable GUIs absolutely excel over CLIs.

> nix-shell

So I have to install NixOS to get your 'took me less than a minute to write, test, and get the right dependencies'. Given my work-flow, and since I don't use Nix, doing what I did was absolutely 100% faster.

> So I, running Windows, using PowerShell

Well, what can I say other than people don't usually get in races with lead weights tied to their ankles.

It's not a race; it is optimising the process for the input size, one's existing knowledge, and context-switch duration from an existing environment. If I had fifty PDFs, I'd look at scripting the result immediately. I had six, and I had Acrobat. I chose the GUI option, and it got me a decent result quickly enough.

A code analogy: it's a bit like how O(n^2) sort algorithms are the fastest for small n, and how most library sorts choose a different algorithm for different `n`. This is what I meant in my initial comment when I said

> Sometimes, the trade-off is not so clear.