It feels natural and native — more like the Sublime/Emacs/IntelliJ Vim emulators than the Visual Studio Code one, speed-wise.
The features they have implemented are easily discoverable because there are as-you-type hints in the new “bottom bar” (which also shows the mode).
Some things that don't appear in the hints are also working, including 'o' in Visual mode (which skips to the “other” end of highlighted text to jump from start to finish or vice-versa).
Dunno about this version of Xcode but on Mac I tend to map Caps Lock to Ctrl so either in Vim or an emulation layer I can just use Ctrl+[ which is the same thing as <ESC> and doesn't require a new mapping, which can differ as to the if and how depending on emulation layer
I did try that way but unfortunately jj has just become muscle memory and I'm finding myself trying to trigger escape with it. Hopefully I can find a solution or Apple release some sort of configuration file.
Heh, I uses a similar keybinding, "jk", for escape that I can't get out of muscle memory. Works well enough in vanilla Vim and Emacs, but causes much pain in other Vim bindings, namely IntelliJ.
Even if you do get it to work, you usually have to wait for the keypress timeout to detect the command. The sequence is something like:
- Enter insert mode.
- Press "j"
- Nothing appears until 40 ms later, when keypress timeout passes and the logic falls back to insert a "j" character.
I think Vim and Emacs use a fancier undo-mechanism, where they always insert the "j" and then delete the "j" if a command completes before the timeout in order to hide the latency.
I use the same configuration for "jk" on both MacVim and AppCode + IdeaVim, and it has always worked for me:
inoremap jk <esc>
I just did an experiment, if I type "j" and pause, I can see "j" appearing and then almost immediately disappears, slight pause and then appear again. Is that the problem you are facing? But if I type fast (e.g "joking"), it doesn't seem to cause a visible delay.
I have absolutely no dog in this fight other than to express how weird it feels culturally. OS X came with emacs key bindings built in system-wide for anything using the native UI frameworks from at least 10.0, I assume back into NeXT roots. Seeing a dedicated vim mode in Apple’s developer tools 20 years later is quite a thing.
Addendum: I have only one dog in this fight, which is that I know I can ^T to transpose with emacs bindings almost anywhere on a Mac and, having never learned either emacs or vim that command has been welcome a lot.
How's the registers and macro support? Did they implement base vim text objects or add in those popular surround ones? How does "." interact with macros and movement? Vim regex, js regex, something else? Do they support things like ":%g/foo/d" or ":%v/bar/d"? How about modifiers after a search like "/foo/e+2"? Does cmd+w act as a prefix for pane navigation?
These are things that vim modes often get wrong and that I find myself missing when I use them.
18 comments
[ 0.20 ms ] story [ 57.6 ms ] threadThen you can enable Vim mode at Preferences → Text Editing → Editing → Enable Vim key bindings.
It feels fast! (Although not feature-complete just yet. Command mode and Visual Line mode are absent at the moment.)
As in Vim Mode or Xcode in General? Is it VSCode Fast or Sublime Fast?
It feels natural and native — more like the Sublime/Emacs/IntelliJ Vim emulators than the Visual Studio Code one, speed-wise.
The features they have implemented are easily discoverable because there are as-you-type hints in the new “bottom bar” (which also shows the mode).
Some things that don't appear in the hints are also working, including 'o' in Visual mode (which skips to the “other” end of highlighted text to jump from start to finish or vice-versa).
Even if you do get it to work, you usually have to wait for the keypress timeout to detect the command. The sequence is something like:
- Enter insert mode.
- Press "j"
- Nothing appears until 40 ms later, when keypress timeout passes and the logic falls back to insert a "j" character.
I think Vim and Emacs use a fancier undo-mechanism, where they always insert the "j" and then delete the "j" if a command completes before the timeout in order to hide the latency.
inoremap jk <esc>
I just did an experiment, if I type "j" and pause, I can see "j" appearing and then almost immediately disappears, slight pause and then appear again. Is that the problem you are facing? But if I type fast (e.g "joking"), it doesn't seem to cause a visible delay.
These are things that vim modes often get wrong and that I find myself missing when I use them.
XVim2 is getting more unstable for each new iteration of XCode. I am putting my trust in Apple for this one.