Finn Evers
2044426634
Closes #28164 This PR adresses inproper keybinds being shown in MacOS application menus. The issue arises because the keybinds shown in MacOS application menus are unaware of keybind contexts (they are only ever updated [on a keymap-change](https://github.com/zed-industries/zed/blob/6d1dd109f554579bdf676c14b69deb9e16acc043/crates/zed/src/zed.rs#L1421)). Thus, using the keybind that was added last in the keymap can result in incorrect keybindings being shown quite frequently, as they might belong to a different context not generally available (applies the same for the default keymap as well as for user-keymaps). For example, the linked issue arises because the keybind found last in the iterator is https://github.com/zed-industries/zed/blob/6d1dd109f554579bdf676c14b69deb9e16acc043/assets/keymaps/vim.json#L759, which is not even available in most contexts (and, additionally, the `e` of `escape` is rendered here as a keybind which seems to be a seperate issue). Additionally, this would result in inconsistent behavior with some Vim-keybinds. A vim-keybind would be used only when available but otherwise the default binding would be shown (see `Undo` and `Redo` as an example below), which seems inconsistent. This PR fixes this by instead using the first keybind found in keymaps, which is expected to be the keybind available in most contexts. Additionally, this allows rendering some more keybinds for actions which vim-keybind cannot be displayed (Find In Project for example) .This seems to be more reasonable until [this related comment](https://github.com/zed-industries/zed/blob/6d1dd109f554579bdf676c14b69deb9e16acc043/crates/gpui/src/keymap.rs#L199-L204) is resolved. This includes a revert of #25878 as well. With this change, the change made in #25878 becomes obsolete and would also regress the behavior back to the state prior to that PR. | | `main` | This PR | | --- | --- | --- | | Edit-menu | <img width="220" alt="main_edit" src="https://github.com/user-attachments/assets/9f793b64-80b6-4a5b-b7e5-628f0d552166" /> | <img width="220" alt="PR_edit" src="https://github.com/user-attachments/assets/bccb444c-7a49-41d5-9377-d90b1639a3ed" /> | | View-menu | <img width="214" alt="main_view" src="https://github.com/user-attachments/assets/0e6a6632-df02-4883-9f5a-facb4d0263b5" /> | <img width="214" alt="PR_view" src="https://github.com/user-attachments/assets/14600ece-fcaa-447a-94ef-4fa350eca49c" /> | Release Notes: - Improved keybinds displayed for actions in MacOS application menus.
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.