This PR improves the behavior of resetting a column's size by
double-clicking on its column handle. We now shrink/grow to the side
that has more leftover/additional space.
We also improved the below
1. dragging was a couple of pixels off to the left because we didn't
take the column handle’s width into account.
2. Column dragging now has memory and will shift things to their exact
position when reversing a drag before letting the drag handle go.
3. Improved our test infrastructure.
4. Double clicking on a column's header resizes the column
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
This PR splits the resize logic into separate left/right propagation
methods and improve code organization around column width adjustments.
It also allows resize to work for both the left and right sides as well,
instead of only checking the right side for room
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
This change dims rows in the keymap editor for which the corresponding
keybind is overridden by other keybinds coming from higher priority
sources.
Release Notes:
- N/A
This PR adds resizable columns to the keymap editor and the ability to
double-click on a resizable column to set a column back to its default
size.
The table uses a column's width to calculate what position it should be
laid out at. So `column[i]` x position is calculated by the summation of
`column[..i]`. When resizing `column[i]`, `column[i+1]`’s size is
adjusted to keep all columns’ relative positions the same. If
`column[i+1]` is at its minimum size, we keep seeking to the right to
find a column with space left to take.
An improvement to resizing behavior and double-clicking could be made by
checking both column ranges `0..i-1` and `i+1..COLS`, since only one
range of columns is checked for resize capacity.
Release Notes:
- N/A
---------
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Supersedes: #34242
Creates an `ActionArgumentsEditor` that implements the required logic to
have a JSON language server run when editing keybinds so that there is
auto-complete for action arguments.
This is the first time action argument schemas are required by
themselves rather than inlined in the keymap schema. Rather than add all
action schemas to the configuration options we send to the JSON LSP on
startup, this PR implements support for the
`vscode-json-language-server` extension to the LSP whereby the server
will request the client (Zed) to resolve URLs with URI schemes it does
not recognize, in our case `zed://`. This limits the impact on the size
of the configuration options to ~1KB as we send URLs for the language
server to resolve on demand rather than the schema itself. My
understanding is that this is how VSCode handles JSON schemas as well. I
plan to investigate converting the rest of our schema generation logic
to this method in a follow up PR.
Co-Authored-By: Cole <cole@zed.dev>
Release Notes:
- N/A *or* Added/Fixed/Improved ...
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>
Closes #ISSUE
Improves the behavior of the edit icon in the far left column of the
keymap UI table. It is now shown in both the selected and the hovered
row as an indicator that the row is editable in this configuration. When
hovered a row can be double clicked or the edit icon can be clicked, and
when selected it can be edited via keyboard shortcuts. Additionally, the
edit icon and all other hover tooltips will now disappear when the table
is navigated via keyboard shortcuts.
<details><summary>Video</summary>
https://github.com/user-attachments/assets/6584810f-4c6d-4e6f-bdca-25b16c920cfc
</details>
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Defines keybindings for `keymap_editor::EditBinding` and
`keymap_editor::CreateBinding`, making sure those actions are used in
tooltips.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Finn <dev@bahn.sh>
Keystroke input now gets cleared when toggling to normal search mode
Main search bar is focused when toggling to normal search mode
This also gets rid of highlight on focus from keystroke_editor because
it also matched the search bool field and was redundant
Release Notes:
- N/A
This PR improves Keystroke search by:
1. Allow searching by modifiers without additional keys.
2. Take match count into consideration when deciding if we should show
an action as a search match.
3. Take order into consideration as well.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes #ISSUE
This change applies both to the UI (we render `<null>` as muted text
instead of `zed::NoAction`) as well as how we update the keymap file
(the duplicated binding is bound to `null` instead of `"zed::NoAction"`)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Creates a new language in the languages crate for the DSL used in Zed
keybinding context. Previously, keybind context was highlighted as Rust
in the keymap UI due to the expression syntax of Rust matching that of
the context DSL, however, this had the side effect of highlighting upper
case contexts (e.g. `Editor`) however Rust types would be highlighted
based on the theme. By extracting only the necessary pieces of the Rust
language `highlights.scm`, `brackets.scm`, and `config.toml`, and
continuing to use the Rust grammar, we get a better result across
different themes
Release Notes:
- N/A *or* Added/Fixed/Improved ...
We know have the ability to filter matches in the keymap editor search
by exact keystroke matches. This allows user's to have the same behavior
as vscode when they toggle all actions with the same bindings
We also fixed a bug where conflicts weren't counted correctly when
saving a keymapping. This cause issues where warnings wouldn't appear
when they were supposed to.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes #ISSUE
This PR attempts to add workarounds for `use_key_equivalents` in the
keymap UI. First of all it makes it so that `use_key_equivalents` is
ignored when searching for a binding to replace so that replacing a
keybind with `use_key_equivalents` set to true does not result in a new
binding. Second, it attempts to infer the value of `use_key_equivalents`
off of a base binding when adding a binding by adding an optional `from`
parameter to the `KeymapUpdateOperation::Add` variant. Neither
workaround will work when the `from` binding for an add or the `target`
binding for a replace are not in the user keymap.
cc: @Anthony-Eid
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Adds keyboard navigation to the keybind edit modal. Using up/down arrows
to select the previous/next input editor, and `cmd-enter` to save +
`escape` to exit
Release Notes:
- N/A *or* Added/Fixed/Improved ...
When a key binding is deleted we keep the exact same scroll bar
position. When a keybinding is modified we select that keybinding in
it's new position and scroll to it.
I also changed save/modified keybinding to use fs.write istead of
fs.atomic_write. Atomic write was creating two FS events that some
scrollbar bugs when refreshing the keymap editor.
Co-authored-by: Ben \<ben@zed.dev\>
Release Notes:
- N/A
This PR adds a column to the keymap editor to highlight warnings as well
as add the possibility to click the edit icon there for editing the
corresponding entry in the list.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Closes #ISSUE
Changes direction on the design of the keystroke input. Due to MacOS
limitations, it was decided that the complex repeat keystroke logic
could be avoided by limiting the number of keystrokes so that accidental
repeats were less damaging to ux. This PR follows up on the design pass
in #34437 that assumed these changes would be made, hooking up actions
and greatly improving the keyboard navigability of the keystroke input.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR fixes an issue where the context menu in the keymap UI would be
immediately dismissed after being opened when using a trackpad on MacOS.
Right clicking on MacOS almost always fires a scroll event with a delta
of 0 pixels right after (which is not the case when using a mouse). The
fired scroll event caused the context menu to be removed on the next
frame. This change ensures the menu is only removed when a vertical
scroll is actually happening.
Release Notes:
- N/A
Closes #ISSUE
An idea I and @MrSubidubi came up with, to improve UX around the
keystroke input.
Currently, there's a hard tradeoff with what to focus first in the edit
keybind modal, if we focus the keystroke input, it makes keybind
modification very easy, however, if you don't want to edit a keybind,
you must use the mouse to escape the keystroke input before editing
something else - breaking keyboard navigation.
The idea in this PR is to have a dual-phased focus system for the
keystroke input. There is an outer focus that has some sort of visual
indicator to communicate it is focused (currently a border). While the
outer focus region is focused, keystrokes are not intercepted. Then
there is a keybind (currently hardcoded to `enter`) to enter the inner
focus where keystrokes are intercepted, and which must be exited using
the mouse. When the inner focus region is focused, there is a visual
indicator for the fact it is "recording" (currently a hacked together
red pulsing recording icon)
<details><summary>Video</summary>
https://github.com/user-attachments/assets/490538d0-f092-4df1-a53a-a47d7efe157b
</details>
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Makes it so that `KeymapFile::update_keybinding` treats removals of
bindings that weren't user-defined as creating a new binding to
`zed::NoAction`.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Previously, the keystroke input would be empty, even when editing an
existing binding. This meant you had to re-enter the bindings even if
you just wanted to edit the context. Now, the existing keystrokes are
rendered as a placeholder, are re-shown if newly entered keystrokes are
cleared, and will be returned from the `KeystrokeInput::keystrokes()`
method if no new keystrokes were entered.
Additionally fixed a bug in `KeymapFile::update_keybinding` where
semantically identical contexts would be treated as unequal due to
formatting differences.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Use `workspace.with_local_workspace` to ensure the keymap UI is opened
in a local workspace, even in remote. This was tested by removing the
feature flag handling code, as with the feature flag logic the action
does not appear which is likely a bug.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR ensures tooltips are dismissed/not shown once the context menu
is opened.
It also ensures the context menu is dismissed once the list is scrolled.
Release Notes:
- N/A
Closes #ISSUE
Ideally the tooltip would only appear if the context was overflowing
it's column, but for now, we just unconditionally show a tooltip so that
long contexts can be seen.
This PR also includes a change to the tooltip element, allowing for
tooltips with non-text contents which is used here for syntax
highlighting
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Co-authored-by: Anthony <anthony@zed.dev>
Closes #ISSUE
This makes it so conflicts are only shown between user bindings. User
bindings that override bindings in the Vim, Base, and Default keymaps
are not identified as conflicts
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Co-authored-by: Anthony <anthony@zed.dev>
Closes #ISSUE
Adds an action and special handling in `KeymapFile::update_keybinding`
for removals. If the binding being removed is the last in a keymap
section, the keymap section will be removed entirely instead of left
empty.
Still to do is the ability to unbind/remove non-user created bindings
such as those in the default keymap by binding them to `NoAction`,
however, this will be done in a follow up PR.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR updates the keybinding editor modal so that conflicts are
already shown in the modal itself. Notably, this does not add validation
on every keystroke, the update still has to be confirmed. However, if
only a warning is present, on the second confirm the keybind will
actually be updated.
The change also includes a slight update to the displayment of errors,
since we now differentiate between errors and warnings.
| Error | Warning |
| --- | --- |
| <img width="543" height="332" alt="warning_keybind"
src="https://github.com/user-attachments/assets/867319be-eeb9-40d7-bf32-fbd44aacf0b5"
/> | <img width="543" height="310" alt="error_keybind"
src="https://github.com/user-attachments/assets/858a6c7c-8c9a-4a90-95af-a5103125676f"
/> |
Release Notes:
- N/A
This change fixes a small issue where the right-click context menu would
not be populdated on the first right click in the keymap editor and the
selection of the corresponding entry would be slightly delayed.
Release Notes:
- N/A
Whilst working on the keymap editor, I regularly find myself
double-clicking an entry just to find that nothing happens besides
selecting the given entry. This feels really unintuitive to me. I
checked back with VSCode and they also open the modal when
double-clicking an entry in the list.
Thus, this PR enables double-clicking an entry in the list to open the
editing modal.
Release Notes:
- N/A
Closes #ISSUE
`cx.intercept_keystrokes` functions as a sibling API to
`cx.observe_keystrokes`. Under the hood the two API's are basically
identical, however, `cx.observe_keystrokes` runs _after_ all event
dispatch handling (including action dispatch) while
`cx.intercept_keystrokes` runs _before_. This allows for
`cx.stop_propagation()` calls within the `cx.intercept_keystrokes`
callback to prevent action dispatch.
The motivating example usage behind this API is also included in this
PR. It is used as part of a keystroke input component that needs to
intercept keystrokes before action dispatch to display them.
cc: @mikayla-maki
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR shows conflicts in a user's keymap editor by adding an error
background to a conflicting row and allows users to filter the keymap
editor by conflicts.
A key binding is determined to have a conflict if any other binding has
the same context and key strokes. In the future, this could be further
improved upon by normalizing bindings’ context so it's not just a string
comparison.
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <dev@bahn.sh>
Closes #ISSUE
Adds a visual indicator to the `Arguments` column of the keymap table to
help distinguish between actions that don't take arguments, and actions
that take arguments but none were provided.
Currently, the `<no arguments>` indicator is rendered only in the latter
case, when no arguments are provided to an action that could take
arguments, as the inverse results in almost every row containing the
indicator which is quite noisy.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Adds support for creating new keybinds in the keymap UI. "Create" means
two different things for existing bindings, and unbound actions.
- For existing bindings, it is essentially a duplicate + edit
- For unbound actions, it is the creation of a binding
Release Notes:
- N/A
Closes #ISSUE
Adds a very simple editor for editing action input to the edit keybind
modal. No auto-complete yet.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Implements a very basic completion provider that is attached to the
context editor in the keybind editing modal.
The context identifiers used for completions are scraped from the
default, vim, and base keymaps on demand.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Adds a context input to the keybind edit modal. Also fixes some bugs in
the keymap update function to handle context changes gracefully. The
current keybind update strategy implemented in this PR is
* when the context doesn't change, just update the binding in place
* when the context changes, but the binding is the only binding in the
keymap section, update the binding _and_ context in place
* when the context changes, and the binding is _not_ the only binding in
the keymap section, remove the existing binding and create a new section
with the update context and binding so as to avoid impacting other
bindings
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Uses Rust for syntax highlighting of context in the keymap editor.
Future pass will improve color choice to make colors less abrasive
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Show the documentation for an action when hovered. As a bonus, also show
the humanized command palette name!
Release Notes:
- N/A *or* Added/Fixed/Improved ...
