foot (original) (raw)

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 orhere.

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, yambarwas 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 examplefoot.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

ctrl+-

Decrease font size

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

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 everything between enclosing quotes, or the entire row if not inside a quote.

left - quad-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.

ctrl+right

Extend the current selection, but force it to be character wise, rather than depending on the original selection mode.

wheel

Scroll up/down in history

ctrl+wheel

Increase/decrease font size

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 supports 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 thefoot.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 toctrl+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 thewikifor details.

Jumping between prompts

Foot can move the current viewport to focus prompts of already executed commands (bound toctrl+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 thewikifor details, and examples for other shells.

Piping last command's output

The key binding pipe-command-output can pipe the last command's output to an application of your choice (similar to the other pipe-*key bindings):

[key-bindings]
pipe-command-output=[sh -c "f=$(mktemp); cat - > <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>f</mi><mo separator="true">;</mo><mi>f</mi><mi>o</mi><mi>o</mi><mi>t</mi><mi>c</mi><mi>l</mi><mi>i</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>m</mi><mi>a</mi><mi>c</mi><mi>s</mi><mi>c</mi><mi>l</mi><mi>i</mi><mi>e</mi><mi>n</mi><mi>t</mi><mo>−</mo><mi>n</mi><mi>w</mi></mrow><annotation encoding="application/x-tex">f; footclient emacsclient -nw </annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.8889em;vertical-align:-0.1944em;"></span><span class="mord mathnormal" style="margin-right:0.10764em;">f</span><span class="mpunct">;</span><span class="mspace" style="margin-right:0.1667em;"></span><span class="mord mathnormal" style="margin-right:0.10764em;">f</span><span class="mord mathnormal">oo</span><span class="mord mathnormal">t</span><span class="mord mathnormal">c</span><span class="mord mathnormal" style="margin-right:0.01968em;">l</span><span class="mord mathnormal">i</span><span class="mord mathnormal">e</span><span class="mord mathnormal">n</span><span class="mord mathnormal">t</span><span class="mord mathnormal">e</span><span class="mord mathnormal">ma</span><span class="mord mathnormal">csc</span><span class="mord mathnormal" style="margin-right:0.01968em;">l</span><span class="mord mathnormal">i</span><span class="mord mathnormal">e</span><span class="mord mathnormal">n</span><span class="mord mathnormal">t</span><span class="mspace" style="margin-right:0.2222em;"></span><span class="mbin">−</span><span class="mspace" style="margin-right:0.2222em;"></span></span><span class="base"><span class="strut" style="height:0.4306em;"></span><span class="mord mathnormal">n</span><span class="mord mathnormal" style="margin-right:0.02691em;">w</span></span></span></span>f; rm $f"] Control+Shift+g

When pressing ctrl+shift+g, the last command's output is written to a temporary file, then an emacsclient is started in a new footclient instance. The temporary file is removed after the footclient instance has closed.

For this to work, the shell must emit an OSC-133;C (\E]133;C\E\\) sequence before command output starts, and an OSC-133;D (\E]133;D\E\\) when the command output ends.

In fish, one way to do this is to add preexec and postexec hooks:

function foot_cmd_start --on-event fish_preexec
  echo -en "\e]133;C\e\\"
end

function foot_cmd_end --on-event fish_postexec
  echo -en "\e]133;D\e\\"
end

See thewikifor 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 eightBitMetaoption 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 toDECBKM being reset.

To instead transmit BS (^H), pressctrl+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 totrue.

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 infoot.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 176 - set app ID
OSC 555 - flash screen (foot specific)
OSC 777 - desktop notification (only the ;notify sub-command of OSC 777 is supported.)

See the foot-ctlseqs(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\\, where464f4f54 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 eachcapability in the multi query. This allows us to send a proper success/fail flag for each queried capability. Responses for allqueried capabilities are always sent. No queries are ever dropped.

All replies are in tigetstr() format. That is, given the same capability name, foot's reply is identical to what tigetstr() would have returned.

In addition to queries for terminfo entries, the query-os-name query will be answered with a response of the form uname=$(uname -s), where $(uname -s) is the name of the OS foot was compiled for.

Credits

Ordoviz, for designing and contributing foot's logo.

Code of Conduct

See Code of Conduct

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 #footchannel onirc.libera.chat. Logs are available at https://libera.irclog.whitequark.org/foot.

Mastodon

Every now and then I post foot related updates on@dnkl@social.treehouse.systems

Sponsoring/donations

Liberapay: https://liberapay.com/dnkl
GitHub Sponsors: https://github.com/sponsors/dnkl

License

Foot is released under the MIT license.