This reverts commit efba2cbfd3.
Unfortunately, the Docker image for 1.89 has not shown up yet. Once it
has, we should re-land this.
Release Notes:
- N/A
Now ! means "no ancestors matches this", and > means "any descendent"
not "any child".
Updates #34570
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- *Breaking change*. The context predicates in the keymap file now
handle ! and > differently. Before this change ! meant "this node does
not match", now it means "none of these nodes match". Before this change
> meant "child of", now it means "descendent of". We do not expect these
changes to break many keymaps, but they may cause subtle changes for
complex context queries.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Adds the initial semblance of a keymap UI. It is currently gated behind the `settings-ui` feature flag. Follow up PRs will add polish and missing features.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Anthony <anthony@zed.dev>
Closes #ISSUE
Adds a very simple API to track metadata about keybindings in GPUI,
namely the source of the binding. The motivation for this is displaying
the source of keybindings in the [keymap
UI](https://github.com/zed-industries/zed/pull/32436).
The API is designed to be as simple and flexible as possible, storing
only a `Option<u32>` on the bindings themselves to keep the struct
small. It is intended to be used as an index or key into a table/map
created and managed by the consumer of the API to map from indices to
arbitrary meta-data. I.e. the consumer is responsible for both
generating these indices and giving them meaning.
The current usage in Zed is stateless, just a mapping between constants
and User, Default, Base, and Vim keymap sources, however, this can be
extended in the future to also track _which_ base keymap is being used.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Instead of a menagerie of macros for implementing `Action`, now there
are just two:
* `actions!(editor, [MoveLeft, MoveRight])`
* `#[derive(..., Action)]` with `#[action(namespace = editor)]`
In both contexts, `///` doc comments can be provided and will be used in
`JsonSchema`.
In both contexts, parameters can provided in `#[action(...)]`:
- `namespace = some_namespace` sets the namespace. In Zed this is
required.
- `name = "ActionName"` overrides the action's name. This must not
contain "::".
- `no_json` causes the `build` method to always error and
`action_json_schema` to return `None`
and allows actions not implement `serde::Serialize` and
`schemars::JsonSchema`.
- `no_register` skips registering the action. This is useful for
implementing the `Action` trait
while not supporting invocation by name or JSON deserialization.
- `deprecated_aliases = ["editor::SomeAction"]` specifies deprecated old
names for the action.
These action names should *not* correspond to any actions that are
registered. These old names
can then still be used to refer to invoke this action. In Zed, the
keymap JSON schema will
accept these old names and provide warnings.
- `deprecated = "Message about why this action is deprecation"`
specifies a deprecation message.
In Zed, the keymap JSON schema will cause this to be displayed as a
warning. This is a new feature.
Also makes the following changes since this seems like a good time to
make breaking changes:
* In `zed.rs` tests adds a test with an explicit list of namespaces. The
rationale for this is that there is otherwise no checking of `namespace
= ...` attributes.
* `Action::debug_name` renamed to `name_for_type`, since its only
difference with `name` was that it
* `Action::name` now returns `&'static str` instead of `&str` to match
the return of `name_for_type`. This makes the action trait more limited,
but the code was already assuming that `name_for_type` is the same as
`name`, and it requires `&'static`. So really this just makes the trait
harder to misuse.
* Various action reflection methods now use `&'static str` instead of
`SharedString`.
Release Notes:
- N/A
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
In Zed the key context almost always has more than 1 entry, so use of
`SmallVec` is just adding overhead.
In Zed while using the editor this typically has more than 8 entries.
Since `ContextEntry` is 48 bytes, if this were made to be a
`SmallVec<[ContextEntry; 10]>` then it would use 480 bytes on the stack,
which to me seems like a lot to be copying. So, instead opting to just
use `Vec`
Release Notes:
- N/A
* Collects and reports all parse errors
* Shares parsed `KeyBindingContextPredicate` among the actions.
* Updates gpui keybinding and action parsing to return structured
errors.
* Renames "block" to "section" to match the docs, as types like
`KeymapSection` are shown in `json-language-server` hovers.
* Removes wrapping of `context` and `use_key_equivalents` fields so that
`json-language-server` auto-inserts `""` and `false` instead of `null`.
* Updates `add_to_cx` to take `&self`, so that the user keymap doesn't
get unnecessarily cloned.
In retrospect I wish I'd just switched to using TreeSitter to do the
parsing and provide proper diagnostics. This is tracked in #23333
Release Notes:
- Improved handling of errors within the user keymap file. Parse errors
within context, keystrokes, or actions no longer prevent loading the key
bindings that do parse.
Closes #16343Closes#10972
Release Notes:
- (breaking change) On macOS when using a keyboard that supports an
extended Latin character set (e.g. French, German, ...) keyboard
shortcuts are automatically updated so that they can be typed without
`option`. This fixes several long-standing problems where some keyboards
could not type some shortcuts.
- This mapping works the same way as
[macOS](https://developer.apple.com/documentation/swiftui/view/keyboardshortcut(_:modifiers:localization:)).
For example on a German keyboard shortcuts like `cmd->` become `cmd-:`,
`cmd-[` and `cmd-]` become `cmd-ö` and `cmd-ä`. This mapping happens at
the time keyboard layout files are read so the keybindings are visible
in the command palette. To opt out of this behavior for your custom
keyboard shortcuts, set `"use_layout_keys": true` in your binding
section. For the mappings used for each layout [see
here](a890df1863/crates/settings/src/key_equivalents.rs (L7)).
---------
Co-authored-by: Will <will@zed.dev>
Simplify key dispatch code.
Previously we would maintain a cache of key matchers for each context
that
would store the pending input. For the last while we've also stored the
typed prefix on the window. This is redundant, we only need one copy, so
now
it's just stored on the window, which lets us avoid the boilerplate of
keeping
all the matchers in sync.
This stops us from losing multikey bindings when the context on a node
changes
(#11009) (though we still interrupt multikey bindings if the focus
changes).
While in the code, I fixed up a few other things with multi-key bindings
that
were causing problems:
Previously we assumed that all multi-key bindings took precedence over
any
single-key binding, now this is done such that if a user binds a
single-key
binding, it will take precedence over all system-defined multi-key
bindings
(irrespective of the depth in the context tree). This was a common cause
of
confusion for new users trying to bind to `cmd-k` or `ctrl-w` in vim
mode
(#13543).
Previously after a pending multi-key keystroke failed to match, we would
drop
the prefix if it was an input event. Now we correctly replay it
(#14725).
Release Notes:
- Fixed multi-key shortcuts not working across completion menu changes
([#11009](https://github.com/zed-industries/zed/issues/11009))
- Fixed multi-key shortcuts discarding earlier input
([#14445](https://github.com/zed-industries/zed/pull/14445))
- vim: Fixed `jk` binding preventing you from repeating `j`
([#14725](https://github.com/zed-industries/zed/issues/14725))
- vim: Fixed `escape` in normal mode to also clear the selected
register.
- Fixed key maps so user-defined mappings take precedence over builtin
multi-key mappings
([#13543](https://github.com/zed-industries/zed/issues/13543))
- Fixed a bug where overridden shortcuts would still show in the Command
Palette
This PR includes two relevant changes:
- Platform binds (super, windows, cmd) will now parse on all platforms,
regardless of which one is being used. While very counter-intuitive
(this means that `cmd-d` will actually be triggered by `win-d` on
windows) this makes it possible to reuse keymap files across platforms
easily
- There is now a KeyContext `os == linux`, `os == macos` or `os ==
windows` available in keymaps. This allows users to specify certain
blocks of keybinds only for one OS, allowing you to minimize the amount
of keymappings that you have to re-configure for each platform.
Release Notes:
- Added `os` KeyContext, set to either `linux`, `macos` or `windows`
- Fixed keymap parsing errors when `cmd` was used on linux, `super` was
used on mac, etc.
Before this change if you had a matching binding and a pending key,
the matching binding happened unconditionally.
Now we will wait a second before triggering that binding to give you
time to complete the action.
