terminals on The Neo-Babbage Files

Auto-sizing images in Kitty (if it fits it sits?)

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 08 Nov 2025 21:50:00 -0600

I’ve been playing with terminal emulators again for a while. More to write up at some point, but here a quick note on some customisations for displaying images in the terminal….

There are a couple of terminal emulators which allow for display of arbitrary images in the terminal (I mean, jpegs and pngs and the like, not (just) sixel), notably Kitty and WezTerm.

WezTerm with iTerm2 compatible image protocol support, and built-in imgcat command, alongside of (experimental but seemingly working) support for Kitty’s image display protocol (enable this in WezTerm by adding to your wezterm.lua config the line enable_kitty_graphics=true).

I mainly use Fish shell, and here I record a couple of notes on convenience customisations in Fish for working with in-terminal image display in Kitty and WezTerm. But, I have a POSIX-compatible (including Bash) version (less well tested) included below as well.

WezTerm’s command to display an image in the terminal is wezterm imgcat </path/to/image/file>, and Kitty’s is kitten icat </path/to/image/file>.

I’m playing with both terminals, and have a hard time remembering things, so one thing I’ve done is to alias these commands in fish to just icat.

More significantly, while WezTerm seems to have a smart auto-sizing of the image to downsize the rendering to make sure the image fits fully within the current terminal window, Kitty only seems to guarantee downsized display to make sure the image fits the current width of the terminal window, but does not downsize to fit the current height of the terminal window.

Thus, in Kitty, we get things like this:

(….hmm, boots aren’t a kitty…)

While in WezTerm, we get:

And with appropriate configuration from below added, the new (easy-to-remember) icat command works to produce in-terminal image display as in WezTerm:

(…and there’s the kitty in Kitty!)

Here are the relevant lines that can be added to your shell configuration file to both make the image display command in both Kitty and WezTerm both simply icat, and also resize the display of the image in Kitty to make sure it fits lengthwise in the current terminal window:

Fish shell

#################### BEGIN image display things ######################

# image display things for kitty [https://sw.kovidgoyal.net/kitty/]
#                        & wezterm [https://wezfurlong.org/wezterm/]
#
# - use 'icat $path/to/image' (in either) to display image in terminal
# - on inner workings of the image display protocols, see:
#   - for kitty:    https://sw.kovidgoyal.net/kitty/kittens/icat/
#   - for wezterm:  https://wezterm.org/cli/imgcat.html

# if we're in kitty:
if [ "$TERM" = "xterm-kitty" ]
  alias icat-full "kitten icat" # alias the default kitty icat behaviour to `icat-full'

  # function icat-auto
  function icat  # define auto-resizing version of kitty's `icat'
    # calculate kitty window size parameters:
    set -l kittysize (kitten icat --print-window-size) # get kitty window size
    set -l kittywidth (echo $kittysize | cut -dx -f1) # extract width of kitty window
    set -l kittyheight (echo $kittysize | cut -dx -f2) # extract height of kitty window
    set -l argcount (count $argv)    # count how argumnets to icat there are

    # calculate target image size parameters: [requires ImageMagick!]
    set -l imagesize (identify -format '%wx%h' "$argv[$argcount]")  # `identify' is part of ImageMagick
    set -l imagewidth (echo $imagesize | cut -dx -f1) # extract width of image
    set -l imageheight (echo $imagesize | cut -dx -f2) # extract height of image
    set -l reducebyy 1.0  # initialise and set to '100%' [no change] y-axis reduction percentage
    set -l reducebyx 1.0  # initialise and set to '100%' [no change] x-axis reduction percentage

    # test if target image is bigger than kitty window
    if [ $imageheight -gt $kittyheight ] # if it's taller than the terminal window
                                         # divide terminal window height by image height
      set reducebyy (math $kittyheight / $imageheight)
    end
    if [ $imagewidth -gt $kittywidth ]  # if it's widre than the terminal window
                                         # divide terminal window width by image width
      set reducebyx (math $kittywidth / $imagewidth)
    end
    if [ $reducebyy -lt $reducebyx ]  # set both reducebyx, reducebyy to smallest of 2 values
      set reducebyx $reducebyy
    else
      set reducebyy $reducebyx
    end
    # calculate target image height and width to fit fully in terminal window
    set imageheight (math floor (math $reducebyy x $imageheight))
    set imagewidth (math floor (math $reducebyx x $imagewidth))

    # call the `kitten icat' kitty command using the calculated image size
    if [ "$argcount" -gt 1 ] # if the user has passed more args than just the target image filepath
                             # then pass all of those separately along with `--use-window-size' parameter
      command kitten icat --use-window-size $COLUMNS,$LINES,"$imagewidth","$imageheight" $argv[1..(math (count $argv) - 1)] $argv[(count $argv)]
    else
      command kitten icat --use-window-size $COLUMNS,$LINES,"$imagewidth","$imageheight" $argv[1]
    end
  end

  # if we're in WezTerm, alias `icat' to wezterm's imgcat
  else if [ "$TERM_PROGRAM" = "WezTerm" ]
    alias icat "wezterm imgcat"
    # NOTE: currently not sure best way of emulating kitty's default image display behaviour
    #      - mainly because I don't know how to get the WezTerm window size in a
    #        fashion that's window-manager neutral and neutral between
    #        graphical display protocol (i.e., X11 vs Wayland)

    # draft version of default kitty icat-like behaviour for `imgcat'
    # function icat-full
    #   set -l imagesize (identify -format '%w' "$argv[$argcount]")
    # end
  # alias icat-full "wezterm imgcat --width 100%"
end

#################### END image display things ######################

POSIX shell (including Bash)

#################### BEGIN image display things ######################

# image display things for kitty [https://sw.kovidgoyal.net/kitty/]
#                        & wezterm [https://wezfurlong.org/wezterm/]
#
# - use 'icat $path/to/image' (in either) to display image in terminal
# - on inner workings of the image display protocols, see:
#   - for kitty:    https://sw.kovidgoyal.net/kitty/kittens/icat/
#   - for wezterm:  https://wezterm.org/cli/imgcat.html

# if we're in kitty:
if [ "$TERM" = "xterm-kitty" ]
then
    alias icat_full="kitten icat" # alias the default kitty icat behaviour to `icat-full'

    icat () { # define auto-resizing version of kitty's `icat'
        # calculate kitty window size parameters:
        kittysize="$(kitten icat --print-window-size)" # get kitty window size
        kittywidth="$(echo $kittysize | cut -dx -f1)" # extract width of kitty window
        kittyheight="$(echo $kittysize | cut -dx -f2)" # extract height of kitty window

        # calculate target image size parameters: [requires ImageMagick!]
        icat_last_arg_pos="\${$#}"
        icat_last_arg_content="$(eval echo \"$icat_last_arg_pos\")"
        identify_command="identify -format '%wx%h' \"$icat_last_arg_content\"" # `identify' is part of ImageMagick
        imagesize="$(eval $identify_command)"
        imagewidth="$(echo $imagesize | cut -dx -f1)" # extract width of image
        imageheight="$(echo $imagesize | cut -dx -f2)" # extract height of image
        reducebyy=100  # initialise and set to '100%' [no change] y-axis reduction percentage
        reducebyx=100  # initialise and set to '100%' [no change] x-axis reduction percentage

        # test if target image is bigger than kitty window
        if [ "$imageheight" -gt "$kittyheight" ] # if it's taller than the terminal window
        then
            # divide terminal window height by image height
            reducebyy=$(( ( kittyheight * 100 ) / imageheight ))
        fi
        if [ "$imagewidth" -gt "$kittywidth" ]  # if it's wider than the terminal window
        then
            # divide terminal window width by image width
            reducebyx=$(( ( kittywidth * 100 ) / imagewidth ))
        fi
        if [ "$reducebyy" -lt "$reducebyx" ]  # set both reducebyx, reducebyy to smallest of 2 values
        then
            reducebyx="$reducebyy"
        else
            reducebyy="$reducebyx"
        fi
        # calculate target image height and width to fit fully in terminal window
        imageheight=$(( ( reducebyy * imageheight ) / 100 ))
        imagewidth=$(( ( reducebyx * imagewidth )  / 100 ))
        kitten icat --use-window-size $COLUMNS,$LINES,$imagewidth,$imageheight "$@"
    }
    # if we're in WezTerm, alias `icat' to wezterm's imgcat
elif [ "$TERM_PROGRAM" = "WezTerm" ]
then
    alias icat="wezterm imgcat"
fi

#################### END image display things ######################

Note about built-in capacity

I confirmed with the developer, Kovid Goyal, that currently Kitty does not have an “autofit” option (other than it’s default autofit to fit width), see GitHub issue #9201. But Kovid seems to have gone ahead and added a built-it --fit option for Kitty, so a built-in way of managing image display with respect to window size should be available natively in an upcoming Kitty release.

Linux Terminal Emulator Features and Hardware Compatibility

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Tue, 28 Jun 2022 16:57:00 -0500

In a continuing series of, er, terminal-related posts, a look at some features of a subset of terminal emulators on Linux.

I mainly use vterm inside of Emacs, usually via Equake, but sometimes I do want to spawn a terminal outside of Emacs, and so I’ve been curious about the properties of different terminals, including the ability to be used across a wide range of hardware.

A few weeks ago [as of 28 June 2022], I came across Zutty, which describes itself as:

Zutty is a terminal emulator for the X Window System, functionally similar to several other X terminal emulators such as xterm, rxvt and countless others. It is also similar to other, much more modern, GPU-accelerated terminal emulators such as Alacritty and Kitty. What really sets Zutty apart is its radically simple, yet extremely efficient rendering implementation, coupled with a sufficiently complete feature set to make it useful for a wide range of users. Zutty offers high throughput with low latency, and strives to conform to relevant (published or de-facto) standards.

Zutty is written in straightforward C++ and only relies on OpenGL ES 3.1 for rendering…

The Zutty page includes a link to a blog post “A totally biased comparison of Zutty (to some better-known X terminal emulators)", which includes some interesting discussion of features of different terminal emulators, including comparison of VT support levels, and discussion of why this could be important. A number of terminal emulators, perhaps leaning towards “minimalism”, only implement support up to VT220, or even lower, which creates inefficiencies in certain cases:

The difference between implementing a VT400 or VT500 terminal (provided the implementations are correct) is relatively inconsequential. The same cannot be said of the gap between these and VT220-level terminals. Programs running in a less capable virtual terminal must sometimes use longer series of basic escape sequences to achieve the results of a fewer number of more modern ones. For example, the DECLRMM control sequence (set left-right margin mode) is available from the VT420 and up, and will be used to restrict scrolling to the active part of two horizontally split tmux panes. On less capable terminals, tmux is forced to perform more work to achieve the same result. This is quite similar to how extended instructions on modern CPUs allow machine code to be more efficient than code compiled for an older machine. In other words, not implementing a modern VT variant goes directly counter to greater efficiency. And there is yet another downgrade from VT220 to those terminals that only claim to support VT100/VT102.

It is surprising how unambitious the newer terminals Alacritty and Kitty are in this regard. I would have hoped that new, supposedly state-of-the-art entrants would take the effort to add support for modern VT standards. Switching from xterm to Alacritty (or any other modern terminal) should not be a major downgrade.

Inspired by this, I copy/supplement the table on that page with some additional comparison information, and a few additional terminal emulators. As per the Zutty post, I use VTTEST (originally written in 1983-1985 by Per Lindberg at the Stockholm University Computing Center; in 1996 a new version written by Thomas E. Dickey, the maintainer of xterm). to check for reported VT support level. The below table includes also whether the terminal emulator is GPU-accelerated or not, and what the mininum OpenGL hardware support is, as well as what display server is targeted (X11 or Wayland or both).

(Nb.: see note on gnome-terminal and VT-capability.)

program	tested version	VT self-id	GPU-accel	minimum OpenGL	DS
zutty	0.6	VT520	yes	ES 3.1	X11
terminology	1.12.1	VT510	when possible	n/a	X11
wezterm	20220624	VT500	yes	3.3 (?)	both
xterm	344	VT420	no	n/a	X11
kitty	0.19.3	VT220	yes	3.3	both
foot	1.12.1	VT220	no	n/a	wayland
alacritty	0.4.3	VT102	yes	3.3	both
st	0.8.2	VT102	no	n/a	X11
urxt	v9.22	VT102	no	n/a	X11
(lib)vterm	0.1.4	VT100/VT102	n/a	n/a	n/a
gnome-terminal	3.48.3	VT510?(see note)	no?	n/a	both

Foot is another interesting new terminal emulator - targetting Wayland only, and not GPU-accelerated, but with some design choices that make it faster than GPU-accelerated terminal emulators in some cases, as described in the wiki “When is foot fast, and when is it not?". One of the things it does is “damage tracking”, i.e. only rendering cells that have been updated, whereas e.g. alacritty rerenders everything (though, as noted, “Alacritty renders empty cells really fast”). But foot only supports up to VT220 (though alacritty only up to VT102!).

The terminal emulator I end up using most is based on libvterm, this is the library underlying Emacs’ vterm, and claims to “implement[] a VT220 or xterm-like terminal emulator”, but VTTEST seems to report as VT102/VT100, at least inside of Emacs.

There’s no clear “best choice” here, even putting vterm aside (vterm isn’t particularly fast, at least inside of Emacs (though it’s faster than other Emacs terminal emulator choices like ansi-term), doesn’t have “very high” VT support; but it runs inside in Emacs, which offers me a lot of advantages). Though alacritty, st, and urxvt implement only up to VT102 level features.

Foot, Zutty, Kitty, and Alacritty are all fast, at least sometimes (the Zutty biased comparison post above offers some additional discussion on this, not including foot). They’re all limited in various ways (hardware or display server - though Zutty apparently has experimental support for software rendering), with only Zutty having “very high” VT support. (And Zutty has some bells-and-whistles limitations: no plans for transparency support, ligatures, bitmap images (e.g. SIXEL).)

Foot runs on pretty much any hardware and has some nice features, but is Wayland only (and limited in VT level support).

Kitty and Alacritty require OpenGL 3.3 (on Intel hardware, this means at least Intel HD Graphics 3000 (so 2011-era **20 ThinkPads or later)).

Zutty “runs on a wider range of graphics hardware by virtue of only requiring OpenGL ES as opposed to “desktop” OpenGL, and its resource demands are otherwise minimal”, but it requires ES 3.1, which isn’t supported by, for instance, Intel HD Graphics 3000.

Terminology, a terminal emulator which doesn’t seem to get talked about as much, actually turns out to be a good choice across different hardware. It can use GPU-acceleration, rendering using OpenGL or OpenGL-ES2, but this is not a hard requirement. It offers VT510 level support, and has lots of bells and whistles. I haven’t seen many speed test comparisons with it, but in use it feels fast. (No native Wayland support though, if that matters to you.)

Note on gnome-terminal:

gnome-terminal used to self-report “VT525” in VTTEST (back in 2022, with v3.30.2), but self-described as VT220-compatible. But now (2025, v.3.48.3) seems to self-report as “VT100”. [Actually, I’m wrong about this. Or, it’s complicated: it says “VT100” family on one screen, and “VT510” on another.]

The Zutty post we’ve been talking about identifies a whole host of bugs in gnome-terminal and comments:

[…there’s] a steaming pile of bugs in various problem areas, some of them pretty basic (such as TAB handling). Horizontal margins (VT420 and above) seem to be completely unsupported, as well as various other sequences from VT420, VT520 and ISO-6429 (ECMA-48) – not entirely sure if the latter is in scope. Overall, a puzzling outcome!

Digging a bit further, I discovered some ambiguity on whether gnome-terminal supports the claimed VT520 level at all: its manpage (not organic to the project, but contributed by Debian) has this to say about the support level of gnome-terminal: Run any application that is designed to run on VT102, VT220, and xterm terminals.

That is pretty sloppy as far as specifications go. Apparently, it might be the case that nothing above VT220 is intentionally supported by gnome-terminal at all, and that its primary device attributes response is a big fat lie.

Tom (of Zutty) refers to the xterm-faq’s page on gnome-terminal (and gnome-terminal’s underlying VTE terminal widget library) as well, which documents extensive issues with gnome-terminal (and VTE) from 1999 onwards, summarising:

Unless specifically mentioned, GNOME Terminal and VTE’s issues generally accumulate, with occasional veering off with skin-deep “rewrites”. Each sighting provides a new episode.

But now (06 Nov 2025: gnome-terminal v3.48.3) it seems to only self-report in VTTEST as “VT100 family” in [4.] Primary Device Attributes (DA):

Report is: <27> [ ? 6 1 ; 1 ; 2 1 ; 2 2 ; 2 8 c  VT100 family
    1 = 132 columns
    21 = horizontal scrolling
    22 = color
    28 = rectangular editing

But as “VT510” in [5.] Secondary Device Attributes (DA):

Testing Secondary Device Attributes (Firmware version)

          <27> [ > 6 1 ; 7 8 0 2 ; 1 c
         Pp=61 (VT510)
         Pv=7802, firmware version 780.2
         Pc=1, ROM cartridge registration number ok

Update: 10 July 2022:

Added WezTerm (another one written in Rust) which I haven’t really had a chance to play with much, but it has good VT feature levels. It seems to have the same OpenGL requirements as Kitty or Alacritty. This seems a very good choice overall, with a lot of cool features, including implementing Kitty’s display of images in terminal protocol (along with iTerm2’s image display protocol), and scripting/extensibility in Lua.

Update: 06 Nov 2025:

Should really add Ghostty at some point (and update things in general), which I was trying out for a while, but recent versions of Ghostty require higher OpenGL-capable hardware than most of my machines have.

(Added above note on gnome-terminal as well.)

Update: 21 Dec 2025:

Updated corrections about gnome-terminal’s two differing reports (VT100-family in primary attributes, but VT510 in secondary attributes).

Noticed a “new” terminal emulator, ptyxis, when using a Fedora Atomic spin. And, indeed, it bills itself as a “terminal for a container-oriented desktop”. It seems to report like gnome-terminal, which makes sense as they’re both really using Gnome’s VTE (discussed above).

Towards a history of Quake-style drop-down terminals

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sun, 26 Jun 2022 20:19:00 -0600

Continued work on fooling Emacs into behaving like a drop-down console (i.e. Equake), set me to thinking about the development of Quake-style drop-down terminals.

The frequent label “Quake-style” does seem to suggest at least part of the origin in the computer game Quake (1996), or at least that the drop-down console in Quake was the most prominent/remembered example of this sort of UI.[0]

On Linux/Unix, a number of terminal emulators have been designed with Quake-style drop-down interaction, and other platforms now seem to have these as well. As far as I can tell, drop-down terminal emulators first appeared on Linux, and probably in the early 2000s. (Though I wonder about this, both the KDE project started in 1996 (same year as Quake) and the GNOME project shortly after and it almost feels like someone must have thought about doing something of this sort between 1996-2000.)

The earliest surviving drop-down terminals on Linux seem to be Yakuake (QT/KDE), Tilda (GTK), and Guake (GTK).

Yakuake seems to have been released in the early 2000s, certainly by 2005[1], but perhaps a bit earlier. Tilda was released by 2006[2]. Guake was explicitly inspired by the original author seeing Yakuake[3], itself being released in 2007.

But “Yakuake” stands for “yet another Kuake”, and indeed the earliest drop-down terminal I can find on Linux is Kuake, released probably by 2003, with the last update in 2004[4].

Happy to hear about further history of early drop-down Quake-style terminals on any platform.

[0] https://en.wikipedia.org/wiki/Console_(computer_games)

[1] https://web.archive.org/web/20051016011941/http://yakuake.uv.ro/

[2] https://web.archive.org/web/20061028182927/http://tilda.sourceforge.net/wiki/index.php/Main_Page

[3] https://news.ycombinator.com/item?id=22524552

[4] https://web.archive.org/web/20040219101722/http://www.nemohackers.org/kuake.php