[HN Gopher] State of Terminal Emulators in 2025: The Errant Cham...
___________________________________________________________________
State of Terminal Emulators in 2025: The Errant Champions
Author : SG-
Score : 255 points
Date : 2025-11-03 14:40 UTC (1 days ago)
(HTM) web link (www.jeffquast.com)
(TXT) w3m dump (www.jeffquast.com)
| audidude wrote:
| So the state of 2025 then tests a VTE that is from 2023? 4 major
| releases behind? And through a GTK 3 app, not even a GTK 4 one
| which will use the GPU?
| embedding-shape wrote:
| Which one is that about specifically? Maybe the author could
| fix it.
|
| 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).
| milliams wrote:
| Likewise I noticed that Konsole was version 23.08. I've just
| submitted a PR (https://github.com/jquast/ucs-detect/pull/14)
| to update it to 25.08.
| aidenn0 wrote:
| They accept PRs on the ucs-detect project for updated test
| results.
| scuderiaseb wrote:
| Nothing even mentioned on WezTerm really?
| embedding-shape wrote:
| It's in the results, even if not mentioned in the blogpost:
| https://ucs-detect.readthedocs.io/results.html#general-tabul...
| greggh wrote:
| People still use WezTerm when we have Kitty and Ghostty? Can
| you explain why? I'm actually interested to know what would
| make someone make that choice.
| alwillis wrote:
| > 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.
| pneumic wrote:
| 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.
| bbkane wrote:
| I had some issues with Wezterm fonts - I was able to
| configure it away: https://github.com/bbkane/dotfiles/tree/
| master/wezterm#fixed...
| sigmonsays wrote:
| 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).
| bbkane wrote:
| 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?
| qart wrote:
| 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.
| rashil2000 wrote:
| I love WezTerm! Recently switched from iTerm2 and programmed
| the hell out of it: https://rashil2000.me/blogs/tune-wezterm.
|
| It has a very extensive Lua API.
| skerit wrote:
| I see Ghostty does not support (and does not plan on adding
| support for) Sixels, instead preferring the Kitty image protocol.
|
| 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.
| didibus wrote:
| I think it's because Kitty and Ghostty are the newest
| terminals, so they came up with new modern options and
| solutions.
| embedding-shape wrote:
| > 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?
|
| 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.
| porridgeraisin wrote:
| 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.
| alwillis wrote:
| I've found it useful, when paired with a terminal file
| manager, to preview graphics in the terminal.
| the_gipsy wrote:
| 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.
| embedding-shape wrote:
| I didn't know, but I'm happy to hear we seemingly are
| aligned regardless :) Thanks for the additional context!
| ziotom78 wrote:
| 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
| leephillips wrote:
| Definitely. I use KittyTerminalImages.jl often, and also
| the image.nvim plugin for embedding images into a Markdown
| or other buffer in Neovim:
| https://github.com/3rd/image.nvim
| xp84 wrote:
| 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.
| wrs wrote:
| That alternate timeline started in 1982 with the Blit
| terminal. [0] It was a GUI made of overlapping terminals
| that had a serial graphics protocol.
|
| [0] https://www.osnews.com/story/26315/blit-a-multitasking-
| windo...
| trenchpilgrim wrote:
| 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.
| setopt wrote:
| 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.
| mikkupikku wrote:
| Images in a terminal emulator is neat for stuff like `ranger`
| lloeki wrote:
| 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.
| cb321 wrote:
| I can confirm that I just do it over ssh fine all the time
| -- gnuplot, img2sixel as an "image-cat", etc. (`st` with
| patches to add sixel support as discussed in various places
| in these comments.)
| bee_rider wrote:
| It would be nice if matplotlib or Octave could display pretty
| plots and figures on a remote server, in the terminal.
| kyawzazaw wrote:
| Curious, what do you do with this?
| mechanicum wrote:
| More than two, e.g. there's also the Inline Images Protocol
| supported by iTerm2 and WezTerm.
|
| Kovid documented his rationale at some length here:
| https://github.com/kovidgoyal/kitty/issues/33
| zadjii wrote:
| 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
| IshKebab wrote:
| IMO none of them are particularly useful. Sixels is hilariously
| inefficient. Kitty is slightly better because you can send data
| as PNG, but ... you have to send image data as PNG!
|
| 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.
| duskwuff wrote:
| 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.
| IshKebab wrote:
| There is though - the ssh authentication and connection is
| already handled, and I'm already in a terminal. When I quit
| the app or session I'm back in the terminal.
|
| If it worked it would greatly reduce the hassle.
|
| Think about all the TUI apps that exist. They're useful
| because they're convenient when working in a terminal, not
| because they look like shit.
| 9dev wrote:
| What you are looking for is forwarding an X session via
| SSH, and that has been supported since the dawn of time.
| trenchpilgrim wrote:
| Is there a wayland equivalent?
| IshKebab wrote:
| Closest is wprs
|
| https://github.com/wayland-transpositor/wprs
|
| I have yet to use it though because Wayland _still_ doesn
| 't work properly for me (it doesn't restore the desktop
| properly after sleep) so I'm still on X11... without
| compositing... because KWin's compositor causes random
| freezes.
|
| Yeay, Linux on the Desktop.
| yjftsjthsd-h wrote:
| Yes, waypipe
| IshKebab wrote:
| > Probably too many GUI naysayers and "What's wrong with
| remote X?" for this to ever happen though.
| Brian_K_White wrote:
| If I want to view an image file on a remote machine, and
| all I have is ssh... I just connect to that machine with
| filezilla and click on whatever files I want. I can even
| open files that aren't PNG! Even files that aren't even
| images at all. Mindblowing.
|
| A terminal with in-band graphics primitives is called an
| RDP client.
|
| We've had graphics terminals since RIP BBS's and even
| before that. If they were actually useful enough to be
| worth the bother, then we'd all have been using them all
| along and there wouldn't be posts like this.
|
| It's not a case of there's this awesome idea that just
| for some reason no one knows about. No, it's just not
| that awesome of an idea. It's not _harmful_ so it doesn
| 't bother me that most xterms support tektronix graphics,
| it's just a gimmick of no real value. It's a solution to
| no problem.
|
| Don't believe me? When was the last time you used
| passthrough printing? Or saw it being used even in some
| place where they do actually need to print? The terminals
| all still support it. It's just a thing that you don't
| need to do in-band in a tty, and today there is no reason
| to bother doing it that way even though you could. It's
| not better and does not solve a problem.
| anthk wrote:
| With sshfs and 'rclone mount' you forget the shell and
| everything it's a filesystem.
| IshKebab wrote:
| I don't think viewing files is the most compelling use
| case for this.
|
| > I just connect to that machine with filezilla
|
| "Just" carries a lot of hassle, and this only applies to
| viewing files.
| anthk wrote:
| drawterm under Unix clients and 9front cpu connections; but
| that's Unix Philosphy 2.0.
| zokier wrote:
| 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.
| anthk wrote:
| Check x2go.
| toast0 wrote:
| > 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.
| IshKebab wrote:
| Yeah I want all of those. Only the third one really works
| at the moment but it's also the least useful. The second
| one I think would be the most transformative because then
| all the TUI apps people use like htop, ncdu and so on can
| have decent graphics.
| alberth wrote:
| mitchellh says no plan to support Sixel:
|
| https://xcancel.com/mitchellh/status/1985432954089455856#m
| electroglyph wrote:
| to be fair, pretty much anything would be better than sixels
| shiomiru wrote:
| Sixel came earlier, and already fulfilled the basic requirement
| of "put pixels on screen in a single well-defined format"
| (something not even iTerm2's protocol does.)
|
| 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".
| forgotpwd16 wrote:
| >why is it only used
|
| 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.
| bartvk wrote:
| The terminal that comes with macOS version ends on the 29th place
| in the results.
| sccxy wrote:
| and terminal that comes with Windows is on the 4th place.
| alwillis wrote:
| Yeah... Apple hasn't done much with Terminal.app since they
| inherited it from NeXT back in the late '90s.
|
| FWIW, it did get Powerline support and 24-bit color in macOS
| 26.
| krackers wrote:
| In 10.10 they added scroll emulation and inline find.
| doug_durham wrote:
| Yeah, I don't understand. I spend my day in the macOS terminal
| app and the thought "Hey I'd like a better terminal" has never
| occurred to me.
| toast0 wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| sitzkrieg wrote:
| the ranking weighed fluffy things i do not want indeed
| Asooka wrote:
| I wonder how long until terminals support half of the XWindows
| protocol (as some weird combination of Markdown, HTML and escape
| codes, most probably). This is not a diss, I would actually be
| pretty happy with a pared-down GUI protocol in the terminal with
| extensive Unicode support.
| sph wrote:
| 2052: the whole of computing is VT100-compatible Javascript CLI
| applications running on a Javascript port of the Linux kernel,
| within a tab of Chromium.
|
| This is the actual end game of the _worse is better_
| philosophy.
| anthk wrote:
| 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.
| temp0826 wrote:
| There is an in-terminal wayland compositor (or two?) out there,
| fwiw.
|
| Edit- one example https://github.com/mmulet/term.everything
| dmd wrote:
| well iTerm2 now has a #&*%( web browser built in...
| alwillis wrote:
| 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.
| quesera wrote:
| By "browser" here, you mean lynx or links or w3m etc,
| right?
|
| Assuming so, what would be the benefit of rendering within
| neomutt instead of lynx?
| AceJohnny2 wrote:
| Does "calling a system provided-component" (WKWebView) count
| as "built-in"?
| dmd wrote:
| Clicking a link to launch an external web browser: no
|
| Viewing a webview inside the app itself: yes
| mfld wrote:
| While there's vscode console, I think that bare Xterm.js would be
| a nice addition to the list.
| iammrpayments wrote:
| I would use neovide over anything else if they supported macos
| tabs. It's the termianl with the best font readability for me.
| duskwuff wrote:
| Disappointingly, the native UI for tabbed windows on macOS
| changed _drastically_ in Tahoe (26.0). I really dislike the new
| tabs - they 're significantly larger, and much harder to
| integrate into a small window like a terminal.
| acuozzo wrote:
| There isn't a single mention of vttest results.
| altairprime wrote:
| What features tested by vttest, that aren't measured by ucs-
| detect, would you want to see added to ucs-detect?
| alkh wrote:
| I have been pretty happy with Alacritty for a while but just
| tried Ghostty and am a little bit mind-blown. The fact that it
| has a built-in theme picker is insanely convenient for people
| working on multiple computers at the same time(so the same theme
| might not work everywhere).
|
| Overall, it literally looks like a better Alacritty alternative.
| The creator(s) did a great job!
| hnlmorg wrote:
| I thought built in theme pickers were the norm...?
| alkh wrote:
| Lol, mb, but I don't believe that's the case for Alacritty.
| As for the Apple Terminal, it is not great
| hnlmorg wrote:
| Apple Terminal is a lot like Internet Explorer in the 00s:
| for power users it's only purpose is an interface to
| install something else which doesn't suck.
| altairprime wrote:
| As a decrepit old {COMMO} power user, anything that
| doesn't give me fully integrated scripting with
| expect/switch/dialog and a popup script editor, honestly
| hasn't been worth investing in further. So I've been on
| Linux console, Putty, and macOS Terminal ever since.
|
| My terminal.app color scheme uses P3 colors on 7% gray
| rather than the usual sRGB colors so that I can use an
| OKLCH equidistant palette, and I make extensive use of
| shift-cmd-up to select and copy "the previous command's
| output". I considered switching for 24-bit color but
| ultimately I prefer not having to learn a new
| "rudimentary" app that's deficient versus my nostalgia
| just like all the others, and it drastically reduces my
| stress level when working on other people's devices that
| I am proficient in working with an OEM environment.
|
| I occasionally use tabs but for the most part I prefer
| windows, so that I can drag them around and
| over/underlapped with other work I'm doing in my GUI. Not
| a big fan of screen and tmux except as their limited
| value to me in mitigating ssh disconnects when that's a
| concern.
|
| Perhaps your definition of power user is limited to uses
| aligned with your own?
| jjwiseman wrote:
| Oh wow, I haven't thought of COMMO in decades.
| altairprime wrote:
| I think of it every time I see 'ansible' come up, because
| the ability to create and run what everyone calls
| 'playbooks' now should have beeen _integrated into the
| terminal_ like it was back in the 80s over dialup. I 'm
| all for being able to git commit the resulting script
| (they're just text files!) but being able to launch a
| playbook _and halt it and repair it and resume_ was,
| like.
|
| Sigh.
| hnlmorg wrote:
| > Perhaps your definition of power user is limited to
| uses aligned with your own?
|
| I was clearly being flippant. Terminal.app does suck but
| if you're happy in it then I'm not going to judge.
|
| For what it's worth, I cut my teeth on very limited
| terminals of the 80s and 90s too.
|
| But I ended up writing my own terminal emulator because I
| wasn't entirely happy with any of the options available
| these days.
| altairprime wrote:
| > _Terminal.app does suck but if you're happy in it_
|
| Clarification: As noted above, Terminal.app is
| indistinguishably suck from all the rest in the areas
| that are materially important to me, so no meaningful
| gain in happiness exists with any current alternative. I
| enjoy one of the specific features it offers but I'd give
| that up the instant a _relevant-to-me_ improvement over
| the status quo was available. Perhaps someday.
| pseudalopex wrote:
| Where could I learn more of COMMO? How do current
| terminal emulators fall short? Wikipedia's article was
| minimal.[1]
|
| [1] https://en.wikipedia.org/wiki/Commo
| altairprime wrote:
| I would probably have to make a video, honestly. Have
| considered it. Usage faded out years before screen
| recording was accessible. I'm going to be late for class
| but I can't allow that article to stand unsupported by
| story tidbits.
|
| The built-in editor for all files had two modes, line-
| based and character based. In edit (char) mode, you
| edited the text file as usual. In line (command) mode,
| you selected lines and hit Return on them to begin
| execution there.
|
| Commands were wrapped in curly braces; non-wrapped text
| was ignored.
|
| The built-in phone directory was just a macro file with a
| dedicated keystroke; so you could structure and annotate
| it however you liked, and navigate it with search or with
| line-based mode up/down/pgup/pgdn as one would expect.
| Each entry was something like {dial 472627} {user x}
| {pass y} {ifca {goto :autologin_wwiv}} {end} with
| whatever niceties you enjoyed outside the curly braces.
|
| It understood {gets} and {puts} from the modem tty (I
| don't remember the actual command names) and it had
| conditional logic and substring index stuff.
|
| If you needed human input, you could throw a {dialog} and
| get it, acting according to the result.
|
| In modern parlance, imagine if your terminal emulator had
| ansible playbook support embedded into it and pressing
| alt-E popped up an editor for the playbook that let you
| start playback from any point in the script, JMP/GOTO-
| style.
|
| You can see an example playbook at https://ftpmirror.your
| .org/pub/misc/dos/cavebbs/The%20Cave%2... inside
| PWRMC30S.ZIP. Read everything that isn't a .MAC file
| first so that you know where to start reading. POWER.MAC
| is the main attraction; 53k of playbook macros serving as
| bionic assistance to TradeWars players.
|
| My own archives are currently probably-lost unless I get
| very lucky someday, or else I'd share my own archive of
| playbooks built up over five years to auto-dial and auto-
| QWK hundreds of local BBSes for two-way mailing list
| packets.
| bigstrat2003 wrote:
| I used IE back in the 00s (up until Chrome came out), and
| I certainly was a power user. I liked it just fine. I
| think that it's a matter of personal preference rather
| than something sucking (or not).
| hnlmorg wrote:
| I was clearly being flippant. But IE definitely sucked.
| phantasmish wrote:
| It's what I've used for years and it's entirely fine for
| me.
|
| For a long time I installed iterm2 because "that's what
| you do" but one day I realized I was suffering a little
| wasted disk space, slightly slower start-up, and slightly
| worse input latency, for... no reason, because I didn't
| do anything with it that Terminal.app couldn't do.
|
| 25 years on unixy operating systems. Spend tons of time
| in the terminal.
| alwillis wrote:
| The theme picker in Ghostty is above and beyond anything I've
| ever seen in a terminal.
| ashton314 wrote:
| Holy crap you're right. I just found that and it's amazing
| hnlmorg wrote:
| Why?
| mort96 wrote:
| The _only_ thing I 'm missing from ghostty is scrollback
| search. It's planned AFAIU, I hope it gets there eventually.
| Otherwise, ghostty has been pretty good.
|
| (I know you can fake scrollback search with tmux. It's not the
| same.)
| nusaru wrote:
| Relevant GitHub issue: https://github.com/ghostty-
| org/ghostty/issues/189
| Imustaskforhelp wrote:
| > To be completely clear, it's not on the "IMMEDIATE"
| roadmap (as noted in the prior comment). It's absolutely on
| the roadmap and I even already started some it in a branch.
| But as a passion project, we prioritize working on whatever
| we want and this isn't currently the priority. It's high on
| the list but not like.. next release ("immediate") priority
| at the time of this comment.
|
| I mean I can respect that, personally it isn't as a big of
| deal with me so I use ghostty on my mac but I would still
| think that I would advocate ghostty only after disclosing
| this to anyone to be really honest.
| dpatterbee wrote:
| It's planned for 1.3 in March
| https://ghostty.org/docs/install/release-
| notes/1-2-0#roadmap
| klooney wrote:
| There seems to be a contingent that just doesn't use scroll
| back search, which I find kind of baffling.
| sevg wrote:
| I've never used scrollback search, and it was a discovery
| for me that there's a contingent that are very vocal in
| their demands for scrollback search.
|
| I can see why someone would feel attached to this feature
| though.
|
| Mostly I'm looking forward to seeing it implemented so I
| can stop reading complaints about this being missing in
| every thread about ghostty!
| Shadowmist wrote:
| I wish they didn't lock the GitHub issue so that we could
| see how many thousands more reactions it would get.
| doritosfan84 wrote:
| My use cases are trying to find the one test that failed
| out of my suite and finding a specific log print when my
| app is running. Yes, there are other ways to do both of
| these. Having scrollback search in the terminal is a very
| convenient option though.
| bigstrat2003 wrote:
| Honestly, I had never even _heard_ of it before this very
| thread. It doesn 't seem all that useful to me, but I don't
| truthfully know how much or how little I would use it in
| practice.
| gsinclair wrote:
| Same here. What I think I'd like more is the ability to
| open the most recent command output in $EDITOR.
| __float wrote:
| There are a ton of people who _immediately_ open
| tmux/zellij/etc. when they're doing anything in the
| terminal. This means you use its backscroll and search
| feature, and you wouldn't notice.
|
| @mitchellh seems to rely on the Ghostty feature to dump
| scrollback to a file, and edit/search over that.
|
| I found it a bit too inconvenient when using remote systems
| frequently, though. (If I'm missing a trick, I'd love to
| use Ghostty! But I'm just not a fan of multiplexers.)
| tharos47 wrote:
| I use ctrl+R for search that way I'm not dependent of a
| terminal emulator features and can get to work even on
| random computers.
|
| https://www.gnu.org/software/bash/manual/bash.html#index-
| rev...
| doritosfan84 wrote:
| I think most people that want this feature want to be
| able to search through terminal output, not the commands
| they've previously used.
| chrysoprace wrote:
| I've always wanted to like Alacritty but they've had an open
| issue to support ligatures since 2017 and they're not in a rush
| to implement them.
|
| Now the only feature I need in Ghostty is Windows support.
| Imustaskforhelp wrote:
| > 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?)
| chrysoprace wrote:
| I'm always running tmux so it's not typically a feature I
| look for, but as you mention it doesn't seem to trigger a
| find for terminal scrollback. Wezterm doesn't do this
| either so maybe that's an iTerm thing. I always assume Ctrl
| keybindings will trigger emacs mode shortcuts in the tty.
|
| Update: Windows Terminal doesn't do it either.
| Imustaskforhelp wrote:
| I would love to use tmux. I have used yazi in the past
| and I really liked it but I was barely using it to its
| fullest potential.
|
| I think I have "skill issue" regarding tmux and I used to
| use hyprland (recently went to niri) and I just always
| preferred opening up another terminal I used to use
| (which was foot back when I was using my own config and
| it was alacritty on cachy/ idk what was on omarchy for
| the time I was on omarchy but I don't like omarchy)
|
| Is there actually a way to fix this skill issue, like I
| want something so simple in start that I just run it and
| forget and still get decent amount of benefits?
| chrysoprace wrote:
| tmux fits my personal use case better so I'll tell you
| why I use tmux and then if that resonates with you, then
| you might get value from that as well.
|
| - It's generally bundled on most distros, or available
| for install in most default repositories.
|
| - tmux sessions are available over ssh, so if I can
| continue where I left off over ssh (this is probably my
| main use case).
|
| - I can full screen my terminal instead of having
| multiple terminals, and split in tmux. I usually split
| vim buffers, but then keep a terminal split beside it or
| in another tmux window.
|
| - It's keyboard-driven, and universal across different
| window managers. Even if I switch from MacOS to Windows
| or to an X11 distro, tmux will still have the same
| keybinds using the same configuration language. I can
| also use vim keys to navigate the scrollback history.
|
| - Its config language is simple enough for the
| modifications I personally need. I haven't felt that I
| need to learn the syntax beyond the basics.
|
| - Knowing tmux is also a helpful skill for managing
| servers, which I do from time to time (my raspberry pi is
| still running a tmux session from when I last rebooted
| it).
| colordrops wrote:
| * use a prepackaged tmux config that makes it look nice
| and smooths out rough edges
|
| * Spend some time learning keybindings and commands. Just
| an hour or two should be enough.
|
| * Learn about the top plugins and install them. There's a
| plugin that saves and restores your session, I forget the
| name, but it's great
|
| * If you use vim, set up both vim and tmux with the right
| plugins so that the same keybindings navigate across both
| vim and tmux splits seemlessly.
| seanw444 wrote:
| Same here. Any replacement I moved to needed to have content
| centering, where the margin around the cells is equal in both
| dimensions when the cells don't fit perfectly into the window.
| Kinda crazy that it's not a feature in a lot of terminals I
| checked over the years. I wouldn't even consider myself OCD,
| but it drove me nuts until I found a terminal that let me do
| it.
| OberstKrueger wrote:
| The first time I went through the theme picker, I was tickled
| to see a theme I had made years ago included. Realized later it
| was due to it including all of the themes from iTerm2 Color
| Schemes automatically.
|
| It made for a more fun first experience with a terminal
| emulator than I expected to have.
| bsimpson wrote:
| The same part of me that is shy to install Chrome extensions is
| shy to try non-standard terminals. I'd like the thing I type my
| passwords into to be as trusted as possible.
|
| 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.)
| jeffbee wrote:
| So, don't type your password into your terminal emulator? In
| many situations (ssh and suchlike) you can use another means of
| unlocking your credentials.
| tristan957 wrote:
| If Konsole suits your needs, there is no reason to move to
| Ghostty. You may find better performance or access to more
| terminal features, but if those don't move the needle for you,
| then it doesn't matter. Konsole is well integrated in to KDE.
| zadjii wrote:
| No love for Windows Terminal? I know that linux has a much richer
| terminal ecosystem, but WT ranks a lot higher than a wide breadth
| of terminal emulators on linux now. Could anyone have imagined
| that 10 years ago?
| gschizas wrote:
| In the test, Windows Terminal (weirdly written as
| "terminal.exe") comes up as #4 in the scoring table.
|
| 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 :)
| epolanski wrote:
| I absolutely love it, it's my personal favorite. Using ghostty
| on MacOS instead.
|
| But I'm no power user.
| bigstrat2003 wrote:
| 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.
| epolanski wrote:
| I don't know, reading around feels like power users are
| mostly defined but the tons of features they use and miss
| when switching emulators.
| jscyc wrote:
| It's what I most miss from using windows. It handles tabs,
| theming and renaming of windows so well. Being able to tell at
| a glance what each window is connected to, it's purpose etc is
| very handy for me.
| jeffbee wrote:
| It's interesting that these are rankings, but in some cases the
| individual points are make or break for a given use case. For
| example, none of the emulators ranked higher than iTerm2 support
| Tek 4010 mode, which iTerm2 does support. So that's the one I
| keep using.
| alwillis wrote:
| It would amazing if iTerm used the Ghostty library (libghostty)
| for the core terminal functionality; then the developer could
| focus on UI/UX. iTerm has tons of useful features, but a lot of
| them are buried in the UI.
| electroglyph wrote:
| no xterm.js? it's a very good cross-platform terminal emulator
| altairprime wrote:
| That seems fixable with a pull request to ucs-detect, if one
| hasn't already been made.
| electroglyph wrote:
| good call, you're right
| christophilus wrote:
| Foot is excellent. Wayland only, but it is very fast to launch,
| and uses few resources. I love it.
| ac29 wrote:
| Yep this is my current favorite too. I liked ghostty when I
| evaluated it, but for some reason it uses an order of magnitude
| more memory than foot to display a single, empty terminal.
| tristan957 wrote:
| Ghostty uses GTK + GPU rendering while Foot uses Wayland
| primitives and CPU rendering.
| colordrops wrote:
| I've seen zero performance issues with foot.
| colordrops wrote:
| Foot is the best. Love ctrl-shift-o to open up links
| RVuRnvbM2e wrote:
| I'm quite confused why this article tests foot v1.16.2, which
| is two years old at this point. The latest version is 1.25.0.
|
| By contrast, the tested version of ghostty v1.2.3 is two weeks
| old.
| aorth wrote:
| Good point. I just submitted a pull request with new data for
| foot 1.25.0 https://github.com/jquast/ucs-detect/pull/17. The
| test suite is really easy to run (and fast, foot rocks!).
| bdunks wrote:
| I agree. I started using Foot based on a recommendation from
| the notcurses library author, who has deep expertise in
| terminal emulation and collaborates with maintainers.
|
| 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.
| enriquto wrote:
| The table seems wrong. Xterm supports sixels.
| altairprime wrote:
| You can fix that with a pull request to ucs-detect; for
| example: https://news.ycombinator.com/item?id=45801452
| the_gipsy wrote:
| Only if run with `-ti 340` argument. So in general, it's not
| there.
| omoikane wrote:
| Same for mintty.
|
| 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").
| cb321 wrote:
| `st` used to have a patch set for sixel graphics on its web site.
| I use an old version all the time to do gnuplots in terminals
| with nice scrollback. It seems to have been retired in favor of
| the kitty graphics protocol.
| topaz0 wrote:
| I can't remember the last time I used a non-ascii character in
| the terminal. I know that's not the case for everyone, and they
| deserve good terminals too, but it does mean that the criteria
| measured here have no relevance to my choice of a good terminal
| for me.
| ubercow13 wrote:
| Seems quite hard to avoid
|
| - 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
| hnlmorg wrote:
| > 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.
| epolanski wrote:
| Emojis are useful as visual indicators, there's anything
| from flags to check marks in them.
|
| They can be super helpful to decorate CLI output.
|
| If it feels juvenile but is helpful (as in many cases is)
| good.
|
| Sure, some CLIs may over do with rockets and such, but any
| tools can misused.
| pseudalopex wrote:
| I want country codes not flags. And check marks do not
| require emoji.
|
| Every emoji I saw in a terminal or Git commit message was
| worse than alternatives. This included emoji intended for
| information not fun. Color made them distracting when the
| wanted information was anything else. A monochrome font
| could not solve this because most emoji are too complex
| to display clearly at normal text sizes without color.
| They were cumbersome to grep. (Uncommon Unicode
| characters would have this problem also.) Many had
| unclear meanings.
|
| Use emoji in your CLIs if you desire. But make them
| optional. Opt in ideally.
| hnlmorg wrote:
| Unicode can be useful. The emoji subset generally are
| not.
| bigstrat2003 wrote:
| IMO emojis have no business in any form of text. It just
| doesn't belong.
| topaz0 wrote:
| 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.
| bigstrat2003 wrote:
| Literally none of those is a situation I've ever encountered.
| I don't think it's as hard to avoid as you think.
| mcswell wrote:
| All depends on what you're doing. When I worked in
| computational linguistics of languages that don't use ASCII
| (or European "accented" characters), I was very concerned
| with the display of non-ASCII Unicode scripts: Arabic,
| Devanagari, Thaana, Tamil, Chinese, even at one point
| Cambodian (which was extremely hard to render, even in
| XeLaTeX--it's improved since then). But at the moment,
| accented European characters are all I need.
| anthk wrote:
| Accented letters are easy under GNU/Linux or OBSD under X.
| Just launch: setxkbmap -us option
| ctrl:swapcaps -option compose:rwin
|
| The first switch switches ctrl with caps lock (it helps your
| hands) and the last one maps the right Windows key (you can
| use menu key from laptop too with compose:menu) so you just
| type [ ' ] [ a ] and you'll get an a char.
| imiric wrote:
| > And then my next windmill that I'm looking at is variable-sized
| text in the terminal. So when I'm catting a markdown file, I want
| to see the headings big.
|
| 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.
| joouha wrote:
| I'd find it very useful to be able to query a terminal to see if
| it has font support for a given list of characters.
|
| 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.
| loph wrote:
| The list does not include DECterm.
|
| 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.)
| dgl wrote:
| xterm does and some others, I posted about this and emojis a
| while ago: https://dgl.cx/2025/06/can-your-terminal-do-emojis
| altairprime wrote:
| (161 comments) https://news.ycombinator.com/item?id=44362272
| unleaded wrote:
| strangely enough Windows Terminal supports DECDHL but barely
| any on Linux do!
| tmtvl wrote:
| Some vaguely related things:
|
| - 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>.
| unleaded wrote:
| It's interesting that none of the programs commonly known as
| "terminal emulators" actually emulate a terminal.. we can do that
| now though. https://zork.net/~st/jottings/Real-VT102-emulation-
| with-MAME...
|
| 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
|
| You can do the same thing with a vt220.
|
| 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.
| dgl wrote:
| If MAME could support the VT525 (nearly the last terminal DEC
| made and unlike the previous DEC models it supports ANSI color)
| people might use it a bit more. It would be very useful for
| compatibility testing as there aren't many people with a real
| VT525! Last I looked someone had dumped the ROMs but there
| wasn't any support code.
| p_l wrote:
| 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
| LukeShu wrote:
| > You can do the same thing with a vt220.
|
| 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).
| unleaded wrote:
| I checked and it was actually the vt240. That one works.
| kevin_thibedeau wrote:
| This also looks closer to the original with some shaders to add
| pincushion distortion and Gaussian scanlines.
| anthk wrote:
| Forget MAME; I'd love a forked project for this minus the
| shaders for old machines. Where you just get the terminal
| emulation with a good TTF font and that's it. There are similar
| projects for the Altair 8800 where they scrapped their code
| from SIMH (now I prefer simh-classic) to just emulate a CP/M
| 2.2 Altair machine and that's it, because these people don't
| need to emulate PDP10's with ITS, old BSD's, current VAX NetBSD
| releases or the rest of the DEC machines...
| blueflow wrote:
| They do emulate a terminal, not just the kind of emulation you
| have in mind. "Wine is not an emulator" again.
| sho_hn wrote:
| Pretty nice to see KDE's Konsole rank really high, especially if
| you take performance/test elapsed time into account. Considering
| it's a decades-older workhorse compared to the new star ghostty,
| not too shabby that it's kept up.
| yokljo wrote:
| Agreed. It's nice to be able to just use the provided terminal
| when running KDE. It's very customisable and runs plenty fast.
| I also love being able to right click on Dolphin and tell it to
| open Konsole in the current folder. Also, I leave infinite
| scroll back turned on in Konsole and it works really well,
| swapping out to a file as it gets too much scroll back. Nothing
| worse than getting errors that I can't read because the
| terminal discarded them. I have Ctrl+Shift+X bound to clear
| everything, which I use before running just about any
| operation.
| jcgl wrote:
| > 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.
| whateveracct wrote:
| Konsole Just Works
| TiredOfLife wrote:
| Unfortunately Konsole has this feature that each time you
| switch tabs the maximized window shrinks by a couple of pixels
| (at least on Steam Deck)
| j1elo wrote:
| Work had me using the Windows Terminal for the first time ever
| after a life of developing on Linux. I got immediately hooked on
| the smart Ctrl+C and Ctrl+V (without needing to use Shift like on
| Linux!)
|
| 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!
| stefanha wrote:
| In Linux (Wayland) you can copy text from the terminal without
| pressing Ctrl+C at all. Just select the text. To paste it in
| another Window, press the middle mouse button.
|
| 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.
| j1elo wrote:
| 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)
| DaSHacka wrote:
| Isn't this an X11-ism? I dont believe this is Wayland-
| specific
| lelandbatey wrote:
| This is also a thing in X, not only Wayland.
| pmontra wrote:
| 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.
| tmtvl wrote:
| There's always Ctrl+Insert for copy and Shift+Insert for
| paste. I know that there's some laptops lacking an insert
| key, which is terrible, but for keyboard with an insert key
| the Ctrl/Shift + Insert combos are useful at times.
| pmontra wrote:
| Especially because one does not have to push three keys
| with the same hand, which is not nice to tendons. I think
| I did that for a while time ago, then forgot about it.
| Thanks.
| tmtvl wrote:
| I always use the opposite modifier key(s) (e.g. right
| control + a), which I was told to do when I learned to
| type Dvorak; but you're welcome.
| bluebarbet wrote:
| >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.
| dzaima wrote:
| But that doesn't go into clipboard history. And severely
| restricts what you can do between copying and pasting in
| general (very importantly makes it a pain to do replace (i.e.
| select+(implicit-delete+)paste)) as any intermediate
| selection before pasting destroys your Primary Selection. And
| if you realize you did that, recopying takes manually
| reselecting the text, or the otherwise-never-used ctrl+insert
| to recopy, instead of just repeating the same old ctrl+c as
| you always do with the clipboard in any sane application.
|
| 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.
| bytehowl wrote:
| How do you paste the selected text if you want to replace a
| text selection in the other window?
| cosmic_cheese wrote:
| Mac terminals yield a similar benefit, with the systemwide
| copy/paste Cmd+C/V not overlapping with Ctrl+C/V.
|
| 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.
| jack_pp wrote:
| 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.
| computably wrote:
| It's easy and reasonably quick to set up key remapping (via
| Karabiner).
| taftster wrote:
| Yes, but specifically in the context of Terminals (as
| discussed in the original article), it's really
| convenient to be able send Ctrl-C (break) differently
| than Cmd-C (copy).
|
| So yes keyboard remapping is an option. But there's just
| differences you can't remap because of the extra meta
| keys on Mac (and I guess on Windows too, with the Copilot
| or Start keys in play).
| inejge wrote:
| > it's really convenient to be able send Ctrl-C (break)
| differently than Cmd-C (copy)
|
| Right, and even on Linux you can do it by using the four-
| fifths forgotten CUA shortcut Ctrl-Insert for copy (and
| Shift-Insert for paste.) Although I'll admit to using
| Ctrl-Shift-C/V most of the time.
| Ghoelian wrote:
| My keyboard doesn't even have an insert key.
| nsagent wrote:
| Maybe you mean it's too much effort, because I'm sure you
| could. I was taught touch typing on a QWERTY keyboard in
| the summer between 6th and 7th grade. Last year I switched
| to Colemak after nearly 30 years of QWERTY.
| jack_pp wrote:
| Oh I have no doubt that I _could_ but I don 't see why
| since linux already does what I need and I don't see any
| compelling reason to switch. I was just curious to see
| what all the hype was about with the new m1 CPUs and give
| it a shot.
| taftster wrote:
| 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.
| cosmic_cheese wrote:
| On all my machines I remap Caps Lock to Control, and since
| I still use Control from time to time under macOS, I have
| muscle memory for it, and so switching between
| Control/Command dominance is low friction.
|
| Control in its typical position however drives me crazy.
| kace91 wrote:
| What do you dislike about cmd placement?
|
| I feel the opposite, the near-thumb position for the most
| used modifier is a godsend vs pinky strain.
|
| Ctrl in caps lock is debatably better but that key is
| arguably better used for esc in vim setups (or the harder
| to setup "ctrl if held, esc if tapped").
| phantasmish wrote:
| cmd is brilliant. I have to shift my entire hand downward
| a little to hit ctr+c/ctrl-v, and make a pinkie-stretch
| that I can feel straining my hand. Cmd+c/v keeps three
| fingers on the home row, and involves just a slide-over
| of the thumb by maybe a centimeter. It's great.
|
| caps-as-an-extra-ctrl helps with all of that, but leaves
| you with the problem of overlapping shortcuts in the
| terminal. Cmd also fixes that.
|
| I hate how hard it is to get anything remotely like it
| working in Linux. All the solutions are partial and very
| janky.
| cosmic_cheese wrote:
| It's a sentiment I've expressed many times here on HN,
| but I'd love to see a DE and matching set of apps
| designed to embrace Mac-like UX, including meta-based key
| shortcuts. It being like that out of the box instead of
| requiring a patchwork of spotty config changes and hacks
| brings massive value.
| kps wrote:
| There are *nix terminals that will let you bind shortcuts
| that don't conflict with terminal control keys. Konsole and
| KDE stuff in general will let you set Mac-style bindings
| (with some config effort), though I personally use mlterm.
| jwnin wrote:
| windows terminal is awesome and i wish it shipped with windows
| by default instead of having to go to the store and install it.
| everyone who uses it has only good things to say, and it is
| updated regularly by Microsoft.
| Iwan-Zotow wrote:
| It is default in w11 25h2
| DHowett wrote:
| 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.
| ajross wrote:
| > I got immediately hooked on the smart Ctrl+C and Ctrl+V
| (without needing to use Shift like on Linux!)
|
| You, uh, never tried middle clicking?
| nitinreddy88 wrote:
| So now we are moving away from Keyboard only Vim/Terminal
| thing to mouse for pasting?
| ajross wrote:
| You can cut/paste within your editor just fine. The subject
| at hand is window-system level clipboard/selection
| interaction, and in particular the presence of standard key
| bindings for them in various environments. While some
| terminal and editor apps do have keyboard bindings that
| interact with the OS clipboard, none are standard.
|
| Basically, yeah: you had to use the mouse to select it in
| the first place. Using the mouse to paste it is easier, not
| harder.
| pmontra wrote:
| Yeah, that slows down typing a lot. Luckily people on a
| laptop can use the touchpad which lies just below the space
| bar. I have a laptop with physical keys around the touchpad
| so I even have a button to paste. No need to tap, double
| tap, etc. I think that I never used a mouse in the last 20
| years.
| officeplant wrote:
| I can hit the middle click for my Trackpoint without
| leaving the keyboard :3
| ghosty141 wrote:
| 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.
| ajross wrote:
| It depends on the semantics of "everyone" and "knows". The
| X11 selection bindings predate CUA clipboard usage by a few
| years, actually. But in any case, the contention was that
| they were _simpler_ , not that they are standard. And they
| aren't.
| h3x4d3c4 wrote:
| Not sure if this was available from the beginning, but Ghostty
| has the ability to do exactly that with what they call
| "performable" keybindings
|
| <https://ghostty.org/docs/config/keybind#performable:>
| mongol wrote:
| Hope Kovid Goyal gets inspired by this
| h3x4d3c4 wrote:
| Kitty also has it, I didn't know prior to today
|
| https://sw.kovidgoyal.net/kitty/conf/#clipboard
| mongol wrote:
| fantastic!
| ghosty141 wrote:
| Oh wow, I'm already using ghostty and didn't know about this.
| It works great, thanks!
| ur-whale wrote:
| Ooh, seconded, will try right away.
|
| [EDIT]: so ... tried it ... very, very nice BUT:
|
| what of CTRL-V ???
| ghosty141 wrote:
| You can do the same with ctrl+v, just use
| paste_from_clipboard
| ur-whale wrote:
| > You can do the same with ctrl+v, just use
| paste_from_clipboard
|
| Yeah, but CTRL+V is actually used e.g. in VIM.
|
| And I can't see a way for ghostty to "guess" what to do
| based on context like it does in the case something is
| selected.
|
| Sorry, should have explained better.
| mongol wrote:
| This is genious. It is one of the most annoying things
| remaining in the Linux desktop and I often press Shift-Ctrl-C
| in the browser by mistake, opening up the dev tools in the
| process, while intending to copy.
|
| Are there any legitimate reasons to send Ctrl-C except to
| abort, that this could interfer with?
| thayne wrote:
| FWIW, in zsh, and probably other terminals, you can bind ctrl+v
| to be paste. Many terminal emulators also allow you to bind
| ctrl+v to paste, although that may interfere with applications
| that use ctrl-v for something else.
|
| 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.
| Yizahi wrote:
| I really wish PC manufacturers didn't kill Insert button. It
| worked just fine for decades with Ctrl-Ins/Shift-Ins, and in
| every terminal I've tried. But now the button is missing more
| and more often (thanks HP, I appreciate useless call and share
| buttons in its place, which don't work anywhere), and fixes
| need to be invented for a solved problem.
| indigodaddy wrote:
| Yeah shift-ins really is the way
| teo_zero wrote:
| It doesn't look so convenient to me. If Ctrl+v is bound to
| paste, how do you insert a verbatim character in the shell? How
| do you start a block visual selection in Vim? How do you scroll
| down in emacs?
| blueflow wrote:
| You don't but you don't notice if you never did anything like
| that. Half of the keybinds listed by 'stty -a' are a mystery
| to mankind.
| tom_ wrote:
| You can unbind the Ctrl+V keymapping if you want, and it
| behaves as expected in emacs -nw at least. (There's a
| Ctrl+Shift+V binding set up by default, same as many Unix
| terminal emulators, so you won't miss out.)
| throw0101c wrote:
| > _If Ctrl+v is bound to paste, how do you insert a verbatim
| character in the shell?_
|
| 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]_
|
| * https://en.wikipedia.org/wiki/Control-V
| j1elo wrote:
| Seems to me a reasonable concern but I'd bet it's only for a
| minority of users... so perfect candidate to have
| implemented, but given as a disabled by default setting.
| co_dh wrote:
| I have to warning everyone: Windows terminal with true color ,
| possibly with tmux, is very slow. There is a half second delay
| from key press to response. I am in a vdi. Your miles varies.
| ciberado wrote:
| This doesn't correspond to my experience. The terminal is not
| faster than light, but good enough for my requirements, and I
| use it both locally and through VNC. May it be a problem with
| your VDI setup?
| usrbinbash wrote:
| > So convenient!
|
| 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.
| rovingeye wrote:
| I have that turned on in Windows Terminal but still use
| ctrl+c because it's how all other software works
| ur-whale wrote:
| > immediately puts it into the tmux buffer
|
| Can you paste in a non-terminal app though (like a web
| browser) ?
| biehl wrote:
| That sounds like an awesome concept. However, I'm restarting
| Linux usage after 10 years on Mac, and I am surprised on how
| much less annoying the Shift-ctrl-v is compared to what I
| expected.
| ctippett wrote:
| I appreciate this analysis is on the state of _terminal
| emulators_ , but I'm curious how well the integrated terminals
| that come bundled in code editors/IDEs also perform. For example,
| where does Zed's integrated terminal fit in the rankings? VS Code
| (and its derivatives)? JetBrains, Sublime Text?
| kartoffelmos wrote:
| vscode terminal came in at number 32.
|
| https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
| ctippett wrote:
| I missed that one!
| uvaursi wrote:
| I still use PuTTY and a MAX232EACwhateverthefuck chip for
| embedded hardware stuff with a DB9 cable thats been plugged in
| and out more times than your mom on prom night.
|
| Should I switch to something else or just keep on truckin?
| shirro wrote:
| Terminal emulators are caught between emulating terminals and
| teletypes of the past and implementing new features and unicode
| is one of the struggles. The way most terminals and wcwidth
| handle the width of characters sometimes is not correct but
| preserving behavior is important for compatibility. It is
| possible that its just not worth trying to handle all unicode
| perfectly in a terminal. Its pretty good for legacy stuff and
| sysadmin. We have other ways of doing things remotely like html
| that might be more appropriate for ZWJ emoji and languages with
| complicated text shaping/rendering.
| kevin_thibedeau wrote:
| For glyph width, there are codepoints classified as ambiguous
| width. These are mostly narrow pre-emoji symbols that have been
| extended with an alternate emoji representation. There's no way
| to predict what their width will be, even with explicit
| variation selectors which might just be ignored.
| charcircuit wrote:
| The terminal emulator knows what font is being used so it
| should be possible to predict it.
| kevin_thibedeau wrote:
| The terminal application doesn't know the font. The best
| you can do is discover ambiguous widths by printing
| codepoints and checking the change in cursor position.
| That's a suboptimal experience.
| lifthrasiir wrote:
| > 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.
| kevin_thibedeau wrote:
| There are preexisting narrow symbols that were given a new
| emoji presentation in later standards rather than assigning
| a new codepoint. Text rendering engines vary on which form
| is the default. VTE had an option to set the preference.
| This can be very annoying when some arrows get the new
| emoji form but others in their cohort stay as narrow
| glyphs.
| anthk wrote:
| It does it fine with GNU Unifont and raw XTerm and others. I
| just had issues with RXVT and clones.
| musicale wrote:
| I'd like to see the key-to-pixel latency speed championship.
| eschatology wrote:
| While the article title is true (errant is a very specific and
| concise word), to me it did not convey clear enough that this is
| just ucs-detect / unicode support (compliance?) ranking. The
| article title "State of Terminal Emulators in 2025" implied a
| larger comparison of terminal emulators than just ucs-detect.
|
| 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?
| bardsore wrote:
| How fast my terminal can print 10000 lines is pretty far down
| the list of requirements I have, who cares as long as it is
| fast enough? To me it is as irrelevant as who has the best
| unicode support.
| ivanjermakov wrote:
| Unicode support in terminals is kind of a mess for TUI software
| developers. There is no good way to know how many columns a
| Unicode character will take, because terminals use different
| grapheme clustering algorithms.
|
| 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...
| Piraty wrote:
| a look at terminal emulators
|
| https://lwn.net/Articles/749992/
|
| https://lwn.net/Articles/751763/
| dmaa wrote:
| I used iterm2 for ages, but then somehow defaulted to
| terminal.app. It is fast and that is basically all i need from a
| terminal emulator, everything else is taken care of by tmux.
| krautburglar wrote:
| it is also a lot easier on the battery than iterm2
| p_l wrote:
| Interesting that xterm is written off as not supporting sixel,
| when in actuality it supports both full SIXEL and ReGIS _and_ Tek
| 4010, with 24bit colour IIRC.
|
| It's just not enabled by default.
| Joker_vD wrote:
| > Kitty and Ghostty are the only terminals that correctly support
| Variation Selector 15,
|
| 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.
| j4_james wrote:
| Agreed. The only thing that VS-15 is supposed to do is give the
| emoji a "text presentation", which the spec suggests as "black
| & white". And every example they show of a text presentation is
| exactly the same width as the emoji presentation.
|
| 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).
| UltraSane wrote:
| Why are we still emulating dumb terminals in 2025?
___________________________________________________________________
(page generated 2025-11-04 23:01 UTC)