|
|
Log in / Subscribe / Register

Kitty chases the mouse

July 9, 2026

This article was contributed by Lee Phillips

Kitty is a terminal emulator that runs on Linux, macOS, and the BSDs, which is notable for its speed and features such as image support and advanced font handling. It is under active development; a recent major release adds a new level of mouse support. Here, we will look at some of those features and show how the program can also be used as platform for text-based applications. Kitty is free software, released under the GPLv3.

Features

[Kitty logo]

Kitty is a GPU-based terminal emulator. As with several other currently popular terminal emulators, use of the GPU provides it with enough bandwidth to dump megabytes of text onto the screen in an instant. This is a welcome virtue when accidentally displaying a huge file using cat, but the GPU also enables smooth exploration of the scrollback buffer. Kitty is designed to have low latency, which refers to the time between striking a key and the appearance of the corresponding character on the screen. This is a property that users are often not consciously aware of, but that has an important effect on the satisfaction and well-being of the terminal jockey.

Kovid Goyal created kitty when he became dissatisfied with the speed of the terminal emulator he was using [YouTube interview video] and decided to make a faster one. He then began to add features, starting with colored underlines, that he wanted but existing programs didn't support.

Kitty is thoroughly customizable through a configuration file. The user can define keyboard shortcuts or mouse actions for dozens of commands. The options go far beyond the usual appearance and keyboard shortcut settings; for example, there are several parameters exposed for performance tuning. In recent kitty versions, changes to the settings go into effect immediately upon saving the configuration file.

Font handling in kitty is flexible—as long as "fonts" does not include bitmap fonts, which kitty does not and will not support because they do not scale arbitrarily. Kitty can use any monospace TrueType or OpenType font and change its size on the fly with a keyboard shortcut.

Ligatures are supported (but, thankfully, can be disabled), as are alternative glyph shapes in OpenType and variable fonts. Separate fonts for normal, italic, and boldfaced text can be defined. In the configuration file, the user can also tell kitty which font to use for which Unicode codepoints, or range of codepoints. This is useful if, for example, a favorite coding font doesn't have good Unicode coverage, or if different fonts do a better job at rendering certain glyphs. There are parameters available to adjust font metrics and things like the position and thickness of underlines and strikethroughs; even how kitty composites text onto the background color can be adjusted.

If the user permits, kitty can override the colors chosen by an application running in the terminal when they would lead to insufficient contrast between foreground and background. I have this turned on, as it protects me against, for example, carelessly defining too similar foreground and background colors for a Vim highlight. As the documentation points out: "Terminal aficionados spend all day staring at text, [so] getting text rendering just right is very important."

Kittens

Kitty comes bundled with a handful of auxiliary programs called "kittens" that provide extra functionality and customization to the program. They are invoked with keyboard shortcuts or by executing the kitten command with an argument to select the desired kitten in the shell. The kitten command with no argument will display the list of available kittens. For brief documentation of any of them, a -h flag is provided; for example, kitten ssh -h for a guide to using the ssh kitten.

Kitty is designed to be extendable by the user. To this end kittens are implemented as external Python programs using an API that allows them to control kitty and gives them access to the text in a kitty window and in its scrollback buffer.

There are many kittens available; here I will mention some of the especially useful ones that come bundled with kitty. The ssh kitten wraps the system's ssh command to ensure that the remote connection plays well with kitty, mainly by transmitting the needed terminfo setting and enabling shell integration (more on that below) on the remote machine; it also brings other conveniences, such as reusing existing connections. There is a kitten that lists and previews any usable font installed. A theme picker allows interactive selection of a preset color theme from among far too many contributed options. The icat kitten uses the "terminal graphics protocol" (described below) to display an image file in any common format (including animated GIFs) directly in the terminal. Image files can be local or fetched with HTTP(S) or FTP; it will even work directly over SSH, as long as the remote machine has kitty installed.

The show-key kitten displays keycodes corresponding to key presses, similar to the xev program. A clipboard kitten enables copy and paste of various data types (e.g. images) over SSH. There is also a unicode input kitten for interactive searching and selecting Unicode characters, as can be seen in the screen shot below.

[Unicode input kitten]

Kitty has a "hints mode" where any URL visible on the screen can be opened in the user's web browser by pressing a single key. It works like the popular Vimium browser extension, and uses a kitten under the hood. Remote control of kitty is provided by a kitten with many options allowing the user to send text to specific windows, change their properties, open and close windows and tabs, and more.

The kitty program features what the documentation calls "shell integration". This works for most popular shells such as Zsh, fish, and Bash, and third-party integrations are available for more exotic ones such as Nushell and Xonsh. Shell integration is a set of functions and shortcuts that make working at the command line more convenient. There are commands for opening the default editor with the contents of the scrollback buffer, the output of the most recent command, or the current command. Shell integration also supplies tab completion of kitty commands and various utility functions that are inserted into the shell environment, such as clone-in-kitty, which clones the current shell environment, including all environment variables, into a new window or tab. Another useful utility is edit-in-kitty, which enables editing remote files over SSH with the local editor.

New protocols

Kitty has created several new terminal protocols, implemented as sets of escape codes. Some of these protocols enable various kitty tricks, such as the terminal graphics protocol, which powers the icat command mentioned above. (Those familiar with the older sixel protocol may wonder why kitty didn't use that; the reason is that kitty's creator wanted to support a handful of features that are not supported by sixel graphics.) Additional kitty protocols improve on other legacy protocols, such as one that implements more flexible keyboard handling.

Other new protocols or protocol extensions implement colored and styled text underlines, copying of various types of data (images, text styles) to the clipboard, changing the shape of the mouse pointer, and mouse drag-and-drop of files to and from GUI file navigators. That feature is made possible by the enhanced mouse support that arrived with the latest major release.

Some of these protocols have been adopted by other projects, so, for example, users of Ghostty or Wezterm, along with several other terminal emulators, enjoy the benefit of kitty's terminal graphics protocol. It is also used by a long list of terminal-based applications, in addition to terminal emulators, and by plugins for editors. One such enhancement that I use with Neovim is the image component of the snacks plugin. It embeds graphics into Markdown buffers where it sees the Markdown syntax for inserting an image, or, optionally, displays them in popup windows. It also calls out to Typst and LaTeX (which, of course, need to be installed) to process math input and displays the result directly in the buffer. The plugin also understands Typst and LaTeX syntax for including images, and embeds those as well. Because Typst is so fast, the user gets realtime preview of the math when editing Typst documents.

[Kitty, Typst, and snacks]

Ι'll mention two final applications of kitty's terminal graphics protocol that I've found useful: both gnuplot and Julia can use it to embed their graphical output directly in their read-eval-print loops (REPLs), the former using a built-in "terminal", and the latter using the KittyTerminalImages Julia package. It can sometimes be useful to have, in the REPL, a record of plots alongside the commands that created them, an association that is lost when graphics are displayed in a separate window.

Interface builder

The kitty window can be split vertically or horizontally into any number of sub-windows, each with its own title, background color, and other properties. The resulting collection of component windows can be rearranged into a variety of layouts, and arbitrarily resized, similar to a tiling window manager such as dwm. The window arrangement can be saved as a "session" with a keyboard shortcut. The session information is saved in a text file that contains the layout details and also records what program each window was running at the time the session was created. These sessions can largely replace terminal multiplexers such as tmux.

In earlier kitty versions, arranging and resizing the windows in a session was done with the keyboard. While I generally prefer the keyboard to the mouse, this was not ideal. The new mouse handling in kitty v0.47.0 enables resizing and moving windows visually with a nicely thought-out interface that allows dragging window partitions and dragging and dropping windows to rearrange them. Session windows can even be dragged out of the session to become separate windows.

A session can loaded with the --session flag on the kitty command. The user can also load or switch sessions when using kitty with keyboard shortcuts. When a session is loaded, all of the programs that had been running in each window are started. Any shared SSH connections made with the ssh kitten mentioned above, which were active when the session was saved, will be reactivated.

An obvious use of kitty sessions is to define environments needed for various projects or tasks. A system administrator might want a session with several windows connected to different servers. A programming project could include a code editor, a REPL, and a window displaying documentation.

When sessions are combined with kitty's remote-control abilities they become the basis for simple text-user-interface (TUI) applications. To make such an application with kitty, it suffices to create the desired layout and save it as a session. The programs running in the component windows can handle user input and send and receive text and commands from each other in response. Considered this way, kitty becomes a kind of TUI construction kit.

[Kitty photo browser]

Above is a screenshot from a simple image browser that I built using this machinery. When the user selects an image file from a list, it displays the image and some information about it. The list is filtered and displayed by fzf in one window, the image is displayed in another window with kitty's icat kitten, and the image information is displayed in a third window by processing the output from the exif command.

Kitty is generally available from distribution repositories, but for those who desire a release more recent than that, the installation instructions describe methods for binary installation and for building from source. Kitty's GitHub page shows over 400 contributors, with Goyal making the vast majority of commits. It's written in Python, C, and Go, with a smattering of a few other languages.

Conclusion

I decided to try out kitty a few years ago because I was intrigued by some of its features, such as advanced image display. It has since become indispensable. Kitty strives to be more than a terminal emulator; it provides a rich environment for textual human-computer interaction. But its panoply of features stay out of the way of the user who simply wants a fast terminal with good font support. They can be explored gradually, and incorporated into workflows as desired. I'm still discovering kitty features that make my life in the terminal more convenient.

Kitty does have at least one problem, which sometimes creates confusion: its name, which is shared with a combination networking client and terminal emulator for Windows.

Finally, because undoubtedly some readers are wondering: yes, you can play Doom in kitty.


Index entries for this article
GuestArticlesPhillips, Lee


to post comments

Slow terminals

Posted Jul 9, 2026 16:04 UTC (Thu) by SLi (subscriber, #53131) [Link] (23 responses)

There's a lot in Kitty that I like. Terminals should not be stuck in the 90s. I'm all for smart mixed content features, more flexibility, better support for OSC codes, search, session management, whatnot.

But can someone help me understand this "fast terminal" trend? I like to think that I'm fairly latency conscious in general, but I cannot think of a single time that I've thought that a terminal is noticeably slow or that I'd hope it were faster. What do you need to do to experience that?

Now admittedly I have usually run my terminals on fairly fast computers and want to avoid things like transparency. But I can't imagine that being it?

I need to check what my current terminal is—I vaguely think maybe alacritty—but I used both Gnome Terminal and Konsole for years, and "this terminal is slow" is a thought that simply never entered my mind. (OTOH I tend to set my history to at least 100k lines.)

Slow terminals

Posted Jul 9, 2026 16:29 UTC (Thu) by jbills (subscriber, #161176) [Link] (1 responses)

If you've ever run something like
```
for i in range(0, 10000000):
print("Hello world")
```
you will note that it completes significantly slower than
```
with open("out.txt", "w") as f:
for i in range(0, 10000000):
print("Hello world", file=f)
```
This is down to the speed the terminal can accept output and write it to screen.

Slow terminals

Posted Jul 9, 2026 16:39 UTC (Thu) by dskoll (subscriber, #1630) [Link]

It's not only the terminal speed. Output to a file is typically buffered whereas output to a terminal isn't, so the second example makes many fewer write system calls. Try stracing the first example as is and then again with stdout directed to /dev/null. You'll see a huge difference.

Slow terminals

Posted Jul 9, 2026 17:04 UTC (Thu) by ejr (subscriber, #51652) [Link]

"Slow" also can mean eating cycles when it'd otherwise be asleep. That, too, is a trade-off between various overheads and the instantaneous speed/efficiency. It feels like most hardware has sufficiently optimized the transitions, and that much related software overhead has been removed... Maybe this only saves 30s of overall battery life, but I'll take it.

Slow terminals

Posted Jul 9, 2026 17:14 UTC (Thu) by farnz (subscriber, #17727) [Link]

As far as I can see, the "fast terminal" trend kicked off after Dan Luu's post on input lag 1977 to 2017 got traction (along with its linked posts). A bunch of people noted that input latency on modern systems shouldn't be as variable as Dan Luu measured, and that it's kinda sucky that input "felt" better on 1980s machines than on modern machines if you're latency sensitive, and set to work fixing that.

Slow terminals

Posted Jul 9, 2026 17:58 UTC (Thu) by grawity (subscriber, #80596) [Link] (5 responses)

Compare typing into Xterm and typing into GNOME Terminal. The latter has noticeably more input latency, especially on slightly older machines.

(Although still not nearly enough latency to make me switch away from GNOME Terminal – I can't get used to any of the alternatives, which inevitably bring weirdness into font rendering. Ghostty is closest, but it too renders my default font just slightly differently from GNOME's standard Pango. The point is merely that the difference can be felt without special measurement tools.)

On the other hand, GNOME Terminal may sometimes feel faster because it throttles frames: if a program outputs massive amounts of text, the terminal will accept all of it asynchronously while only redrawing at a certain rate, while e.g. Xterm (or the native Linux console for a particularly "slow" example) produces a frame for every single line of that output synchronously as it is received, causing the program's output to be capped at how fast the terminal can render.

One situation where I do use Xterm is X11-over-network, where ironically enough Xterm sometimes becomes the worst option; it takes several seconds to start (compared to URxvt opening instantly), and becomes completely unresponsive to input when processing large amounts of output as it pushes every update to the X server (even if the Cygwin X server and/or the ancient laptop's CPU cannot cope).

Those are at least 3 different factors in which a terminal can be "fast" or "slow". There might be others, like memory usage, or CPU usage (relative to other terminals for the same output), or the amount it takes to load in a new font (e.g. Xterm stutters when displaying Japanese text), or general UI responsiveness (as far as terminals have UI).

kitty over terminal Re: Slow terminals

Posted Jul 9, 2026 19:58 UTC (Thu) by atai (subscriber, #10977) [Link]

So how would kitty behave with the display over the network? Would it be slower as the (locally accelerated) GPU rendered frame buffer has to be sent over the network?

Slow terminals

Posted Jul 9, 2026 22:23 UTC (Thu) by SLi (subscriber, #53131) [Link] (1 responses)

> (Although still not nearly enough latency to make me switch away from GNOME Terminal – I can't get used to any of the alternatives, which inevitably bring weirdness into font rendering. Ghostty is closest, but it too renders my default font just slightly differently from GNOME's standard Pango. The point is merely that the difference can be felt without special measurement tools.)

Font rendering is a pain. I wish there were standards for what things like font sizes or line spacings mean.

Slow terminals

Posted Jul 15, 2026 12:14 UTC (Wed) by siddh (subscriber, #169663) [Link]

> Font rendering is a pain. I wish there were standards for what things like font sizes or line spacings mean.

Related protocol in kitty: https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#fix...

Slow terminals

Posted Jul 10, 2026 13:27 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

Interesting, because for me XTerm is always fast and light precisely thanks to jump scroll. You just need to have this in your .Xresources: XTerm*jumpScroll: true (or call it with xterm -j).

Slow terminals

Posted Aug 11, 2026 14:56 UTC (Tue) by zahlman (guest, #175387) [Link]

> Compare typing into Xterm and typing into GNOME Terminal. The latter has noticeably more input latency, especially on slightly older machines.

I don't remember why exactly I installed Xterm, but I fail to notice the difference, or any particular issue for that matter; my CPU and mobo date to 2014. And as far as I can tell, throughput is at least as good in GNOME Terminal as in Xterm, and both are actually *better* than Kitty.

Slow terminals

Posted Jul 9, 2026 19:56 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> But can someone help me understand this "fast terminal" trend? I like to think that I'm fairly latency conscious in general, but I cannot think of a single time that I've thought that a terminal is noticeably slow or that I'd hope it were faster. What do you need to do to experience that?

I was doing a `skopeo copy` of a 30G image with 60 layers over `ssh`. All of the progress bar updates were very flickery in `foot` locally. One of the times that incremental updates are probably worse than complete repaints.

Slow terminals

Posted Jul 9, 2026 22:20 UTC (Thu) by SLi (subscriber, #53131) [Link]

This may also be due to differences in what escape codes they support, in this case for example the CSI ? 2026 h/l for doing atomic updates, apparently supported by some terminals and apparently not others. So for many terminals you do have a way of saying "don't show what I'm going to send you now until I tell you to", which is nice.

Slow terminals

Posted Jul 9, 2026 20:31 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (2 responses)

Back when I was stuck on Windows I tried all the usual ssh programs out there, from putty & its various forks such as kitty (not to be confused with the kitty of this article! there was a Windows program called kitty that was a fork of putty), to wezterm, to Windows' own improved Console — the problem with most of them was that they either didn't play nicely with program-ssh-tmux-Emacs (e.g. wezterm couldn't pass Ctrl+SPACE through to Emacs properly, which is quite bad as that's frequently used).

I gave Windows' own Console a serious try at one point — but that one has so many redraw & scrolling issues that simply watching an active "cargo" or "make" run scroll by gave me the willies. It was so bad that in end I went back to putty, even though I hated several other of its features (mostly storing sessions in the registry, making the whole thing inherently unsharable with other machines).

Point of the story is, speed doesn't matter in absolutes, but even a limited lack of speed can completely ruin your terminal experience.

On Linux I've been using Linux-kitty (the one from this article) for… I don't know, a decade now, maybe? And while I value the unparalleled configurability the most I also quite enjoy that it lacks absolutely nothing wrt. speed.

Slow terminals

Posted Jul 14, 2026 20:37 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

this eventually got better, MS Terminal (not conhost.exe which has limitations due to compatibility constraints, the new standalone Terminal app) and OpenSSH on Windows are usable, in fact I'd say that MS Terminal is the best I've used and when I switched back to Linux desktop for work the available terminal options were less good (for me) which I found to be surprising and frustrating.

The best I've found has been kitty although I'm keeping an eye on Ghostty as well as the UI/theme are a bit closer to what I like. The killer feature for me are splits, kitty and Ghostty (and Konsole to some extent) support them but none of the other terminals seem to, everyone else is using tmux (or screen) to get this feature, or switching desktop environment to Sway and eschewing overlapping windows altogether,, but I don't care for the tradeoff of either changing my whole desktop or losing access to native terminal features like scrollback with actual draggable scrollbars, instead of funky keyboard commands. My experience with Konsole and Ghostty is that they both have rendering artifacts or UI issues that I'm not willing to deal with, Ghostty seems to reset and redraw the entire application window when resizing a split frame, which is slow and janky, and Konsole had strange defaults like toolbars, but I found the GUI configuration UI less comprehensible than the kitty text config. The biggest issue I have with kitty is setting TERM on remote hosts, the RHEL ones can take the kitty terminfo file but other platforms (not desktop/server Linux) get confused so I need to maintain entries in .ssh/config setting TERM=xterm-256color or something more commonly deployed.

Having a workspace inside of one window works well for me, I can have a full-width log scroll along with an editor side by side with running a command, maybe several panes for different hosts, all neatly packed together without losing a lot of screen space. Looking forward to updating kitty and trying the improvements.

Slow terminals & passing environment variables to other hosts

Posted Jul 15, 2026 18:11 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

Yeah, I was talking about the modern Terminal app, too, not conhost.exe. I'm not trying to diss it that much, it has great compatibility, I just happened to run into the one performance corner case (Terminal → OpenSSH → Linux → tmux with two split panes above one another → dumping a lot of text, e.g. watching fast-moving log files) where it really annoyed me.

Had all the same TERM problems with putty-256color back when I was using that or its forks on Windows, so I know that problem well. I usually defaulted to an omnipresent 16 color TERM & only set it for the select few hosts that I know had it. You could often have the same issues with locales like e.g. LC_COLLATE=de_DE.UTF-8, and that's still a thing on hosts with minimal locale installations.

Heck, I remember when xterm-256color wasn't a universal thing either.

Slow terminals

Posted Jul 10, 2026 0:21 UTC (Fri) by dsommers (subscriber, #55274) [Link] (1 responses)

When I upgraded to RHEL-10, the old gnome-terminal had been replaced with ptyxis, and my otherwise preferred terminal, tilix was not available nor easy to get built.

I understood I wanted something else than ptyxis, as it wasted do much screen space on fancy GUI elements outside the terminal itself.

I found and tried many different alternatives before landing on wezterm as the least worse alternative.

Today wezterm was acting up so I had to check some things in ptyxis again. That's when I really noticed the immediate response I get in wezterm. Ptyxis actually felt sluggish by comparison. And this was just the feeling when scrolling up/down with pgup/pgdown keys or scrolling with the mouse in the window. Also typing felt slightly more sluggish.

I've never noticed this so clearly before. But once you spend time i the new, modern terminals with GPU support, I'm pretty sure you might experience something similar after months of using it.

Slow terminals

Posted Jul 25, 2026 12:46 UTC (Sat) by daenzer (subscriber, #7050) [Link]

> Today wezterm was acting up so I had to check some things in ptyxis again. That's when I really noticed the immediate response I get in wezterm. Ptyxis actually felt sluggish by comparison. [...]
>
> I've never noticed this so clearly before. But once you spend time i the new, modern terminals with GPU support, [...]

Ptyxis also uses GPU acceleration (GTK4 uses Vulkan or OpenGL by default for all of its drawing), so that alone can't explain the difference. Sounds like wezterm is simply better optimized for latency than ptyxis.

Slow terminals

Posted Jul 10, 2026 5:38 UTC (Fri) by epa (subscriber, #39769) [Link] (2 responses)

xterm was pretty fast thirty years ago. At least if you had an accelerated video card rather than a pure software framebuffer. But newer terminal emulators have become slower. You’d think that faster hardware would more than compensate, but there is a noticeable difference between the fastest and slowest terminals still. I guess this is an example of the rule that you often can’t throw hardware at the problem.

Slow terminals

Posted Jul 11, 2026 9:12 UTC (Sat) by kucharsk (subscriber, #115077) [Link]

I still use xterm; there's nothing more I need from my terminal emulator.

Slow terminals

Posted Jul 12, 2026 17:03 UTC (Sun) by viiru (subscriber, #53129) [Link]

> xterm was pretty fast thirty years ago.

I find this funny. I distinctly remember switching from xterm to rxvt due to the much better performance of the latter. I'm fairly sure this was less than 30 years ago, but obviously the hardware at the time wasn't what we'd call fast these days.

I kept using rxvt for a couple of decades, but that was mostly inertia (there wasn't anything wrong with it so why switch).

Slow terminals

Posted Jul 10, 2026 5:53 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (2 responses)

Part of it is also likely just doing it because it can be done. Sometimes the world doesn't *need* something, but you do it anyway as a challenge or a form of art.

Slow terminals

Posted Jul 10, 2026 8:49 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (1 responses)

Part of it is that in a world of jinja, markdown, automation cloud and AI the terminal is cool and necessary again. Even Microsoft decided to invest in a terminal, which is little different from a ptyxis from a design and features point of view.

On a good well-tuned HiDPI screen with GPU acceleration the comfort of a terminal with good Opentype support will blow out of the water any legacy bitmap-oriented console. You need the acceleration to render outline fonts at a good speed, since it’s a lot more processing work than just outputting birmaps.

That also means there is little point in trying those terminals on LowDPI legacy-oriented screens or without spending some time selecting a nice monospace font. And choosing a pretty color theme. Because all of this is about visual comfort.

Slow terminals

Posted Jul 13, 2026 3:15 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Hmm…even with HiDPI, I still prefer Terminus to anything else I've found… But maybe that's just familiarity at this point.

The unicode kitten and remote control

Posted Jul 9, 2026 17:17 UTC (Thu) by rdxmassubscription (subscriber, #162869) [Link] (12 responses)

I'm a huge fan of the unicode kitten! It's super nice not having to tab over to a browser (nor memorize all the unicode symbol codes) when I want to type something like a degree, or some mathematical notation. I'm also a very heavy user of the remote control kitten. With a relatively small amount of python scripting, I found I was able to recreate a lot of my old AppleScript/iTerm workflows on Linux. Super excited to try out some of the new mouse features. Thank you for contributing this!

The unicode kitten and remote control

Posted Jul 9, 2026 17:34 UTC (Thu) by daroc (editor, #160859) [Link] (11 responses)

Personally, I've always preferred to use the Compose key for things like that. It's generally well-supported and cross-application. You can't search for codepoints, exactly, but most of the combinations are intuitive. Compose + ' + a = á, Compose + : + ) = ☺, etc. ° is Compose + o + o, which took some getting used to but now it's muscle memory.

The unicode kitten and remote control

Posted Jul 9, 2026 20:03 UTC (Thu) by rdxmassubscription (subscriber, #162869) [Link] (5 responses)

Oh, interesting. It looks like a lot of commonly used symbols are supported out of the box, too! It seems like in some instances, there may be additional setup for certain characters, such as the "dead_greek" letters (Δ [delta], Σ [sigma], Θ [theta], etc.)? In any case, I'll definitely be looking into this more. Thanks for the tip!

The unicode kitten and remote control

Posted Jul 9, 2026 20:09 UTC (Thu) by daroc (editor, #160859) [Link] (4 responses)

Yeah — if your keyboard has a 'dead key' that you can press to add a sticky modifier to the next keypress, you can use it out of the box, but a lot of physical keyboards don't do that anymore. You can either customize the bindings in your compose configuration file, or program your keyboard to interpret some key chord as a 'dead key'. Apple devices use Option + I for that, I think. I don't have to type in Greek often, so I only have a custom shortcut for λ, since it comes up so frequently.

https://en.wikipedia.org/wiki/Dead_key

The unicode kitten and remote control

Posted Jul 10, 2026 15:15 UTC (Fri) by ejr (subscriber, #51652) [Link] (3 responses)

Oooh, I may just re-bind insert to be compose. I hadn't thought of that until just now. Thank you!

The unicode kitten and remote control

Posted Jul 28, 2026 10:44 UTC (Tue) by rmano (guest, #49886) [Link] (2 responses)

Oh. Don't everybody remap the (useless) caps-lock to compose ;-)? (Or to control, and control to compose)?

The unicode kitten and remote control

Posted Jul 28, 2026 10:59 UTC (Tue) by TomH (subscriber, #56149) [Link] (1 responses)

No that's what Pause/Break is for, remapping to Compose.

The unicode kitten and remote control

Posted Jul 29, 2026 13:44 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Alas, that key is either non-existent or hidden behind some Fn-flavored chord on laptops. I use Shift+RightAlt myself for Compose. Caps Lock is Backspace here.

The unicode kitten and remote control

Posted Jul 10, 2026 8:54 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (3 responses)

It is very nice. Does wayland still refuse to support user defined combinations?

The unicode kitten and remote control

Posted Jul 10, 2026 11:58 UTC (Fri) by daroc (editor, #160859) [Link] (1 responses)

I believe it depends on your compositor. Since switching to wayland, I have used both sway and KDE, and both of them handle custom compose shortcuts.

The unicode kitten and remote control

Posted Jul 10, 2026 17:46 UTC (Fri) by dagobayard (subscriber, #174025) [Link]

Compose key *and* XCompose customization work for me in the default
Gnome session on Debian trixie, which is Wayland I'm pretty sure.

The unicode kitten and remote control

Posted Jul 13, 2026 19:59 UTC (Mon) by ralfj (subscriber, #172874) [Link]

What are you talking about? I have used user-defined combinations with Wayland for many years. It works everywhere except for VSCode (so I force that to use XWayland and then it works there as well).

The unicode kitten and remote control

Posted Jul 10, 2026 11:30 UTC (Fri) by paulj (subscriber, #341) [Link]

XCompose is very useful. You can easily add your own extensions via ~/.XCompose. E.g., added from when I had to type up some basic logic stuff - easier than remembering LaTeX for me, and means you can type them into MarkDown docs too:

$ cat ~/.XCompose
include "%L"

<Multi_key> <backslash> <slash> : "¯\\_(ツ)_/¯" # UTF-8 shrug

<Multi_key> <slash> <exclam> : U0338 # COMBINING LONG SOLIDUS OVERLAY
<Multi_key> <e> <x> : "∃" U2203

<Multi_key> <E> <l> : "∈" U2208 # Element of
<Multi_key> <E> <L> : "∈" U2208 # Element of
<Multi_key> <e> <L> : "∈" U2208 # Element of

<Multi_key> <e> <l> : "∊" U220A # small element of

<Multi_key> <L> <e> : "∋" U220B # contains as
<Multi_key> <L> <E> : "∋" U220B # contains as
<Multi_key> <l> <E> : "∋" U220B # contains as

<Multi_key> <l> <e> : "∍" U220D # small contains as

<Multi_key> <E> <plus> : "∑" U2211 # summation
<Multi_key> <s> <r> : "√" U221A # square root
<Multi_key> <s> <b> : "⊂" U2282 # subset of
<Multi_key> <s> <p> : "⊃" U2283 # superset of

And note that you are *not* limited to using it to produce just unicode characters - you can have it output ASCII too, and strings of characters!

There's even a "Wincompose" app to add X11 style Compose key functionality to windows.

Best article name ever

Posted Jul 9, 2026 20:08 UTC (Thu) by noiobeforebedtime (subscriber, #160749) [Link] (1 responses)

props to whoever came up with that

Best article name ever

Posted Jul 9, 2026 21:22 UTC (Thu) by jake (editor, #205) [Link]

> props to whoever came up with that

heh, Lee gets all the credit there ...

jake

Python as a deal breaker

Posted Jul 10, 2026 7:49 UTC (Fri) by taladar (subscriber, #68407) [Link] (5 responses)

Kitty does look interesting but I honestly just can't get myself to adopt another Python based tool, especially for something this crucial to keeping my system usable, considering how often those tend to break on me with both the tools I used to use and the ones I still haven't found good replacements for.

Python as a deal breaker

Posted Jul 10, 2026 11:16 UTC (Fri) by neggles (subscriber, #153254) [Link] (2 responses)

kitty itself is rust based, it's just the plugin api/sdk that's python

Python as a deal breaker

Posted Jul 13, 2026 10:44 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

Then why is the repository https://github.com/kovidgoyal/kitty 0% Rust, 38% Python 28% C and 26% Go?

Python as a deal breaker

Posted Jul 13, 2026 15:16 UTC (Mon) by leephillips (guest, #100450) [Link]

I guess neggles meant to say “go”.

I also hesitate to install programs written in or with a dependency on Python, but https://sw.kovidgoyal.net/kitty/build/ explains how the Kitty project sidesteps possible breakage due to Python evolution. Kitty doesn’t depend on your system Python and there is no breakage there.

Python as a deal breaker

Posted Jul 11, 2026 8:25 UTC (Sat) by rbtree (guest, #129790) [Link]

FWIW, I've been using kitty heavily for about five years, never had it break on me. Also was very skeptical about using a terminal emulator with lots of Python glue behind it (mostly for performance reasons), but they turned out to be unfounded.

I think Kovid has been moving away from Python for some time, I'm seeing many "kittens" being rewritten in Go. Those are modules external to the main application, so the internal parts probably won't be ported anytime soon, but again -- I do not remember those Python bits ever biting me, and for other bugs the maintainer is exceptionally responsive and often fixes them within a couple of hours of somebody reporting them.

Python as a deal breaker

Posted Aug 11, 2026 15:10 UTC (Tue) by zahlman (guest, #175387) [Link]

CPython supports its Python releases for 5 years (5 simultaneous minor versions on an annual cadence), actively maintained projects generally try to move in lock-step with that, point-release distros make sensible choices for the system Python version, and all the major package tooling knows how to account for the Python version in the environment. So it's really unclear to me how people end up reporting this sort of breakage all the time. If you have concrete examples, I'd be happy to help diagnose what's going wrong for you, and/or reassure you that it wouldn't affect this project.

Reinventing Emacs

Posted Jul 10, 2026 17:51 UTC (Fri) by dagobayard (subscriber, #174025) [Link]

> Considered this way, kitty becomes a kind of TUI construction kit.

Nobody who has seen the True Light, as mediated by the One True Church
of Emacs, would have come up with this ;-)

Terminal graphics

Posted Jul 11, 2026 4:12 UTC (Sat) by rfunk (subscriber, #4054) [Link]

It was only in the past year that I learned about terminal programs supporting high quality graphics. But part of what I learned is that there are many different protocols for it: sixel, kitty, and iterm2. As a KDE user I was happy to learn that konsole supports all three of those, and I use timg with it (which ends up choosing the iterm2 protocol). And it works across ssh!

Anyway, as a heavy terminal user who also works quite a bit with images, I feel like this is an unsung feature of many modern terminals and should be much better known!

Killer features

Posted Jul 11, 2026 14:07 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

The one killer feature I use: press PrintScreen, have the whole scrollback buffer in "less" for easy perusal.

TODO, add this feature to tmux …

Killer features

Posted Jul 11, 2026 16:45 UTC (Sat) by malmedal (subscriber, #56172) [Link]

tmux capture-pane can do this. I also do this with xterm, it's a bit more involved set up print command to print to file and then trigger the print escape code.

Expand/collapse/disclosure widgets in terminals

Posted Jul 12, 2026 15:32 UTC (Sun) by dave_malcolm (subscriber, #15013) [Link] (1 responses)

Do any of these new terminal protocols support hierarchical expand/collapse, allowing a program to emit a tree hierarchy of text that the user can click on to expand/collapse subtrees?

GCC's C++ template errors recently gained such structure (added in GCC 15 and made default in GCC 16), albeit as bullet points with nested indentation, so it might be neat to be able to support expand/collapse in a suitably smart terminal.

Expand/collapse/disclosure widgets in terminals

Posted Jul 30, 2026 21:00 UTC (Thu) by Per_Bothner (subscriber, #7375) [Link]

Do any of these new terminal protocols support hierarchical expand/collapse, allowing a program to emit a tree hierarchy of text that the user can click on to expand/collapse subtrees?

Check out DomTerm. Here is an (old) demo. This is a "saved console log" with some JavaScript to make dynamic resizing and expand/collapse work the same way in the log as in an actual terminal. Try resizing the window and/or clicking the (red and black) triangles to see it in action. Note how line-break and indentation adjusts to the line width. (This uses the Common Lisp pretty-printing model built into the terminal.)

Documentation: Escape sequences (look for "show" and "hide"). Internal/DOM representation.

Nice, but functionality is not very discoverable

Posted Jul 23, 2026 14:29 UTC (Thu) by callegar (guest, #16148) [Link]

Nice, but lack of a menubar makes the functionality quite undiscoverable and thus anything else that is "good enough" and either already known or discoverable substantially better.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds