---
title: Generate
description: Write your bindings into Karabiner, and how Vimputer hears them fire.
---

Vimputer edits its own config. Karabiner only sees your bindings once you
generate. The buttons are in **Settings → Karabiner**.

| Button | Writes | Then |
| --- | --- | --- |
| Generate and activate | `~/.config/karabiner/karabiner.json` | Switches Karabiner to the Vimputer profile |
| Test file | `~/Library/Application Support/Vimputer/karabiner.test.json` | Nothing; diff it or load it yourself |

Generating rewrites the rules of one Karabiner profile, named after your Vimputer
profile ("Vimputer" by default). Other profiles are left alone. The first time,
the new profile copies device settings and simple modifications from the profile
that was active.

Bindings with unsaved drafts are written as they were last saved. The row warns
you, as in "2 unsaved drafts won't be written".

## Compiler settings

| Setting | Does |
| --- | --- |
| Simultaneous threshold | The default chord window, in milliseconds. 100 when empty. A chord's own **Pressed together within** overrides it. |
| Runtime ingress | How bindings reach Vimputer. Keep **Send user command**. **Socket (legacy)** sends nothing, so the HUD stops following layers and Vimputer actions are left out. |

## How Vimputer hears keys

Bindings that enter or leave a modal layer also tell Vimputer, which is how the
[HUD](/docs/runtime/hud) knows what's active.

Some actions run inside Vimputer, so they need the app running: plugin commands,
menu and app commands, and Vimputer actions. Shortcuts, typing,
opening apps and URLs, and layers work without it.