I find this a bit silly. In which way is vim editing more keyboard centric than VSCode’s own shortcuts? To be honest I think current modern cua mode editors with their multi cursor, mark next occurrence, select inside, etc. Are kind of crossing keyboard usage effectiveness when compared to the two old editors.
I am only missing a way to toggle between vertical and horizontal terminal split. Other than that, I don’t use the mouse at all.
Why do people equate keyboard-centric to vim movement?
A big component is arrow keys. Using literal arrow keys sucks, as they are far from home row, but account for a big chunk of keystrokes. This can be solved by:
Is that really that big of a deal compared to long keybond sequences that need to be typed repeatedly?
What about escape? It is also outside the home row.
Feels like a meme without really ever asking these questions.
In my experience, yes it is. It is much faster and much lower mental effort to type something without moving hands. Reaching for arrow keys it not that much worse better than reaching for mouse. Again for me, even godawful Emacs keybindngs were a marked improvement over arrows.
It is not worse than reaching the mouse, it is leaps and bounds less disruptive for typing than reaching the mouse. The arrow keys are always in the same relative position, and closer, to the letters than the mouse. And place your hand with the keys home, end,pgup, pgdn, insert, which are central to cursos movement.
Why is moving the right hand (most people most agile hand) to the arrows such a deal breaker to com users, but moving the left hand to escape is fine? What exactly is the difference?
I don’t need to move my hand to reach escape key – just extend the hand. The wrist stays where it is. To move to the arrow keys, I need to rellocate the whole hand.
I totally can see how having to reach for arrow keys is not a big deal for some folks. However, the bit about “What exactly is the difference?” I don’t get. Obviously there’s a huge difference between just extending the finger versus moving the whole hand?
And, to clarify, on the layout I use, escape is capslock, arrows are ijkl, home end pgup/down are uo<>.
But yeah, Toggle Editor Group Sizes is close to what I want, thanks a bunch! Is there a way to make it work with explorer as well? So that it automatically shrinks/expands based on whether it is focused?
Hmmm, I don’t know. But you can go into zen mode where it auto hides, and then you can make it show up while you interact with it and then it auto hides when you give focus back to the buffer?
I submitted under the emacs tag because, as the body of the post goes in to, the inspiration for my VSCode configuration came almost entirely from Spacemacs and Doom Emacs. I’m certainly open to suggestions on the tags and/or title of the post :)
Removing the tabs is kind of pointless since that “file bar” (which contains the split editor icon) cannot be removed. That vertical space is still “lost” even without tabs.
It saves some space if you have "breadcrumbs.enabled": true,. Though, the primary motivation here is not as much saving pixels, as just getting rid of inefficient way to navigate.
Vim emulation is just that - Vim-like keybindings. It implements most of the functionality of a few plugins (surround, sneak, etc) but is otherwise fake Vim.
The Neovim plugin runs real actual Neovim backend and renders it in the VSCode window. This is possible with Neovim because it separates the frontend and backend for reasons like this. Because it’s real Neovim, all your plugins just work. It’s so much better.
I find this a bit silly. In which way is vim editing more keyboard centric than VSCode’s own shortcuts? To be honest I think current modern cua mode editors with their multi cursor, mark next occurrence, select inside, etc. Are kind of crossing keyboard usage effectiveness when compared to the two old editors. I am only missing a way to toggle between vertical and horizontal terminal split. Other than that, I don’t use the mouse at all.
Why do people equate keyboard-centric to vim movement?
A big component is arrow keys. Using literal arrow keys sucks, as they are far from home row, but account for a big chunk of keystrokes. This can be solved by:
Is that really that big of a deal compared to long keybond sequences that need to be typed repeatedly? What about escape? It is also outside the home row.
Feels like a meme without really ever asking these questions.
In my experience, yes it is. It is much faster and much lower mental effort to type something without moving hands. Reaching for arrow keys it not that much
worsebetter than reaching for mouse. Again for me, even godawful Emacs keybindngs were a marked improvement over arrows.Escape is on CapsLock of course!
It is not worse than reaching the mouse, it is leaps and bounds less disruptive for typing than reaching the mouse. The arrow keys are always in the same relative position, and closer, to the letters than the mouse. And place your hand with the keys home, end,pgup, pgdn, insert, which are central to cursos movement.
Why is moving the right hand (most people most agile hand) to the arrows such a deal breaker to com users, but moving the left hand to escape is fine? What exactly is the difference?
I don’t need to move my hand to reach escape key – just extend the hand. The wrist stays where it is. To move to the arrow keys, I need to rellocate the whole hand.
I totally can see how having to reach for arrow keys is not a big deal for some folks. However, the bit about “What exactly is the difference?” I don’t get. Obviously there’s a huge difference between just extending the finger versus moving the whole hand?
And, to clarify, on the layout I use, escape is capslock, arrows are ijkl, home end pgup/down are uo<>.
I, like many vim users, has a map for escape for this reason. I use
jjfrom normal mode.How do you escape insert mode?
I mistyped. Should have read “
jjfrom insert mode”.Yes, but only if you’re arrow keys are in a sucky location. There’s little reason to use hjkl if arrow keys are in an ideal location.
I realize alternative keyboards arent as affordable or accessible though.
Couple of useful extensions:
Things I still miss:
Try double clicking one of your tabs (after splitting to 2+ tabs)
I don’t have tabs 🤣🤣🤣
But yeah, Toggle Editor Group Sizes is close to what I want, thanks a bunch! Is there a way to make it work with explorer as well? So that it automatically shrinks/expands based on whether it is focused?
I’m glad it was useful!
Hmmm, I don’t know. But you can go into zen mode where it auto hides, and then you can make it show up while you interact with it and then it auto hides when you give focus back to the buffer?
I submitted under the emacs tag because, as the body of the post goes in to, the inspiration for my VSCode configuration came almost entirely from Spacemacs and Doom Emacs. I’m certainly open to suggestions on the tags and/or title of the post :)
Removing the tabs is kind of pointless since that “file bar” (which contains the split editor icon) cannot be removed. That vertical space is still “lost” even without tabs.
It saves some space if you have
"breadcrumbs.enabled": true,. Though, the primary motivation here is not as much saving pixels, as just getting rid of inefficient way to navigate.Except I want JUST the breadcrumbs and no tabs! So, I can’t turn tabs off without losing the breadcrumbs :(
https://github.com/microsoft/vscode/issues/95796#issuecomment-1085115994
Heh, familiar issue!
The Neovim integration is far superior.
Vim emulation is just that - Vim-like keybindings. It implements most of the functionality of a few plugins (surround, sneak, etc) but is otherwise fake Vim.
The Neovim plugin runs real actual Neovim backend and renders it in the VSCode window. This is possible with Neovim because it separates the frontend and backend for reasons like this. Because it’s real Neovim, all your plugins just work. It’s so much better.