Hacker News

Heh, shortcut muscle memory is the reason I returned my Mac mini one week after trying it. I sure am not gonna remap my brain for apple after 20 years of Linux and windows.

I really do like Cmd key usage for any terminal in Mac. The ability to send Ctrl+C differently than Cmd+C in a Mac is joyous.

However, for most all other applications in Mac, I dislike the Mac command key. Especially in IDEs like vscode, etc.

And I really hate that the actual Ctrl key on a Mac is in the wrong place, having swapped places with Fn. It's like the first thing I have to remember to do on each Mac setup, swap those two keys.

Because I'm toggling between mac/windows/linux all day long, my poor muscle memory is always confused. And it would be nice if this could be unified. Unfortunately, I'm guessing it would have to be solved more by Apple than by Microsoft or Linux.

That's an X11 thing that Wayland had to reimplement because it's so convenient. The problem is when pasting into the terminal something that another program copied into the clipboard. That's ctrl-shift-c.

I thought about remapping copy and paste to their own keys, possibly a single one. Maybe on the number pad, which I never use. Or remapping ctrl-c.

Isn't this an X11-ism? I dont believe this is Wayland-specific

Yeah I know. I missed this for the first couple days, but didn't take much before forgetting it after the change to Windows. (anyway I keep using Linux at home)

>middle mouse button

Speaking for myself (although I suspect many others), I haven't used a mouse in well over a decade. To be clear, I am in the terminal all the time. So this is not a universal solution.

This is also a thing in X, not only Wayland.

Oh wow, I'm already using ghostty and didn't know about this. It works great, thanks!

Hope Kovid Goyal gets inspired by this

It comes with Windows, and has since 2022! Alas, if you mean Windows 10 then you can use some DISM magic to add it to an install image.

It is default in w11 25h2

I mean ctrl+c/v is just muscle memory, obviously there are tons of other way but ctrl+c/v are just the default and the one everyone knows.

So now we are moving away from Keyboard only Vim/Terminal thing to mouse for pasting?

I checked and it was actually the vt240. That one works.

VT5xx was the budget line with limited functionality, that's why only 525 among them supports ANSI color. The only fancy stuff was multisession (TD/SMP if you have all bits to support it) and "desktop accessories" like clock and calculator.

The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics

> I also love being able to right click on Dolphin and tell it to open Konsole in the current folder.

This is a KDE thing; it'll open in whatever terminal you've got configured in Default Applications.

> These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation.

Nitpick: this is incorrect. Easy counter-examples would be arrow symbols like →. UAX #11 helpfully explains what is "ambiguous" about those characters:

Ambiguous characters occur in East Asian legacy character sets as wide characters, but as narrow (i.e., normal-width) characters in non–East Asian usage. (Examples are the basic Greek and Cyrillic alphabet found in East Asian character sets, but also some of the mathematical symbols.) Private-use characters are considered ambiguous by default, because additional information is required to know whether they should be treated as wide or narrow.

In the other words, these characters have been commonly available in both Asian and non-Asian character sets and assigned different widths by them.

The terminal emulator knows what font is being used so it should be possible to predict it.

There seems to be a contingent that just doesn't use scroll back search, which I find kind of baffling.

Relevant GitHub issue: https://github.com/ghostty-org/ghostty/issues/189

> Now the only feature I need in Ghostty is Windows support.

I use ghostty on my mac but have you forgot about ctrl + f to find things support in ghostty (I don't think it has ctrl f support iirc right?)

Lol, mb, but I don't believe that's the case for Alacritty. As for the Apple Terminal, it is not great

The theme picker in Ghostty is above and beyond anything I’ve ever seen in a terminal.

I missed that one!

I would argue that anyone who uses the terminal enough to have opinions on which one they like best is very much a power user.

Ghostty uses GTK + GPU rendering while Foot uses Wayland primitives and CPU rendering.

Perhaps my needs are too pedestrian, but I don't believe I've ever needed anything more than what the macOS Terminal app is capable of. I've tried the vaunted iTerm2 and Ghostty among others but they never stuck.

Maybe it's better now, but when I started my time on OSX, the built in terminal defaulted to "unlimited" scrollback, so if you were used to tailing giant log files, it would beachball pretty quick. I spent the rest of my time using iterm2 instead; it defaulted to a sensible scrollback length; and at some point it added a progress bar when you made a giant paste.

In 10.10 they added scroll emulation and inline find.

I run Kitty and use this feature regularly. Most of the time, I rely on it within Yazi [1], a TUI file manager, but I can also display plots within the Julia REPL, thanks to the KittyTerminalImages.jl package [2]. It's even more crucial when I'm navigating a remote directory and need to check an image file, as I usually have timg [3] installed on those servers. Once you discover how valuable this is, it becomes a permanent part of your workflow.

[1] https://yazi-rs.github.io/

[2] https://github.com/simonschoelly/KittyTerminalImages.jl

[3] https://github.com/hzeller/timg

I have to say, (caveat, I have not tried any of these yet) that I am intrigued by all these features like graphics being added to terminals. It feel like exploring an alternate timeline 1990s where the GUI “lost” — of course in the absence of a successful Windows and Macintosh, terminals would have naturally gained these graphical abilities 30 years ago.

It’s pretty nice to ssh into a remote host and plot some data there without needing either X forwarding, or dumping to files and rsync’ing, or similar workarounds.

The alacritty maintainers reject any image protocols as unnecessary. I am fond of images in terminals, but I gotta say that I respect their decision, very good call. Not every terminal emulator should do the same.

Viewing an image in a terminal can be really handy for debugging ML systems that use images or bitmaps. You can also paste images directly into claude code as context.

Once while working on a daemon that did both ML and DSP on live audio I added the ability to play sounds and display spectrographs of in-memory audio data at various points of the internal pipeline to debug an issue that would have been difficult otherwise. Way quicker than dumping WAV files to view externally.

I'm not particularly fond of displaying images on the terminal in ways that would resemble a GUI.

That said, augmenting a shell-based workflow with tidbits such as this had me sold:

https://xcancel.com/thingskatedid/status/1316074032379248640...

https://xcancel.com/thingskatedid/status/1316075850580652032...

To achieve that, either Sixel or Kitty protocol is fine. IIRC Sixel works over SSH without any fuss, dunno about Kitty.

I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.

Yes, pictures. It's quite useful. Opening images on remotes for one. Viewing plots arbitrary python scripts create for another.

Off the top of my head.

It would be nice if matplotlib or Octave could display pretty plots and figures on a remote server, in the terminal.

Images in a terminal emulator is neat for stuff like `ranger`

FWIW The definitive thread on "images in terminals" is probably found in these threads:

https://gitlab.freedesktop.org/terminal-wg/specifications/-/...

https://gitlab.freedesktop.org/terminal-wg/specifications/-/...

there's lengthy discussion from just about everyone at this point in those threads, about why images in terminals is Hard

One of my pet proof of concept projects is figuring out how to ergonomically tunnel web apps over ssh without needing to fiddle with listen ports and port forwards. First attempt was to push http2 over stdio which actually worked, but it didn't really integrate well with terminal use. Currently I think similar approach to X forwarding makes sense, where SSH forwards one unix socket over ssh connection and then the applications can connect to that socket and put http2 traffic over that connection. Basically the idea is to make webapp tunneling as easy as X tunneling, so you can just type command in shell and (browser) window would pop open without any extra hassle. The neat thing is that because http2 has persistent connections with multiplexing etc built in, it works really well for this sort of hack; plain http 1.0 would be far more annoying.

> I wish there was a high performance way of remoting graphics over SSH. How cool would it be if you could SSH to a remote machine and it just showed you the remote desktop in the terminal itself? No messing around with port forwarding, weird X servers, etc

I think there's at least three different experiences here, and they're all valid, but I don't know what you really want.

A) remote desktop --- connect to a fully formed desktop environment (with SSH to authenticate, I guess?), possibly persisted and/or shared so you can connect back and get into the same place or share with another user?

B) run a program remotely and display it on your local terminal; essentially remote X, but I gather you're looking for more performance and maybe some other nice to haves? Maybe you want to transport audio too... Maybe you don't want the crap experience remote X has become since app developers don't spend any effort on it and you kind of get what you get, which is a lot of jank.

C) images in the terminal, with high performance. PNG should be ok for that, right? Maybe an extension for lossy compression might be nice depending.

At that point you're really better off using some other remoting protocol instead of trying to tunnel it all over a terminal session. There's nothing left of the original terminal.

drawterm under Unix clients and 9front cpu connections; but that's Unix Philosphy 2.0.

(161 comments) https://news.ycombinator.com/item?id=44362272

It would be different if I worked in chinese or hindi or something, or worked with other people who do. Also worth noting that even terminals that score badly on this benchmark handle most of the things you mention just fine (e.g. accented characters or check marks -- unicode that is well-behaved in terms of mapping a single code point to a single fixed width character). The places where the poorly ranked terminals lose points is mostly in pretty complicated cases that are far from what terminals were originally designed for. Also I have never encountered a command line tool that prints emoji -- and if I did, I would be annoyed.

Literally none of those is a situation I've ever encountered. I don't think it's as hard to avoid as you think.

Accented letters are easy under GNU/Linux or OBSD under X. Just launch:

    setxkbmap -us option ctrl:swapcaps -option compose:rwin 

> using various modern command line tools that insist on printing emojis in their output

Ugh. Unpopular opinion this but I personally find this practice repugnant. Same for when used in git commit messages, CI/CD task names and other such places. It just cheapens the quality of the product in my opinion

Graphical characters and symbols like ticks I’m fine with. I have no objection to people wanting to make the terminal pretty. But emojis in software feels like juvenile - like signing a formal letter with your gaming handle.

I 100% agree `st` is pretty great and comparing bare bones is unfair.

Thanks for that link! I suppose I should have provided a link to the variant I use which is https://github.com/bakkeby/st-flexipatch though I do have like 14 of my own private patches. :-) Because it really is a simple, hackable codebase.

I will say, though, that I doubt there are many unicode conformance patches floating about. I don't know though, and I haven't looked.

good call, you're right

It's 9front actually. VT100 it's killed except for legacy plaforms, it's seen like CP/M and Altair emulators where looked upon 1995-2000.

9front's libc with a minimal desktop based on a tweaked rio(1) and a taskbar plus a really simple file manager won. People god fed up of FX' and bells and whistles everywhere. A minimal RTF editor with simple options plus a simple spreadsheet with rc/awk support does things much faster. Oh, and, of course, you can damn bind/import devices (video cards, network cards, whole networks) from anywhere to anywhere with IPV6 and quantum networks.

Old GNU/Linuxen, OpenBSD et all are just virtualized at crazy speeds under photonic CPU's.

There's no SSH, just rcpu and quantum-secured factotum(1). Photonic GPU's and neural network devices just boot 9front themselves too, with zero delay. Forget VPN's, too. These are obsolete too.

Yes! Hoping I can get Neomutt to render HTML email without resorting to launching a browser.

Since URLs are clickable in iTerm, you have the option to view a webpage in the terminal.

Does "calling a system provided-component" (WKWebView) count as "built-in"?

Wezterm is actually programmable. I am looking to drop Kitty as it intentionally offers minimal tmux support and the text rendering options that made it superior for me are being deprecated.

Until Ghostty offers the scriptability found in wezterm and kitty (e.g., hit a keybind, spawn a new terminal and execute a font picker script), I am trying out wezterm, which is pretty great, but renders fonts too thin by default. I stare at this thing eight hours a day so text rendering is super important.

I have them all installed, but I use WezTerm most often because it is fastest to give me a window when I hit the assigned shortcut key. Ghostty is a hair slower. Kitty takes 2-3 seconds. I keep launching terminals pretty frequently, so this matters to me a lot. The only other feature that it must have is truecolor.

> People still use WezTerm when we have Kitty and Ghostty?

Very customizable and extensible using Lua. Extensive documentation, native ssh support and built-in multiplexing.

Folks have responded about WezTerm's programmability being the reason they like it, but if you don't mind I'd like to flip the question around: why do you prefer Kitty or Ghostty to WezTerm?

I prefer WezTerm over ghosttty and kitty.

I prefer it's UI and level of customization.

Ghostty animations run like crap for me on linux (not sure why).