Hacker News new | ask | show | jobs
by zmmmmm 1610 days ago
I love the general renaissance of terminal UI tools we are seeing in the last few years.

I can't quite put my finger on what I like about it so much. Something to do with the simplicity and directness of these UIs, guaranteed optimised for efficient keyboard nav, widespread adoption of vim-like navigation keys, and the fact that they link directly with my terminal shell so I can stay entirely in a stream of thought while working through complex series of tasks that weave in and out of these apps and shell interactions.

I do wish it was easier to select text from the terminal screen without using the mouse. It is supported in terminals to place text onto the system clipboard, but rarely implemented in most of these apps. It's the main reason my hands leave the keyboard.

10 comments

> I can't quite put my finger on what I like about it so much.

I can.

Doesn't require a 1.5GB build directory to make a 500MB binary that uses 3GB of RAM to display a chat client/music player/etc.

The node-based CLI tools kind of do though.
It boggles my mind people use Node for this.
'When all you have is a hammer'
I don't have a hammer, but I know how to import it!

Not sure what to do with it, I'll just import "structural connectors."

Hm. Oh, look, a "match tool to connector" library! Wait, it builds a map the wrong way. I'll just import a "reverse map" tool.

Hm. Well, whatever, my build directory is a few hundred GB and somehow includes all of McMaster's web inventory, but that's fine, SSDs are cheap!

And now I know that I need a "nail" for the hammer!

Sorry, can you tell I don't like modern web dev techniques and styles?

I mean, in a Node project, if I need some internal CLI tool, I'll just write a Node script. But for distributable apps, doesn't make much sense to me either.
Oh, do I have a terminal emulator to sell you:

https://hyper.is/

> Hyper is an Electron-based terminal

I mean Hyper is really just an IDE that's REPL focused and so it makes as much sense to be in Electron as VSCode.
It makes ALOT of sense that vscode is written in electron. Why would you think otherwise?
I don't read the parent comment as saying that vscode shouldn't be written in electron. I read it as the opposite, that they are defending the terminal emulator using electron.

Also, out of interest, what reasons would you give for vscode being written with electron?

I read it as sarcasm, cause writing a terminal emulator in electron is really a stretch, could be wrong ofc.

At first I was a bit irritated that vscode is build on electron. Then I found code-server, essentially vscode in the browser and fell in love with it. I can run a fully fledged IDE on a PI without using too much ram or CPU power because the client does a lot of the ui heavy lifting. Then also the other way around, I use code-server on my powerful tower pc and can connect to it via vpn to run heavy coding tasks directly on the server while not miss8ng a single IDE feature. I use the metals plug-in to code Scala backend services and it works incredibly well. Much better then using remote desktop applications (nomachine, vnc, xrdp etc.) on the go. It's even better then ssh when the connection is bad, like mosh but for ui.

Also, every app uses the same font and colors, there is no animation, its very responsive.
The submitted library features a physics-based animation system, so that may change
no thanks
That's definitely not true. While fonts may be the same, colours are definitely not. Many terminals support a very large array of colours. Lots of tools have animations for progress bar, and a shell us no guarantee of being responsive. Anything that displays git statuses in the prompt will take multiple seconds to be ready on a large project, and many will just silently pause while they chug away at whatever they're doing.

In terms of responsiveness, there are plenty of terminal based apps that respond poorly to window resizing (the flickerkng is incredibly frustrating to me), or just don't handle aspect ratio changes at all and clip the ends of lines. Some tui applications don't clear their screen buffer properly on quit so completely break scrolling back the terminal. Many terminals really suck for performance and can really really chug if you accidentally dump a large JSON file to the terminal, for example. That's not responsive at all.

Also, natural language is a better command interface than iconic point and click for intermediate to advanced users. The mouse studies that came out of Apple back in the day were based on testing against the mass market so their findings only apply to mom, pop, buddy and sis.
Have there been studies done on "advanced users"? I'm an advanced user and I think mouse based interfaces are great when mixed sensibly with keyboard shortcuts and command search (like VSCode's Ctrl-Shift-P).

I'm not going to ever use the Edit->Copy menu but I'm also not going to learn the shortcut to click the Ublock origin button in Chrome, which I do maybe once a month.

Do you have any evidence for your assertion? It sounds like snobbery.

lol. Too true..
> I do wish it was easier to select text from the terminal screen without using the mouse.

Check out TMUX. TMUX has a copy mode that can be used to navigate the scrollback buffer for any TMUX window/pane and select and copy text. By default, that text is copied to a TMUX paste buffer, but can be copied to the system buffer using a simple command (e.g., `tmux show-buffer | pbcopy` on macOS or `tmux show-buffer | xsel -b` on Linux/X11). You can set that command to run automatically when you copy, which saves a step if you do it often.

Also, if you enable vi keys in TMUX (e.g., add `set-window-option -g mode-keys vi` to ~/.tmux.conf), then you can navigate copy mode using vi navigation keys, including '/' and '?' for search within the scrollback buffer.

Alacritty has a similar thing built-in, without tmux if someone doesn't like it for some reason.
This kind of copy and paste is a bummer though since it isn’t aware of word wrapping.
I just checked. TMUX does not insert newlines if there were no newlines in the buffer. That's usually what you want.
Maybe it varies by version, but I get this behavior all the time.
If you are copying from a text-mode app that does its own word-wrapping by inserting newlines or moving the insertion point, then it may not be possible for TMUX to undo that. Copying from shell output like `cat somefile` or `wget something`, however, works like it's supposed to.
You can configure kitty to open the entire scrollback buffer in an editor or a pager(less/nvim etc).

https://github.com/kovidgoyal/kitty/issues/719

I wish there was something that have stdout in an env variable that is readily usable next time the prompt is available.
See https://sw.kovidgoyal.net/kitty/shell-integration in particular Open the output of the last command in a pager such as less
There is minimal effort in a CLI app compared to a full-fledged web app. I also appreciate how much faster things are when there is a CLI REST APP instead of a GUI front-end for the same application.
My first exposure to anything that could be related to professional day-to-day work was when my dad taught toddler-me how to use DOS in Windows 3.1

Unfortunately for me, I didn't do anything else remotely related to programming until my 20s. But I think this early exposure to a command line made it much easier to go through tutorials, since everything that I used to learn early on involved a unix terminal.

Anyways, command lines/terminals make me feel good. I don't think it's nostalgia. I'm not exactly sure what to call it.

It's the same feeling I get when I occasionally have to write Objective-C code. It's not the first language I learned, it's not my main daily language, and I'm not particularly good at it. But it's the first programming language that I was paid an actual salary to use. It helped me start my career, and it makes me happy. It just feels warm and comforting.

Same thing for me with terminals, I like it in a way that feels different than other things
It's because your interaction with the computer is based on language which is more natural than graphical point and click interaction.
> I love the general renaissance of terminal UI tools we are seeing in the last few years.

Terminals are underused. This is why I push for implementation of all off terminal codes such as double width and height, blink, smooth scrolling, ReGIS, Tek 4010 and so on. I had a small victory long ago by adding 25 and 50% fills in sysdig spectrograms so that running it on the framebuffer console looked better.

Imagine an htop using Tektronix graphics. Or ReGiS.

I managed to convince the Windows Terminal folks to support overline (so I could have a 3270-like status on tmux, where I added overline myself).

Now I got myself into promising to implement Tektronix for VTE.

I use tmux's scroll/select/copy/paste with vim bindings

Alacritty has this too, but I have never tried it because I use tmux.

Good point - perhaps this belongs much more in the terminal emulator layer. I will have to investigate the options there!
Tmux is a terminal emulator layer. It even has its own terminal type. (Well, shared by `screen`.)
> I do wish it was easier to select text from the terminal screen without using the mouse.

I've recently gotten into the habit of running my xterm inside Vim. At any given point I can do a `ctrl-\ ctrl-n` and edit the entire terminal history in Vim.

Very useful.

You can use TMUX for copy or a terminal that support it. I use alacritty and it supports direct copy with a vi move that turn the whole scrollback buffer into a vim-like buffer.
Tmux allows text selection like you describe.