Vim mode multi-key mappings

[cjfuller]

Is your feature request related to a problem? Please describe.
I normally remap keys in vim or vim-mode in other editors so that I can use jk in insert mode to exit insert mode instead of escape, but I don't see any way to do this from the docs, and it did not work to try to hack it with:

    {
        "context": "Editor && vim_mode == insert && vim_operator == j",
        "bindings": {
            "k": "vim::NormalBefore"
        }
    }

Describe the solution you'd like
I'd like to somehow be able to bind j then k to Escape in insert mode.

Describe alternatives you've considered
I tried the config hack above to no avail, and I also considered retraining to ctrl-c, which is the default alternate binding, but I'd rather be able to use something on the home row.

Mockup
For example, I'd love to be able to write the following:

    {
        "context": "Editor && vim_mode == insert",
        "bindings": {
            "jk": "vim::NormalBefore"
        }
    }

[albertorestifo]

Vim mode without the ability to remap multi-key bindings is very limiting indeed.

Another use-case: In normal mode, I want to remap gd to the Go To Definition command.

[caliguIa]

@albertorestifo you may have already figured this out but you can achieve go to definition already with the following snippet:

[
    {
        "context": "Editor && vim_operator == g",
        "bindings": {
            "d": "editor::GoToDefinition"
        }
    }
]

[mauscoelho]

The vim_operator == g but when trying to do something like vim_operator == [ it does not work, is it a special character? How would it translate?

Not working example:

  {
    "context": "Editor && vim_operator == [",
    "bindings": {
      "d": "editor::GoToPrevDiagnostic"      
    }
  }

[ConradIrwin]

Multi-character key-bindings should mostly "just work" if you separate keys with a space in the key.

The main thing I know is broken is that you can't (in insert mode) map j k to escape, because the way the keybinding system currently works you can't then type a j. I do want to try and fix that.

You should not need to specify the first key in the context for the second. This is only required in the builtin vim.json because we want to support c <motion> and vim special cases c to be the "entire line" motion if the operator is c (or d if the operator is d, etc.).

That said, it is quite fiddly to get the context correct at the moment (which I'd like to work on) but in the meantime:

The main context for things is:

{[{
  "context": "Editor && VimControl && !VimWaiting && !menu"
  "bindings": [
   // put key-bindings here if you want them to work in normal & visual mode
   "c d": "editor::Change
  ]
}, {
  "context": "Editor && vim_mode == normal && (vim_operator == none || vim_operator == n) && !VimWaiting",
   "bindings": [
    // put key-bindings here if you want them to work only in normal mode
   ]
}, {
  "context": "Editor && vim_mode == visual && !VimWaiting && !VimObject"
  "bindings": [
   // visual, visual line & visual block modes
  ],
}, {
    "context": "Editor && vim_mode == insert",
    "bindings": [
     // insert mode *CAVEAT* about using printable characters above.
   ],
]}

Also please do open issues if there are common plugins you use that define keybindings you want (or just keybindings for vim stuff that we're missing) – ideally you don't have to make too many changes to the file!

[washanhanzi]

This worked for jk:

  {
    "context": "Editor && vim_mode == insert",
    "bindings": {
      "j k": "vim::NormalBefore"
    }
  }

but if you want to type j, it's jj.

[mauscoelho]

For reference this works for me:

{
    "context": "Editor && vim_mode == normal && (vim_operator == none || vim_operator == n) && !VimWaiting",
    "bindings": {
      // put key-bindings here if you want them to work only in normal mode
      "g d": "editor::GoToDefinition",
      "g r": "editor::FindAllReferences",
      "[ d": "editor::GoToPrevDiagnostic",
      "] d": "editor::GoToDiagnostic"
    }
  }

[ConradIrwin]

Nice! I like [ d and ] d. I recently added g A for "find all references" to the default vim keybindings (although I think it's unlikely that vim's g r support is coming anytime soon, I wanted to not overwrite any defaults).

[calebmeyer]

I added a bunch of keybinds, and they're all working (amazingly fast and well compared to vs code!). My only issue is what @washanhanzi said, I now have to double type js.

My new keybinds!

[
    {
        // normal & visual mode
        "context": "Editor && VimControl && !VimWaiting && !menu",
        "bindings": {}
    },
    {
        // normal mode
        "context": "Editor && vim_mode == normal && (vim_operator == none || vim_operator == n) && !VimWaiting",
        "bindings": {
            "g d": "editor::GoToDefinition",
            "space space": "command_palette::Toggle",
            "space b d": "pane::CloseActiveItem",
            "space b n": "pane::ActivateNextItem",
            "space b p": "pane::ActivatePrevItem",
            "space c l": "editor::ToggleComments",
            "space f s": "workspace::Save",
            "space f S": "workspace::SaveAll",
            "space j f": "project_symbols::Toggle", // not quite right, since it's full project
            "space p s": "TODO", // go to project
            "space q a": "pane::CloseAllItems",
            "space q o": "pane::CloseInactiveItems",
            "space q w": "workspace::CloseWindow",
            "space q q": "zed::Quit",
            "space s d": "pane::SplitDown",
            "space s l": "pane::SplitLeft",
            "space s r": "pane::SplitRight",
            "space s u": "pane::SplitUp",
            "space t i": "editor::ToggleInlayHints",
            "space t n": "workspace::NewTerminal",
            "space t t": "terminal_panel::ToggleFocus",
            "space w d": [
                "workspace::ActivatePaneInDirection",
                "Down"
            ],
            "space w l": [
                "workspace::ActivatePaneInDirection",
                "Left"
            ],
            "space w r": [
                "workspace::ActivatePaneInDirection",
                "Right"
            ],
            "space w u": [
                "workspace::ActivatePaneInDirection",
                "Up"
            ],
            "space w w": "workspace::ActivateNextPane",
        }
    },
    {
        // visual, visual line & visual block modes
        "context": "Editor && vim_mode == visual && !VimWaiting && !VimObject",
        "bindings": {},
    },
    {
        // insert mode
        "context": "Editor && vim_mode == insert",
        "bindings": {
            "j k": "vim::NormalBefore"
        }
    }
]

[mauscoelho]

"space j f": "project_symbols::Toggle", // not quite right, since it's full project

You can use cmd-shift-O for buffer symbols @calebmeyer. I could not find the action name for it as well

[JosephTLyons]

"space j f": "project_symbols::Toggle", // not quite right, since it's full project

You can use cmd-shift-O for buffer symbols @calebmeyer. I could not find the action name for it as well

We call buffer symbols an outline, so the action name for this would be outline: toggle.

[ConradIrwin]

@calebmeyer thanks for sharing these!

I'm going to add outline::Toggle and project_symbols::Toggle to the default map. Vim doesn't use g s for anything useful ("sleep for count seconds??!") and doesn't use g S at all.

I've already begun repurposing the g namespace for zed specific stuff, so that would give us:

      "g d": "editor::GoToDefinition",  // in vim "go to local declaration" 
      "g shift-d": "editor::GoToTypeDefinition", // in vim "go to global declaration"
      "g .": "editor::ToggleCodeActions", // zed specific
      "g shift-a": "editor::FindAllReferences", // zed specific
      "g s": "outline::Toggle",  // zed specific
      "g shift-s": "project_symbols::Toggle",  // zed specific
      // ... 
      "c d": "editor::Rename", // zed specific

Also a quick note that in your file "space f S" needs to be spelt "space f shift-s" for zed's keyboard handler to understand it.

[justDeeevin]

In the preview version of Zed, doing something like this:

    {
        "context": "Editor && vim_mode == insert",
        "bindings": {
            "j k": "vim::NormalBefore",
            "k j": "vim::NormalBefore"
        }
    },

Actually ends up typing k or j in the file before executing the command. So I have to get rid of the extra letter every time I use the keybind. Not fun.

[d1y]

In the preview version of Zed, doing something like this:

    {
        "context": "Editor && vim_mode == insert",
        "bindings": {
            "j k": "vim::NormalBefore",
            "k j": "vim::NormalBefore"
        }
    },

Actually ends up typing k or j in the file before executing the command. So I have to get rid of the extra letter every time I use the keybind. Not fun.

Same problem, in zed-preview

[ConradIrwin]

Thanks for the report on Preview. I'll at least revert to the gpui1 behavior, but I wonder if I can figure out how to teach the input handler about pending keys so we can have our cake and eat it to.

[JosephTLyons]

This should be shipped in v0.119.16-pre.

[ConradIrwin]

I've added support for jk in insert-mode in the latest nightly:

• You'll need to set up bindings like:

[
  {
    "context": "Editor && vim_mode == insert",
    "bindings": {
      "j k": "vim::NormalBefore"
    }
  }
]

• Once you have that, typing jk in insert mode will act like <esc>
• If you type j and then wait 1000ms, it will type j
• If you type j and then any other key, it will type the j just before the next key.

This works similarly in normal mode, for example if you have:

[
  {
    "bindings": {
      "shift-escape": null,
      "ctrl-enter": "menu::ShowContextMenu",
      ", w": "workspace::Save"
    }
  }
]

• If you type ,w then it will save.
• If you type , and then wait 1000ms it will do the default (repeat the most recent tf command in reverse).
• If you type , and then another key, it will do the default just before the next key

With that done, I think we can close this out.

There is a related feature request to support mapping from one sequence of keys to another sequence of keys, but we should track that separately!

[LORE-D-NATO]

I have kj set as my escape binding and it makes exiting insert mode after typing a k sort of awkward with the 1000ms delay. Shouldn't kk type a k and then wait for another input?

[ConradIrwin]

@LORE-D-NATO If you just keep typing it should do the right thing, for example if you type koala without pausing after the k it should insert the k correctly. Please let me know if you're not observing that!

There does seem to be a small bug right now where if you type kk it doesn't type the first k until the timeout has passed either; I'll take a look at that.

[LORE-D-NATO]

@ConradIrwin Yes, typing a second letter other than k works as intended. The bug when typing kk is what I was referencing.

[jparr721]

I didn't want to resurrect this for another individual issue, so let me know if this is the inappropriate place to put this, but I am having trouble getting certain chained functionality similar to above, specifically ciw or "change inner word". I grabbed a keymap a year or so ago and have been using that, but the one critical piece keeping me in regular vim/vscode is the ability to use the c commands as I expect, and most specifically ciw. Given the following config, I am trying to understand how I might implement this? I have been googling this issue for months to avoid adding yet-another one-off request, but I am truly stumped as to how to do this with the present functionality. Is there any way I can get this to work as I expect? You can see my half-hearted attempt to add the feature below, but it's definitely not right. If there's docs I'm happy to read those. I've been using the provided bindings, but I am not sure how I would replace the current word.

Something like this:

"c i w": "editor::DeleteToNextWordEnd",

Works great, but something like this:

      "c i w": [
        "editor::MoveToPreviousWordStart",
        "editor::DeleteToNextWordStart",
        "vim::SwitchMode",
        "Insert"
      ],

does not. Am I doing something horribly wrong here?

[ConradIrwin]

@jparr721 There should be (but I don't think there is) an issue for what you're talking about, which is being able to bind one keystroke to many actions (or more keystrokes). It is in the backlog of the Vim channel notes https://zed.dev/channel/vim-393, but would be good to have tracked on Github too.

That said, we do already support things like ciw. If you're looking at the binding file, you can see that c pushes the "Change" operator: https://github.com/zed-industries/zed/blob/main/assets/keymaps/vim.json#L296

Then i pushes the around operator: https://github.com/zed-industries/zed/blob/main/assets/keymaps/vim.json#L459, and finally w selects the word object: https://github.com/zed-industries/zed/blob/main/assets/keymaps/vim.json#L376.

Its a little convoluted, but that way we don't have to have separate bindings for each action and object.

In order for any of this work you do have to use Zed in Vim mode "vim_mode": true in your settings in addition to having the keymap; as that enables all the bookkeeping machinery. (Also if you copied the keymap a year ago, I'd suggest deleting it and starting afresh!)

[jparr721]

The new keymaps worked like a charm! Thanks for the followup here.

[eneiford]

is it possible to override the 1000ms delay time waiting on a second keypress (especially for a specific context)? using jk is really awkward with the 1000ms delay when actually typing a "j" or "k". For example, i would normally escape from visual mode with jk, but i also need to be able to navigate lines inside visual mode, so I set the delay interval very small to enable jk escape while keeping the ability to navigate visual blocks

[ConradIrwin]

@eneiford not right now, but if you’d like to pair with me on building it, feel free to book time at https://calendly.com/conradirwin/pairing.

We should just be able to add a new setting for this.

[mre]

@ConradIrwin, I have a similar (but slightly different) use-case for reducing the 1000ms delay time.
(Did not want to open a new issue right away.)

I normally use cmd-j and cmd-k to switch between panes.

"bindings": {
    "cmd-j": "pane::ActivatePrevItem",
    "cmd-k": "pane::ActivateNextItem",
}

While cmd-j works as expected, cmd-k is slow because it waits for a second key press. I think if I set the delay time to 0, it would be instant. Alternatively, is there a way to disable multi-key mappings and/or set all the other cmd-k X mappings to null?

My current workaround is

"bindings": {
    "cmd-[": "pane::ActivatePrevItem",
    "cmd-]": "pane::ActivateNextItem",
}

[ConradIrwin]

There's no currently easy way to do this unfortunately.

A few things we could consider improving on the Zed side that might help:

• Moving all the cmd-k X bindings to a top-level context so that user-bindings at a lower-level context would take priority
• Have a way to give user-bindings precedence over internal bindings
• Make the delay so much shorter that you don't care anymore

I think 3. should be easy, and is probably a good place to start; but 2. would be nice to have too. (1. seems further away from feasible)

[mre]

Yes, each of these solutions would work fine for me.
As this issue is closed, would you like me to create a new issue mentioning your points?

[ConradIrwin]

Please do!

Or if you'd like to just fix them PRs are also welcome – if you'd like to work together you can book time here: https://calendly.com/conradirwin/pairing