Skip to content

Feat unbind (#52047) (cherry-pick to preview)#52216

Merged
zed-zippy[bot] merged 1 commit intov0.229.xfrom
cherry-pick-v0.229.x-4a965d18
Mar 23, 2026
Merged

Feat unbind (#52047) (cherry-pick to preview)#52216
zed-zippy[bot] merged 1 commit intov0.229.xfrom
cherry-pick-v0.229.x-4a965d18

Conversation

@zed-zippy
Copy link
Copy Markdown
Contributor

@zed-zippy zed-zippy bot commented Mar 23, 2026

Cherry-pick of #52047 to preview


Context

This PR adds an Unbind action, as well as syntax sugar in the keymaps
for declaring it

{
  "unbind": {
    "tab: "editor::AcceptEditPrediction"
  }
}

Is equivalent to

{
  "bindings": {
    "tab: ["zed::Unbind", "editor::AcceptEditPrediction"]
  }
}

In the keymap, unbind is always parsed first, so that you can unbind and
rebind something in the same block.

The semantics of Unbind differ from NoAction in that NoAction is
treated as an action, Unbind is treated as a filter. In practice
this means that when resolving bindings, we stop searching when we hit a
NoAction (because we found a matching binding), but we keep looking
when we hit an Unbind and filter out keystroke:action pairs that match
previous unbindings. In essence Unbind is only an action so that it
fits cleanly in the existing logic. It is really just a storage of
deleted bindings.

The plan is to rework the edit predictions key bindings on top of this,
as well as use Unbind rather than NoAction in the keymap UI. Both
will be done in follow up PRs.

Additionally, in this initial implementation unbound actions are matched
by name only. The assumption is that actions with arguments are bound to
different keys in general. However, the current syntax allows providing
arguments to the unbound actions. Both so that copy-paste works, and so
that in the future if this functionality is added, keymaps will not
break.

How to Review

  • The dispatch logic in GPUI
  • The parsing logic in keymap_file.rs

Self-Review Checklist

  • I've reviewed my own diff for quality, security, and reliability
  • Unsafe blocks (if any) have justifying comments
  • The content is consistent with the UI/UX
    checklist
  • Tests cover the new/changed behavior
  • Performance impact has been considered and is acceptable

Release Notes:

  • Added support for unbinding key bindings from the default keymaps. You
    can now remove default bindings you don't want, without having to
    re-declare default bindings that use the same keys. For instance, to
    unbind tab from editor::AcceptEditPrediction, you can put the
    following in your keymap.json
[
  {
    "context": "Editor && edit_prediction",
    "unbind": {
      "tab": "editor::AcceptEditPrediction"
    }
  }
]

## Context

This PR adds an `Unbind` action, as well as syntax sugar in the keymaps
for declaring it
```
{
  "unbind": {
    "tab: "editor::AcceptEditPrediction"
  }
}
```
Is equivalent to
```
{
  "bindings": {
    "tab: ["zed::Unbind", "editor::AcceptEditPrediction"]
  }
}
```
In the keymap, unbind is always parsed first, so that you can unbind and
rebind something in the same block.

The semantics of `Unbind` differ from `NoAction` in that `NoAction` is
treated _as an action_, `Unbind` is treated as a filter. In practice
this means that when resolving bindings, we stop searching when we hit a
`NoAction` (because we found a matching binding), but we keep looking
when we hit an `Unbind` and filter out keystroke:action pairs that match
previous unbindings. In essence `Unbind` is only an action so that it
fits cleanly in the existing logic. It is really just a storage of
deleted bindings.

The plan is to rework the edit predictions key bindings on top of this,
as well as use `Unbind` rather than `NoAction` in the keymap UI. Both
will be done in follow up PRs.

Additionally, in this initial implementation unbound actions are matched
by name only. The assumption is that actions with arguments are bound to
different keys in general. However, the current syntax allows providing
arguments to the unbound actions. Both so that copy-paste works, and so
that in the future if this functionality is added, keymaps will not
break.

## How to Review

- The dispatch logic in GPUI
- The parsing logic in `keymap_file.rs`

## Self-Review Checklist

<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Release Notes:

- Added support for unbinding key bindings from the default keymaps. You
can now remove default bindings you don't want, without having to
re-declare default bindings that use the same keys. For instance, to
unbind `tab` from `editor::AcceptEditPrediction`, you can put the
following in your `keymap.json`
```
[
  {
    "context": "Editor && edit_prediction",
    "unbind": {
      "tab": "editor::AcceptEditPrediction"
    }
  }
]
```
@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Mar 23, 2026
@zed-community-bot zed-community-bot bot added the bot Pull requests authored by a bot label Mar 23, 2026
@zed-codeowner-coordinator zed-codeowner-coordinator bot requested review from a team, ConradIrwin, SomeoneToIgnore, as-cii and dinocosta and removed request for a team March 23, 2026 14:47
@zed-zippy zed-zippy bot merged commit 59b3661 into v0.229.x Mar 23, 2026
41 checks passed
@zed-zippy zed-zippy bot deleted the cherry-pick-v0.229.x-4a965d18 branch March 23, 2026 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bot Pull requests authored by a bot cla-signed The user has signed the Contributor License Agreement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants