foot.ini(5) | File Formats Manual | foot.ini(5) |
foot.ini - configuration file for foot(1)
foot uses the standard unix configuration format, with section based key/value pairs. The default section is unnamed (i.e. not prefixed with a [section]).
foot will search for a configuration file in the following locations, in this order:
font, font-bold, font-italic, font-bold-italic
Examples:
For each option, the first font is the primary font. The remaining fonts are fallback fonts that will be used whenever a glyph cannot be found in the primary font.
The fallback fonts are searched in the order they appear. If a glyph cannot be found in any of the fallback fonts, the dynamic fallback list from fontconfig (for the primary font) is searched.
font-bold, font-italic and font-bold-italic allow custom fonts to be used for bold/italic/bold+italic fonts. If left unconfigured, the bold/italic variants of the regular font(s) specified in font are used. Note: you may have to tweak the size(s) of the custom bold/italic fonts to match the regular font.
To disable bold and/or italic fonts, set e.g. font-bold to exactly the same value as font.
Default: monospace:size=8 (font), not set (font-bold, font-italic, font-bold-italic).
dpi-aware
In this mode, the monitor's scaling factor is ignored; doubling the scaling factor will not double the font size.
When set to no, the monitor's DPI is ignored. The font is instead sized using the monitor's scaling factor; doubling the scaling factor does double the font size.
Finally, if set to auto, fonts will be sized using the monitor's DPI on monitors with a scaling factor of 1, but otherwise size fonts using the scaling factor.
Default: auto
pad
initial-window-size-pixels
initial-window-size-chars
Note that if you have a multi-monitor setup, with different scaling factors, there is a possibility the window size will not be set correctly. If that is the case, use initial-window-size-pixels instead.
Default: not set.
initial-window-mode
geometry
shell
login-shell
term
title
app-id
bold-text-in-bright
bell
When set to set-urgency, the margins will be painted in red whenever BEL is received while the window does not have keyboard focus. Note that Wayland currently does not have an urgency hint like X11. The value set-urgency was chosen for forward-compatibility in the hopes that a corresponding Wayland protocol is added in the future (in which case foot will use that instead of painting its margins red).
Applications can enable/disable this feature programmatically with the CSI ? 1042 h and CSI ? 1042 l escape sequences.
Note: expect this feature to be replaced with proper compositor urgency support once/if that gets implemented.
When set to notify, foot will emit a desktop notification (see the notify option).
When set to none, no special action is taken when receiving BEL.
Default: none.
word-delimiters
notify
Applications can trigger notifications in the following ways:
Default: notify-send -a foot -i foot ${title} ${body}.
selection-target
workers
lines
multiplier
indicator-position
indicator-format
This section controls the cursor style and color. Note that applications can change these at runtime.
style
blink
color
hide-when-typing
alternate-scroll-mode
This lets you scroll with the mouse in e.g. pagers (like less) without enabling native mouse support in them.
Alternate scrolling is not used if the application enables native mouse support.
This option can be modified by applications at run-time using the escape sequences CSI ? 1007 h (enable) and CSI ? 1007 l (disable).
Default: yes.
This section controls the 16 ANSI colors and the default foreground and background colors. Note that applications can change these at runtime.
The colors are in RRGGBB format. That is, they do not have an alpha component. You can configure the background transparency with the alpha option.
foreground
background
regular0, regular1 .. regular7
bright0, bright1 .. bright7
alpha
selection-foreground, selection-background
This section controls the look of the CSDs (Client Side Decorations). Note that the default is to not use CSDs, but instead to use SSDs (Server Side Decorations) when the compositor supports it.
Note that unlike the colors defined in the colors section, the color values here are in AARRGGBB format. I.e. they contain an alpha component.
preferred
Note that this is only a hint to the compositor. Depending on compositor support, and how it has been configured, it may instruct foot to use CSDs even though this option has been set to server, or render SSDs despite client or none being set.
Default: server.
size
color
button-width
button-minimize-color
button-maximize-color
button-close-color
This section lets you override the default key bindings.
The general format is action=combo1...comboN. That is, each action may have one or more key combinations, space separated. Each combination is on the form mod1+mod2+key. The names of the modifiers and the key must be valid XKB key names.
Note that if Shift is one of the modifiers, the key must be in upper case. For example, Control+Shift+v will never trigger, but Control+Shift+V will.
Note that Alt is usually called Mod1.
A key combination can only be mapped to one action. Lets say you want to bind Control+Shift+R to fullscreen. Since this is the default shortcut for search-start, you first need to unmap the default binding. This can be done by setting action=none; e.g. search-start=none.
scrollback-up-page
scrollback-up-half-page
scrollback-up-line
scrollback-down-page
scrollback-down-half-page
scrollback-down-line
clipboard-copy
clipboard-paste
primary-paste
search-start
font-increase
font-decrease
font-reset
spawn-terminal
minimize
maximize
fullscreen
pipe-visible, pipe-scrollback, pipe-selected
You can configure multiple pipes as long as the command strings are different and the key bindings are unique.
Note that the command is not automatically run inside a shell; use sh -c "command line" if you need that.
Example:
Default: not bound
This section lets you override the default key bindings used in scrollback search mode. The syntax is exactly the same as the regular key-bindings.
cancel
commit
find-prev
find-next
cursor-left
cursor-left-word
cursor-right
cursor-right-word
cursor-home
cursor-end
delete-prev
delete-prev-word
delete-next
delete-next-word
extend-to-word-boundary
extend-to-next-whitespace
clipboard-paste
primary-paste
This section lets you override the default mouse bindings.
The general format is action=combo1...comboN. That is, each action may have one or more key combinations, space separated. Each combination is on the form mod1+mod2+BTN_<name>[-COUNT]. The names of the modifiers must be valid XKB key names, and the button name must be a valid libinput name. You can find the button names using libinput debug-events.
Note that Shift cannot be used as a modifier in mouse bindings since it is used to enable selection when the client application is grabbing the mouse.
The trailing COUNT is optional and specifies the click count required to trigger the binding. The default if COUNT is omitted is 1.
A modifier+button combination can only be mapped to one action. Lets say you want to bind BTN_MIDDLE to fullscreen. Since BTN_MIDDLE is the default binding for primary-paste, you first need to unmap the default binding. This can be done by setting action=none; e.g. primary-paste=none.
All actions listed under key-bindings can be user here as well.
select-begin
select-begin-block
select-extend
select-word
select-word-whitespace
select-row
primary-paste
This section is for advanced users and describes configuration options that can be used to tweak foot's low-level behavior.
These options are not included in the example configuration. You should not change these unless you understand what they do and note that changing the default values will print a warning when launching foot.
Note that these options may change, or be removed at any time, without prior notice.
When reporting bugs, please mention if, and to what, you have changed any of these options.
scaling-filter
Default: lanczos3.
allow-overflowing-double-width-glyphs
One use case for this is fonts "icon" characters in the Unicode private usage area, e.g. Nerd Fonts, or Powerline Fonts. Without this option, such glyphs will appear "cut off".
Another use case are legacy emoji characters like WHITE FROWNING FACE.
Note: this feature uses heuristics to determine which glyphs should be allowed to overflow.
Default: yes.
render-timer
delayed-render-lower, delayed-render-upper
If a client splits up a screen update over multiple write(3) calls, we may end up rendering an intermediate frame, quickly followed by another frame with the final screen content. For example, the client may erase part of the screen (or scroll) in one write, and then write new content in one or more subsequent writes. Rendering the frame when the screen has been erased, but not yet filled with new content will be perceived as screen flicker.
The real solution to this is Application Synchronized Updates (https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2).
The problem with this is twofold - first, it has not yet been standardized, and thus there are not many terminal emulators that implement it (foot does implement it), and second, applications must be patched to use it.
Until this has happened, foot offers an interim workaround; an attempt to mitigate the screen flicker without affecting neither performance nor latency.
It is based on the fact that the screen is updated at a fixed interval (typically 60Hz). For us, this means it does not matter if we render a new frame at the beginning of a frame interval, or at the end. Thus, the goal is to introduce a delay between receiving client data and rendering the resulting state, but without causing a frame skip.
While it should be possible to estimate the amount of time left until the next frame, foot's algorithm is currently not that advanced, but is based on statistics I guess you could say - the delay we introduce is so small that the risk of pushing the frame over to the next frame interval is also very small.
Now, that was a lot of text. But what is it foot actually does?
When receiving client data, it schedules a timer, the delayed-render-lower. If we do not receive any more client data before the timer has run out, we render the frame. If however, we do receive more data, the timer is re-scheduled. That is, each time we receive client data, frame rendering is delayed another delayed-render-lower nanoseconds.
Now, while this works very well with most clients, it would be possible to construct a malicious client that keeps writing data at a slow pace. To the user, this would look like foot has frozen as we never get to render a new frame. To prevent this, an upper limit is set - delayed-render-upper. If this timer runs out, we render the frame regardless of what the client is doing.
If changing these values, note that the lower timeout must be set lower than the upper timeout, but that this is not verified by foot. Furthermore, both values must be less than 16ms (that is, 16000000 nanoseconds).
You can disable the feature altogether by setting either value to 0. In this case, frames are rendered "as soon as possible".
Default: lower=500000 (0.5ms), upper=8333333 (8.3ms - half a frame interval).
damage-whole-window
There is normally no reason to enable this. However, it has been seen to workaround an issue with fractional scaling in Gnome.
Note that enabling this option is likely to increase CPU and/or GPU usage (by the compositor, not by foot), and may have a negative impact on battery life.
Default: no.
max-shm-pool-size-mb
It does not change how much physical memory foot uses.
Foot uses a memory mapping trick to implement fast rendering of interactive scrolling (typically, but applies to "slow" scrolling in general). Example: holding down the 'up' or 'down' arrow key to scroll in a text editor.
For this to work, it needs a large amount of virtual address space. Again, note that this is not physical memory.
On a normal x64 based computer, each process has 128TB of virtual address space, and newer ones have 64PB. This is an insane amount and most applications do not use anywhere near that amount.
Each foot terminal window can allocate up to 2GB of virtual address space. With 128TB of address space, that means a maximum of 65536 windows in server/daemon mode (for 2GB). That should be enough, yes?
However, the Wayland compositor also needs to allocate the same amount of virtual address space. Thus, it has a slightly higher chance of running out of address space since it needs to host all running Wayland clients in the same way, at the same time.
In the off chance that this becomes a problem for you, you can reduce the amount used with this option.
Or, for optimal performance, you can increase it to the maximum allowed value, 2GB (but note that you most likely will not notice any difference compared to the default value).
Setting it to 0 disables the feature.
Note: this feature is always disabled in 32-bit.
Default: 512. Maximum allowed: 2048 (2GB).
2021-02-13 |