For those not knowing, Windows Terminal uses Ctrl+C to abort the current process (as we'd expect) when nothing is selected, but copies when there is a selection. Similarly, Ctrl+V just pastes. So convenient!
Being used to that, Linux terminals become rather annoying. Yes there's other ways under Linux, but they don't have 25+ years of muscle memory associated with them, and so when the key shortcuts don't work as expected it's like nails on a chalkboard.
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.
This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.
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.
Of course still a nice option (esp. in terminals where the proper copy/paste are nerfed and selecting for editing is annoyingly not a thing), but far from a replacement for the proper clipboard.
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.
For those unaware:
> Unix interactive terminals use Control-V to mean "the next character should be treated literally" (the mnemonic here is "V is for verbatim"). This allows a user to insert a literal Control-C or Control-H or similar control characters that would otherwise be handled by the terminal. This behavior was copied by text editors like vi and Unix shells like bash and tcsh, which offer text editing on the command line.[3]
Running in tmux, marking anything on my terminal immediately puts it into the tmux buffer, without me having to click anything on the keyboard. Pressing middle-mouse pastes it.
THAT is convenience.
Are there any legitimate reasons to send Ctrl-C except to abort, that this could interfer with?
Kitty has a copy_or_interrupt action that behaves like you describe. Although, I think it would interfere with apps where ctrl-c is handled specially.
Edit: kitty also has a copy_or_noop action that passes through the ctrl+c if there is no selection.
You, uh, never tried middle clicking?
Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"?
Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?
I would avoid doing the PTY thing and instead do this (works on WSL if MAME is the windows version):
$ sudo socat TCP-LISTEN:1234,reuseaddr,fork EXEC:"/sbin/agetty -L - 9600 vt102",pty,setsid,ctty,stderr
$ mame -nomouse vt102 -rs232 null_modem -bitb socket.localhost:1234
I've had an idea to try to write a sort of high-level-ish VT220 emulator that pokes and patches the ROMs and the system to let you control it with the mouse, paste and stuff, lets you just doubleclick it to get a terminal, etc... I forgot about that until seeing this. Nobody would use it for more than 5 minutes but it would be funny.
Can you? The last I looked at it (a year or two ago), the vt220 in MAME was just the beginning skeleton of an implementation, and it doesn't seem to have been touched much since then. A shame, because AFAIK no "terminal emulator" implements vt220-style sixels (which are different than than the widely-implemented vt4xx-style sixels).
The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics
This is a KDE thing; it'll open in whatever terminal you've got configured in Default Applications.
- VTTEST <https://invisible-island.net/vttest/vttest.html>, which tests capabilities from VT-100 to VT-520 terminals.
- Markus Kuhn's UTF-8 test <https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>.
Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!
(I know you can fake scrollback search with tmux. It's not the same.)
It made for a more fun first experience with a terminal emulator than I expected to have.
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?)
https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
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.
By contrast, the tested version of ghostty v1.2.3 is two weeks old.
A tip for new users: The default theme is a bit harsh. I was able to port my Alacritty theme and other config by feeding the config file to an LLM (along with the Foot documentation). It generated a configuration that was 80-90% correct and only required about five minutes of manual fixes.
The result is now visually identical to my Alacritty setup, but Foot feels faster.
As to the "love" question, I still watch this video from time to time: https://www.youtube.com/watch?v=8gw0rXPMMPE :)
EDIT: I love the easter egg with the names of the developers across the Windows timeline :)
But I'm no power user.
It's just not enabled by default.
Compared the results (https://ucs-detect.readthedocs.io/results.html#general-tabul...) with what I use day-to-day (Alacritty) and seems the results were created with the same version I have locally installed, from Arch/CachyOS repos, namely 0.16.1 (42f49eeb).
This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
FWIW, it did get Powerline support and 24-bit color in macOS 26.
I tried `echo "\e[c"` (send device attributes) on mintty 2.8.1 just now and got "4" back ("VT132 with Advanced Video and Graphics").
- file management such as running "ls" where any filename has any non-ascii character such as a CJK or accented letter
- editing any text file in a terminal editor that isn't 100% ascii
- viewing/printing any data from any source, such as a log file/the web/'curl'ing something, where any language other than English or non-ascii character is used
- using various modern command line tools that insist on printing emojis in their output
setxkbmap -us option ctrl:swapcaps -option compose:rwin
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.
Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~
*Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.
Kitty is a lot more complex: it accepts five different encodings, has three different ways to load the data, supports animations, etc. So it's no wonder only a few terminal developers had time to implement it.
See also: https://github.com/veltza/st-sx/issues/1#issuecomment-190272... 5000 lines (Kitty) vs 1000 lines (Sixel) even though the Kitty patch is just a "subset".
Images as in "pictures" or is that something else? I'm using Alacritty, and I don't think I've once thought "I need to see this image inside the terminal" and I do deal with images and frames from videos a lot. Probably if I saw it being added to Alacritty I'd think it was adding unnecessary bloat, so I wouldn't be surprised not every terminal is rushing to implement it.
Or I completely misunderstand what you're talking about.
[1] https://yazi-rs.github.io/
Off the top of my head.
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.
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.
Kovid documented his rationale at some length here: https://github.com/kovidgoyal/kitty/issues/33
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
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 probably that requires a full fat video codec like H.264 to work well though. Or maybe RDP?
Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.
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.
Sixel has existed for 40y, Kitty protocol originated and initially made for a single project (Kitty) few years ago.
>why we have 2 competing protocols
Well, iTerm2 also got its own image protocol (predating Kitty's but basic, only meant to show images rather graphics in general) that has been adopted by few other projects. Terminology also got something on its own, and urxvt can show images by setting the background image.
For a text editor I'm making I ended up with:
> Unicode support is limited to what common modern terminal emulators support. In Hat, "character" is a Unicode codepoint. So no grapheme clustering, no variation selection, no ZWJs, no terminal emulator-specific logic. As long as every buffer byte is displayed and editable, we're ok.
https://github.com/ivanjermakov/hat/blob/master/CONTRIBUTING...
And I do basic codepoint range check to find its approximate width: https://github.com/ivanjermakov/hat/blob/00782dbaee1e1a814ce...
https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/us...
Maybe it's hard to find these days. However it had the best VT220 emulation I have seen running on X Window System.
I will note that I have not seen a terminal emulator that supports the "double wide" and "double high, double wide" character modes of the VT100. Those giant letters were kinda fun. (<esc>#3, <esc>#4, and <esc>#6 if my memory serves me right.)
It would not only fit more text on a line, while (probably) also being nearly as pleasing as a proportional font, but it would also still perfectly align indents. I think it could be a great markdown font.
Is this something people actually want?
One of the reasons I enjoy using the terminal is because the text is of a fixed size and monospaced. Even colors and bold text can be distracting at times. I certainly don't want my terminal to render Markdown...
I imagine the feature could be disabled, but still. I'm all for improving terminal UIs, but let's not turn them into a web browser.
SteamOS comes with Konsole, so that's what I've got installed in Linux. What am I missing out on by not using e.g. Ghostty?
(I know this article is about Unicode support, but I don't think I've ever had a hard time using a terminal because of its level of Unicode support.)
This is the actual end game of the worse is better philosophy.
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.
Edit- one example https://github.com/mmulet/term.everything
Since URLs are clickable in iTerm, you have the option to view a webpage in the terminal.
IMO it's unfair to compare barebones `st` with fully-featured terminals. The entire point of `st` is for users to apply their own patches to it, which does make it difficult to compare, since there's no standard version of it.
`st` is a pretty great terminal. I switched to `foot` when I migrated to Wayland a few months ago, but not for any practical reasons other than wanting to rely less on Xwayland.
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.
Really? Because IIRC they "support" it by treating the preceding emoji character as being Narrow instead of Wide. This is completely unsupported by anything in the Unicode standards: the codepoint sequences that affect the East Asian Width of their first codepoints are explicitly enumerated, and none of them have emojis and/or VS-15 in it. So no, it's not "correctly" supported. Emojis are Wide (terminal width 2) with or without VS-15/VS-16, and if fonts have textual renditions of them that are only 1 cell wide, well, that's the fonts' problems, just as fonts that have e.g. glyphs for Playing Cards block with visible width of 1.5 (I am looking at you, Google Noto) are wrong too.
Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that.
And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes.
VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).
Should I switch to something else or just keep on truckin?
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.
Very customizable and extensible using Lua. Extensive documentation, native ssh support and built-in multiplexing.
I prefer it's UI and level of customization.
Ghostty animations run like crap for me on linux (not sure why).
It has a very extensive Lua API.