Watch 1

Star 0

HTTPS

Download ZIP Download TAR.GZ Download BUNDLE Open with VS Code Open with VSCodium Open with Intellij IDEA

Logo: a terminal with a foot shaped prompt foot

The fast, lightweight and minimalistic Wayland terminal emulator.

CI status Pipeline status builds.sr.ht status

Packaging status

Index

1. Features
2. Installing
3. Configuration
4. Troubleshooting
5. Why the name 'foot'?
6. Fonts
7. Shortcuts
   1. Keyboard
      1. Normal mode
      2. Scrollback search
   2. Mouse
   3. Touchscreen
8. Server (daemon) mode
9. URLs
10. Shell integration
    1. Current working directory
    2. Jumping between prompts
11. Alt/meta
12. Backspace
13. Keypad
14. DPI and font size
15. Supported OSCs
16. Programmatically checking if running in foot
17. XTGETTCAP
18. Credits
19. Bugs
20. Contact
    1. IRC
    2. Mastodon
21. Sponsoring/donations
22. License

Features

• Fast (see benchmarks, and performance)

• Lightweight, in dependencies, on-disk and in-memory

• Wayland native

• DE agnostic

• Server/daemon mode

• User configurable font fallback

• On-the-fly font resize

• On-the-fly DPI font size adjustment

• Scrollback search

• Keyboard driven URL detection

• Color emoji support

• IME (via text-input-v3)

• Multi-seat

• True Color (24bpp)

• Synchronized Updates support

• Sixel image support

  wow

Installing

See INSTALL.md.

Configuration

foot can be configured by creating a file $XDG_CONFIG_HOME/foot/foot.ini (defaulting to ~/.config/foot/foot.ini). A template for that can usually be found in /etc/xdg/foot/foot.ini or here.

Further information can be found in foot's man page foot.ini(5).

Troubleshooting

See the wiki

Why the name 'foot'?

I'm bad at names. Most of my projects usually start out as foo something (for example, yambar was f00bar for a while).

So why foot?

foo terminal → footerm → foot

Pretty bad, I know.

As a side note, if you pronounce the foo part of foot the same way you pronounce foobar, then foot sounds a lot like the Swedish word fot, which incidentally means (you guessed it) foot.

Fonts

foot supports all fonts that can be loaded by freetype, including bitmap fonts and color emoji fonts.

Foot uses fontconfig to locate and configure the font(s) to use. Since fontconfig's fallback mechanism is imperfect, especially for monospace fonts (it doesn't prefer monospace fonts even though the requested font is one), foot allows you, the user, to configure the fallback fonts to use.

This also means you can configure each fallback font individually; you want that fallback font to use this size, and you want that other fallback font to be italic? No problem!

If a glyph cannot be found in any of the user configured fallback fonts, then fontconfig's list is used.

Shortcuts

These are the default shortcuts. See man foot.ini and the example foot.ini to see how these can be changed.

Keyboard

Normal mode

shift+page up/page down

Scroll up/down in history

ctrl+shift+c, XF86Copy

Copy selected text to the clipboard

ctrl+shift+v, XF86Paste

Paste from clipboard

shift+insert

Paste from the primary selection

ctrl+shift+r

Start a scrollback search

ctrl++, ctrl+=

Increase font size by 0,5pt

ctrl+-

Decrease font size by 0,5pt

ctrl+0

Reset font size

ctrl+shift+n

Spawn a new terminal. If the shell has been configured to emit the OSC 7 escape sequence, the new terminal will start in the current working directory.

ctrl+shift+o

Enter URL mode, where all currently visible URLs are tagged with a jump label with a key sequence that will open the URL.

ctrl+shift+u

Enter Unicode input mode.

ctrl+shift+z

Jump to the previous, currently not visible, prompt. Requires shell integration.

ctrl+shift+x

Jump to the next prompt. Requires shell integration.

Scrollback search

ctrl+r

Search backward for next match

ctrl+s

Search forward for next match

ctrl+w

Extend current selection (and thus the search criteria) to the end of the word, or the next word if currently at a word separating character.

ctrl+shift+w

Same as ctrl+w, except that the only word separating characters are whitespace characters.

ctrl+v, ctrl+shift+v, ctrl+y, XF86Paste

Paste from clipboard into the search buffer.

shift+insert

Paste from primary selection into the search buffer.

escape, ctrl+g

Cancel the search

return

Finish the search and copy the current match to the primary selection

URL mode

t

Toggle whether the URL is displayed in the jump label or not

escape, ctrl+c, ctrl+g, ctrl+d

Exit URL mode without launching any URLs

Mouse

left - single-click

Drag to select; when released, the selected text is copied to the primary selection. This feature is disabled when client has enabled mouse tracking.

Holding shift enables selection in mouse tracking enabled clients.

Holding ctrl will create a block selection.

left - double-click

Selects the word (separated by spaces, period, comma, parenthesis etc) under the pointer. Hold ctrl to select everything under the pointer up to, and until, the next space characters.

left - triple-click

Selects the entire row

middle

Paste from primary selection

right

Extend current selection. Clicking immediately extends the selection, while hold-and-drag allows you to interactively resize the selection.

wheel

Scroll up/down in history

Touchscreen

tap

Emulates mouse left button click.

drag

Scrolls up/down in history.

Holding for a while before dragging (time delay can be configured) emulates mouse dragging with left button held.

Server (daemon) mode

When run normally, foot is a single-window application; if you want another window, start another foot process.

However, foot can also be run in a server mode. In this mode, one process hosts multiple windows. All Wayland communication, VT parsing and rendering is done in the server process.

New windows are opened by running footclient, which remains running until the terminal window is closed, at which point it exits with the exit value of the client process (typically the shell).

The point of this mode is a) reduced memory footprint - all terminal windows will share fonts and glyph cache, and b) reduced startup time - loading fonts and populating the glyph cache takes time, but in server mode it only happens once.

The downside is a performance penalty; all windows' input and output are multiplexed in the same thread (but each window will have its own set of rendering threads). This means that if one window is very busy with, for example, producing output, then other windows will suffer.

And of course, should the server process crash, all windows will be gone.

Typical usage would be to start the server process (foot --server) when starting your Wayland compositor (i.e. logging in to your desktop), and then run footclient instead of foot whenever you want to launch a new terminal.

Foot support socket activation, which means foot --server will only be started the first time you'll run footclient. (systemd user units are included, but it can work with other supervision suites).

URLs

Foot supports URL detection. But, unlike many other terminal emulators, where URLs are highlighted when they are hovered and opened by clicking on them, foot uses a keyboard driven approach.

Pressing ctrl+shift+o enters "URL mode", where all currently visible URLs are underlined, and is associated with a "jump-label". The jump-label indicates the key sequence (e.g. "AF") to use to activate the URL.

The key binding can, of course, be customized, like all other key bindings in foot. See show-urls-launch and show-urls-copy in the foot.ini man page.

show-urls-launch by default opens the URL with xdg-open. This can be changed with the url-launch option.

show-urls-copy is an alternative to show-urls-launch, that changes what activating a URL does; instead of opening it, it copies it to the clipboard. It is unbound by default.

Jump label colors, the URL underline color, and the letters used in the jump label key sequences can be configured.

Shell integration

Current working directory

New foot terminal instances (bound to ctrl+shift+n by default) will open in the current working directory, if the shell in the "parent" terminal reports directory changes.

This is done with the OSC-7 escape sequence. Most shells can be scripted to do this, if they do not support it natively. See the wiki for details.

Jumping between prompts

Foot can move the current viewport to focus prompts of already executed commands (bound to ctrl+shift+z/x by default).

For this to work, the shell needs to emit an OSC-133;A (\E]133;A\E\\) sequence before each prompt.

In zsh, one way to do this is to add a precmd hook:

precmd() {
 print -Pn "\e]133;A\e\\"
}

See the wiki for details, and examples for other shells.

Alt/meta

By default, foot prefixes Meta characters with ESC. This corresponds to XTerm's metaSendsEscape option set to true.

This can be disabled programmatically with \E[?1036l (and enabled again with \E[?1036h).

When disabled, foot will instead set the 8:th bit of meta character and then UTF-8 encode it. This corresponds to XTerm's eightBitMeta option set to true.

This can also be disabled programmatically with rmm (reset meta mode, \E[?1034l), and enabled again with smm (set meta mode, \E[?1034h).

Backspace

Foot transmits DEL (^?) on backspace. This corresponds to XTerm's backarrowKey option set to false, and to DECBKM being reset.

To instead transmit BS (^H), press ctrl+backspace.

Note that foot does not implement DECBKM, and that the behavior described above cannot be changed.

Finally, pressing alt will prefix the transmitted byte with ESC.

Keypad

By default, Num Lock overrides the run-time configuration keypad mode; when active, the keypad is always considered to be in numerical mode. This corresponds to XTerm's numLock option set to true.

In this mode, the keypad keys always sends either numbers (Num Lock is active) or cursor movement keys (Up, Down, Left, Right, Page Up, Page Down etc).

This can be disabled programmatically with \E[?1035l (and enabled again with \E[?1035h).

When disabled, the keypad sends custom escape sequences instead of numbers, when in application mode.

DPI and font size

Font sizes are apparently a complex thing. Many applications use a fixed DPI of 96. They may also multiply it with the monitor's scale factor.

This results in fonts with different physical sizes (i.e. if measured by a ruler) when rendered on screens with different DPI values. Even if the configured font size is the same.

This is not how it is meant to be. Fonts are measured in point sizes for a reason; a given point size should have the same height on all mediums, be it printers or monitors, regardless of their DPI.

That said, on Wayland, Hi-DPI monitors are typically handled by configuring a "scaling factor" in the compositor. This is usually expressed as either a rational value (e.g. 1.5), or as a percentage (e.g. 150%), by which all fonts and window sizes are supposed to be multiplied.

For this reason, and because of the new fractional scaling protocol (see below for details), and because this is how Wayland applications are expected to behave, foot >= 1.15 will default to scaling fonts using the compositor’s scaling factor, and not the monitor DPI.

This means the (assuming the monitors are at the same viewing distance) the font size will appear to change when you move the foot window across different monitors, unless you have configured the monitors’ scaling factors correctly in the compositor.

This can be changed by setting the dpi-aware option to yes in foot.ini. When enabled, fonts will not be sized using the scaling factor, but will instead be sized using the monitor’s DPI. When the foot window is moved across monitors, the font size is updated for the current monitor’s DPI.

This means that, assuming the monitors are at the same viewing distance, the font size will appear to be the same, at all times.

Note: if you configure pixelsize, rather than size, then DPI changes will not change the font size. Pixels are always pixels.

Fractional scaling on Wayland

For a long time, there was no true support for fractional scaling. That is, values like 1.5 (150%), 1.8 (180%) etc, only integer values, like 2 (200%).

Compositors that did support fractional scaling did so using a hack; all applications were told to scale to 200%, and then the compositor would down-scale the rendered image to e.g. 150%. This works OK for everything except fonts, which ended up blurry.

With wayland-protocols 1.32, a new protocol was introduced, that allows compositors to tell applications the actual scaling factor. Applications can then scale the image using a viewport object, instead of setting a scale factor on the raw pixel buffer.

Supported OSCs

OSC, Operating System Command, are escape sequences that interacts with the terminal emulator itself. Foot implements the following OSCs:

• OSC 0 - change window icon + title (but only title is actually supported)
• OSC 2 - change window title
• OSC 4 - change color palette
• OSC 7 - report CWD (see shell integration)
• OSC 8 - hyperlink
• OSC 9 - desktop notification
• OSC 10 - change (default) foreground color
• OSC 11 - change (default) background color
• OSC 12 - change cursor color
• OSC 17 - change highlight (selection) background color
• OSC 19 - change highlight (selection) foreground color
• OSC 22 - set the xcursor (mouse) pointer
• OSC 52 - copy/paste clipboard data
• OSC 104 - reset color palette
• OSC 110 - reset default foreground color
• OSC 111 - reset default background color
• OSC 112 - reset cursor color
• OSC 117 - reset highlight background color
• OSC 119 - reset highlight foreground color
• OSC 133 - shell integration
• OSC 555 - flash screen (foot specific)
• OSC 777 - desktop notification (only the ;notify sub-command of OSC 777 is supported.)

See the foot-ctlseq(7) man page for a complete list of supported control sequences.

Programmatically checking if running in foot

Foot does not set any environment variables that can be used to identify foot (reading TERM is not reliable since the user may have chosen to use a different terminfo).

You can instead use the escape sequences to read the Secondary and Tertiary Device Attributes (secondary/tertiary DA, for short).

The tertiary DA response is always \EP!|464f4f54\E\\, where 464f4f54 is FOOT in hex.

The secondary DA response is \E[>1;XXYYZZ;0c, where XXYYZZ is foot's major, minor and patch version numbers, in decimal, using two digits for each number. For example, foot-1.4.2 would respond with \E[>1;010402;0c.

Note: not all terminal emulators implement tertiary DA. Most implement secondary DA, but not all. All should however implement Primary DA.

Thus, a safe way to query the terminal is to request the tertiary, secondary and primary DA all at once, in that order. All terminals should ignore escape sequences they do not recognize. You will have to parse the response (which in foot will consist of all three DA responses, all at once) to determine which requests the terminal emulator actually responded to.

Starting with version 1.7.0, foot also implements XTVERSION, to which it will reply with \EP>|foot(version)\E\\. Version is e.g. "1.8.2" for a regular release, or "1.8.2-36-g7db8e06f" for a git build.

XTGETTCAP

XTGETTCAP is an escape sequence initially introduced by XTerm, and also implemented (and extended, to some degree) by Kitty.

It allows querying the terminal for terminfo capabilities. Applications using this feature do not need to use the classic, file-based, terminfo definition. For example, if all applications used this feature, you would no longer have to install foot’s terminfo on remote hosts you SSH into.

XTerm’s implementation (as of XTerm-370) only supports querying key (as in keyboard keys) capabilities, and three custom capabilities:

• TN - terminal name
• Co - number of colors (alias for the colors capability)
• RGB - number of bits per color channel (different semantics from the RGB capability in file-based terminfo definitions!).

Kitty has extended this, and also supports querying all integer and string capabilities.

Foot supports this, and extends it even further, to also include boolean capabilities. This means foot’s entire terminfo can be queried via XTGETTCAP.

Note that both Kitty and foot handles responses to multi-capability queries slightly differently, compared to XTerm.

XTerm will send a single DCS reply, with ;-separated capability/value pairs. There are a couple of issues with this:

• The success/fail flag in the beginning of the response is always 1 (success), unless the very first queried capability is invalid.
• XTerm will not respond at all to an invalid capability, unless it’s the first one in the XTGETTCAP query.
• XTerm will end the response at the first invalid capability.

In other words, if you send a large multi-capability query, you will only get responses up to, but not including, the first invalid capability. All subsequent capabilities will be dropped.

Kitty and foot on the other hand, send one DCS response for each capability in the multi query. This allows us to send a proper success/fail flag for each queried capability. Responses for all queried capabilities are always sent. No queries are ever dropped.

Credits

• Ordoviz, for designing and contributing foot's logo.

Bugs

Please report bugs to https://codeberg.org/dnkl/foot/issues

Before you open a new issue, please search existing bug reports, both open and closed ones. Chances are someone else has already reported the same issue.

The report should contain the following:

• Foot version (foot --version).
• Log output from foot (run foot -d info from another terminal).
• Which Wayland compositor (and version) you are running.
• If reporting a crash, please try to provide a bt full backtrace with symbols.
• Steps to reproduce. The more details the better.

Contact

IRC

Ask questions, hang out, sing praise or just say hi in the #foot channel on irc.libera.chat. Logs are available at https://libera.irclog.whitequark.org/foot.

Mastodon

Every now and then I post foot related updates on @dnkl@linuxrocks.online

Sponsoring/donations

• GitHub Sponsors: https://github.com/sponsors/dnkl

License

Foot is released under the MIT license.