Learn Vim (the Smart Way): a book to learn the good parts of Vim(github.com)
github.com
Learn Vim (the Smart Way): a book to learn the good parts of Vim
https://github.com/iggredible/Learn-Vim
133 comments
The name could be a reference to learnvimscriptthehardway.stevelosh.com, which is an amazing resource.
Ah Vim, one of the root causes of my imposter syndrome. (The others are CSS Grid, and Kubernetes)
Kubernetes very easy to use, worth learning imho. One hour's worth effort yields great advantage for work.
Vim not worth learning to use as adult. Time too valuable. Takes too long to become extension of body. Best learned as child/teenager. Time worthless then. Maybe if you can learn it fast. Took me years of teenage to get unthinking proficiency.
Vim not worth learning to use as adult. Time too valuable. Takes too long to become extension of body. Best learned as child/teenager. Time worthless then. Maybe if you can learn it fast. Took me years of teenage to get unthinking proficiency.
I disagree, I learned Vim in my 40's after decades on emacs. For a month it was awful, but I have since recouped the time lost many times over. Other developers on my team went through the same.
Very interesting. Good to hear.
I also disagree. I learnt vim in my 50's and am using it daily now. In fact, I find that I use jk (which I've muscle-memoried to 'ESC' in nearly every application). Sometimes it doesn't work :-). But it did when I went on to learn org-mode during Covid-19 by parachuting with doom-emacs. There is no need to avoid learning the good stuff.
Picked up my vi chops at 38.
The learning curve is admittedly steep, but you get past the curve pretty quick.
The learning curve is admittedly steep, but you get past the curve pretty quick.
Ha, how about that. By the way, you might enjoy Lord of Light by Roger Zelazny. You're the hero of the story.
My parents named me after the main character, so you won't be surprised to hear that I've read it a few times, over the years.
Haha, figured as much. Well, good character to be named after.
Add real-time safety critical systems, realistic 3D rendering, reverse engineering, quines, Paxos, deep learning, production-quality Haskell, and Boston Dynamics.
- Realistic 3D rendering: start with Ray-Tracing. It's fun!
- Quines: those are dark magic, but not very useful.
- Deep learning: A fancy word for multi-layerd neural network. Interesting concept, but nothing scary.
- Production-quality Haskell: You would be surprised how low-quality some production codes are.
- Boston dynamics: that happens when a group of smart people focus on a subject with no hinderance.
- Quines: those are dark magic, but not very useful.
- Deep learning: A fancy word for multi-layerd neural network. Interesting concept, but nothing scary.
- Production-quality Haskell: You would be surprised how low-quality some production codes are.
- Boston dynamics: that happens when a group of smart people focus on a subject with no hinderance.
Quines almost always have exactly the same structure:
- Header (code)
- Data blob (string variable) that encodes the header and footer
- Footer (code)
Since the data blob is a variable, the header/footer simply decode the data blob and write out the decoded header, original blob, and decoded footer.
- Header (code)
- Data blob (string variable) that encodes the header and footer
- Footer (code)
Since the data blob is a variable, the header/footer simply decode the data blob and write out the decoded header, original blob, and decoded footer.
Over engineering
FZF(and its vim plugins) really leveled up the game for Vim.
I 100% agree with this. Using fzf.vim for finding/opening files, searching across files, searching within a file, etc had a definite positive impact on my productivity. For reference, I was previously using netrw.
fzf is also really useful outside of Vim. I like to use it to fuzzy find git branches among other things.
fzf is also really useful outside of Vim. I like to use it to fuzzy find git branches among other things.
As well as neovim and LSP.
I've had neovim installed for a while but really haven't found anything that would make me want to switch. Sure, I get the meta Neovim competition driving improvements in vim but I'd like to know what I'm missing out on.
It's been quite a bit faster than Vim, but perhaps Vim has caught up. I haven't checked it out in a while. Neovim supported asynchronous updates well before Vim, so also much more responsive until recently.
In any case my config is compatible with both and I can use them interchangeably.
In any case my config is compatible with both and I can use them interchangeably.
As it is now, it seems to be a partial book.
Two things that helped me more than anything with "learning" vim and or ever wanting to use it:
1. Remap your "capslock" key to "escape." Vi was written using an ADM-3A terminal and its keyboard, which you can see here: https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys has the escape-key in a sane place. On modern keyboards, if you can, remap "capslock" to "escape" when pressed alone, and "ctrl" when pressed with another key.
2. Make your leader key something easy like the comma character "," E.g. to make a horizontal split, I press (not including quotation marks) ",h" or ",v" to make a vertical one.
Once I did those two things it all made so much more sense... It's also great because most editors these days support vim bindings, so even if you don't want to use vim you can still benefit from its really-awsome-once-you-figure-it-out UX.
1. Remap your "capslock" key to "escape." Vi was written using an ADM-3A terminal and its keyboard, which you can see here: https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys has the escape-key in a sane place. On modern keyboards, if you can, remap "capslock" to "escape" when pressed alone, and "ctrl" when pressed with another key.
2. Make your leader key something easy like the comma character "," E.g. to make a horizontal split, I press (not including quotation marks) ",h" or ",v" to make a vertical one.
Once I did those two things it all made so much more sense... It's also great because most editors these days support vim bindings, so even if you don't want to use vim you can still benefit from its really-awsome-once-you-figure-it-out UX.
When I was first learning Vim I remapped caps lock to escape, and it was a huge improvement. But as I became more comfortable in Vim I realized I was using the control key a lot.
I've since remapped caps lock to control, and use ctrl-[ as escape (this is default behavior). I find having an easily accesible control key is very useful, even outside Vim. You can see in your link that it is actually the control key that used to be in the position we now put the caps lock key.
It does seem like remapping caps lock to escape when pressed alone and control when pressed with another key would be nice, but that wasn't an option for me (on wayland) as far as I know.
I bring this up only because there was a week or two transition period when I made this change, and I probably would have been better off if I had mapped caps lock to control from the start.
I've since remapped caps lock to control, and use ctrl-[ as escape (this is default behavior). I find having an easily accesible control key is very useful, even outside Vim. You can see in your link that it is actually the control key that used to be in the position we now put the caps lock key.
It does seem like remapping caps lock to escape when pressed alone and control when pressed with another key would be nice, but that wasn't an option for me (on wayland) as far as I know.
I bring this up only because there was a week or two transition period when I made this change, and I probably would have been better off if I had mapped caps lock to control from the start.
On Linux and Mac it’s possible to have caps be escape when pressed alone or control when pressed with another key. On Linux the software is called xcape. :)
There's also caps2esc, which works even on the tty. https://gitlab.com/interception/linux/plugins/caps2esc
[deleted]
On Mac, there is Karabiner-Elements.
https://karabiner-elements.pqrs.org/
https://karabiner-elements.pqrs.org/
Here's a Karabiner tutorial that worked for me: https://medium.com/@pechyonkin/how-to-map-capslock-to-contro...
I recently learned this trick since getting a new MacBook pro with the touch bar esc key. I couldn't stand the lack of travel and didn't want to remap keys, now I use the ctrl-[ combo on all keyboards out of habit
Relevant to the other conversations going on in this thread, how simple is it to re-map that ctrl-[ to work globally? I'm assuming I'd have to install something for this. I am also using a Mac and use the caps-lock-as-escape to, say, close my spotlight search bar after activating it using the command+space shortcut.
In theory at least Ctrl-[ "is" Escape and is already universal. Reason: simultaneously pressing Ctrl is the ASCII -> ASCII mathematical transformation "subtract 0x40" for keys that represent a single ASCII character. So for example Ctrl-M is 0x4d - 0x40 = 0x0a. M is 0x4d ASCII and carriage return (aka '\r', aka Enter) is 0x0d ASCII. Ctrl-M is, or at least should be, universally the same as Enter. Similarly '[' is 0x5b in ASCII, so Ctrl-'[' is 0x1b in ASCII which is the ASCII code for, you guessed it I hope, Escape. Phew that was tough on a phone.
that's funny - I'm currently trying the jj remap, but I keep going for esc out of habit
This is what I do on both Linux and macOS. I like remapping Caps Lock to Ctrl/Command because it's the UNIX-style key layout I'm used to on the old IBM Model M keyboards, and my left and right pinky fingers are used to the Ctrl-[ combination, it's burned into muscle memory.
I remap my right Alt to Ctrl. The best thing I have ever done with regards to ergonomics. It works wonders in all softwares, not only vim. It's much more convenient to press with the thumb than CapsLock is with the pinkie.
[deleted]
Die hard vimeleon here.
IMHO chording the 'j' and 'k' keys simultaneously [1] is a severely underutilized solution for escape.
Try it. You'll love it.
If you're going to rebind capslock to something — and this is particularly true if you're on macOS — rebind it to backspace. Capslock escape isn't useful outside of Vim. Backspace is useful everywhere, including inside Vim.
[1] https://github.com/kana/vim-arpeggio
IMHO chording the 'j' and 'k' keys simultaneously [1] is a severely underutilized solution for escape.
Try it. You'll love it.
If you're going to rebind capslock to something — and this is particularly true if you're on macOS — rebind it to backspace. Capslock escape isn't useful outside of Vim. Backspace is useful everywhere, including inside Vim.
[1] https://github.com/kana/vim-arpeggio
> If you're going to rebind capslock to something — and this is particularly true if you're on macOS — rebind it to backspace.
No, rebind it to Compose. Makes life a lot easier.
https://en.wikipedia.org/wiki/Compose_key
No, rebind it to Compose. Makes life a lot easier.
https://en.wikipedia.org/wiki/Compose_key
That's interesting. I'm a bit spoiled by primarily using Vim to write code and prosé in American English. Vim's digraph feature (Ctrl-K by default) has handled unicode char input nicely enough for me, but I wonder if the compose key could be of use when writing text in Japanese for example.
I actually meant to do it systemwide, for when you're writing or googling things not in English, or when you want to write a fancy ⅝. The day I have to start putting diacritics into computer code is the day I quit programming:)
I think it's no good for Japanese, but I know very little about Japanese input. Romanji is still Japanese, right?
I think it's no good for Japanese, but I know very little about Japanese input. Romanji is still Japanese, right?
Now that's an idea. Haskellers routinely use x' as a variable name, but ẋ and x̃ are also valid ones!
I use option-e e to insert é, option-n n to insert ñ, etc. I noticed this while pressing option in the Keyboard Viewer.
The problem with your jk solution is that it doesn’t work in other Vi-like interfaces such as those provided by readline or shells.
Also ctrl-h is backspace so mapping caps to ctrl gives you a convenient escape and backspace shortcut.
(It also gives you a heap more terminal shortcuts but that’s another story).
Also ctrl-h is backspace so mapping caps to ctrl gives you a convenient escape and backspace shortcut.
(It also gives you a heap more terminal shortcuts but that’s another story).
I sort of got obsessed with the aforementioned ADM-3A keyboard layout, so I got myself a keyboard with unofficial QMK[1] support, and with that I remapped my keys as follows:
- Tab functions as Escape, Caps Lock as Control. That makes both keys well in reach of my pinky, and I can still use ^I for Tab.
- I remapped symbols according to an illustration[2] of the ADM-3A layout on Wikimedia (with some small adjustments). Aside from not having to press shift to enter command-mode, this also has the advantage of being more similar to the German layout, which I often have to use.
- And finally I changed ^H and ^I to work outside of terminal emulators (i.e. they send keycodes for Backspace and Tab, respectively).
While this layout is somewhat inconvenient for navigating CUA-derived UIs, I've found it great for use with vi clones and other TUIs.
[1] https://qmk.fm/
[2] https://upload.wikimedia.org/wikipedia/commons/a/a0/KB_Termi...
- Tab functions as Escape, Caps Lock as Control. That makes both keys well in reach of my pinky, and I can still use ^I for Tab.
- I remapped symbols according to an illustration[2] of the ADM-3A layout on Wikimedia (with some small adjustments). Aside from not having to press shift to enter command-mode, this also has the advantage of being more similar to the German layout, which I often have to use.
- And finally I changed ^H and ^I to work outside of terminal emulators (i.e. they send keycodes for Backspace and Tab, respectively).
While this layout is somewhat inconvenient for navigating CUA-derived UIs, I've found it great for use with vi clones and other TUIs.
[1] https://qmk.fm/
[2] https://upload.wikimedia.org/wikipedia/commons/a/a0/KB_Termi...
I also remap shift-tab to tab in Vim, and then somehow manage to live without being able to actually shift-tab in Vim. I should probably think of some solution for that at some point...
I'm personally a fan of remapping jk or jj to esc, there barely any instances in the english language where you would use those two letters together, and it means you can leave insert mode whilst barely moving your hands :D
My issue with this is that it causes a delay with every single j
that is entered. Only a visual delay that freezes the cursor and
then lets it jump by two characters, but irritating for me
regardless.
Otherwise it's very practical though.
Otherwise it's very practical though.
I thought I was the only one. That visual delay made me nuts.
I don’t use it either but I think you can change the delay. Check out :h 'ttimeout' and :h 'ttimeoutlen'
Haven’t touched that part of my vimrc in years
Haven’t touched that part of my vimrc in years
Changing the delay will not completely get rid of this
phenomenon but will definitely make a ton of my other
shortcuts harder to use. That visual delay makes a lot of sense,
it's just not a feature that was intended with this specific use
in mind and so it seems to behave strange for jj/jk/etc
shortcuts.
I tried mapping both jk and kj to Esc for a while (so I could just mash them in any order), but the slight delay it added to the letters always threw me off my loop.
You can reduce the delay by setting ttimeoutlen, the time in milliseconds between an escape key being pressed (or jk etc. that are mapped to Esc) and exiting Insert mode. I have it set to 100.
[deleted]
The first thing I put in my .vimrc on any system:
inoremap jk <ESC>
I use jk too. Happy with it. My .vimrc has this: set <esc>=jk
I wonder what the difference is.
I like kk.
On remapping caps:
ctrl-[ is escape in terminals by default.
It’s often easier to map caps to ctrl than escape when pressed and ctrl when held. Most OSs support that without extra software.
Even in Vim it’s still very useful to have a convenient ctrl key. A lot of useful features make use of Ctrl in Vim.
On remapping leader:
Remapping to spacebar means your thumbs are dedicated to that operation. That’s more balanced left-right for touch typing.
Also you get to keep the default behaviour.
ctrl-[ is escape in terminals by default.
It’s often easier to map caps to ctrl than escape when pressed and ctrl when held. Most OSs support that without extra software.
Even in Vim it’s still very useful to have a convenient ctrl key. A lot of useful features make use of Ctrl in Vim.
On remapping leader:
Remapping to spacebar means your thumbs are dedicated to that operation. That’s more balanced left-right for touch typing.
Also you get to keep the default behaviour.
> Remap your "capslock" key to "escape."
I hear this recommendation a lot. You can do that, but much better is to get a keyboard with a proper thumb cluster like a kinesis[1], maltron[2], dactyl[3], ...
Much better to put such a common key on the thumb than stress out a pinky. I have a kinesis, and have esc mapped to the 'end' key there; similar positioning is possible on other keyboards. The keyboards I linked are also much more ergonomic than most flat keyboards—important, if you rely on your hands and wrists for your livelihood. Bit expensive, but well worth it.
1. https://kinesis-ergo.com/shop/advantage2/
2. https://www.maltron.com/
3. https://github.com/adereth/dactyl-keyboard
I hear this recommendation a lot. You can do that, but much better is to get a keyboard with a proper thumb cluster like a kinesis[1], maltron[2], dactyl[3], ...
Much better to put such a common key on the thumb than stress out a pinky. I have a kinesis, and have esc mapped to the 'end' key there; similar positioning is possible on other keyboards. The keyboards I linked are also much more ergonomic than most flat keyboards—important, if you rely on your hands and wrists for your livelihood. Bit expensive, but well worth it.
1. https://kinesis-ergo.com/shop/advantage2/
2. https://www.maltron.com/
3. https://github.com/adereth/dactyl-keyboard
Several years ago I finally developed RSI. It took nearly a year of different setups and exercises to figure out what would work. The cause of RSI for me was a well known ergo keyboard. I had been using it for nearly a year before the pain/numbness started in my hands. I went back to standard slab keyboards, and every time I use a ergo keyboard the issues flare up again.
So, while I like the style of those keyboards, I can't justify spending that much if I am likely to develop RSI again.
---
I'm one of those weirdo's that has remapped caps to Lctrl/esc, tab to hyper/tab, \| to alt/\|, return to Rctl/enter. It's comfortable. (Ralt is now Compose/Dead Greek and Rctrl is Caps Lock)
I would love more buttons to the left of the keyboard. I currently use a 10-keyless but would love a cluster of 10-15 keys to the left of my left hand. and possibly 6 keys under the thumb area. And a real dedicated hyper key. Maybe another row of F-Keys too...
So, while I like the style of those keyboards, I can't justify spending that much if I am likely to develop RSI again.
---
I'm one of those weirdo's that has remapped caps to Lctrl/esc, tab to hyper/tab, \| to alt/\|, return to Rctl/enter. It's comfortable. (Ralt is now Compose/Dead Greek and Rctrl is Caps Lock)
I would love more buttons to the left of the keyboard. I currently use a 10-keyless but would love a cluster of 10-15 keys to the left of my left hand. and possibly 6 keys under the thumb area. And a real dedicated hyper key. Maybe another row of F-Keys too...
For me it was enough to just remap my right Alt to Ctrl. No need for expensive hardware which I can't bring with me everywhere. The ThinkPad keyboard is good enough.
Regarding 2, I think using 'space' as leader will be the most easy one to get into. You don't lose any meaningful functionality and space is (ideally) operated with your thumb, which means you can bind any key combination without awkward hand movements.
I just use ctrl-c instead of esc. Infinitely more accessible than esc or even ctrl bracket - it mystifies me why it’s not more commonly known. Only problem is that it quits you out of macros, so you need to use esc then, but that’s easy to remember and I use ctrl-c probably 4 orders of magnitude more than I use macros. (In fact, multi cursor mode in vscode vim obsoletes them for me entirely!)
It’s not that ctrl-c isn’t widely known it’s that Escape and ctrl-c are not equivalent in Vim.
Ctrl-c breaks all kinds of things including repeats, so ctrl-[ is usually a better choice.
Ctrl-c breaks all kinds of things including repeats, so ctrl-[ is usually a better choice.
my leader character is space, makes things super easy
Make your leader key something easy like the comma character ","
I would do this but I use the comma and semicolon keys all the time. I find them so useful. Gosh vim is weird. Everyone uses it differently!
I would do this but I use the comma and semicolon keys all the time. I find them so useful. Gosh vim is weird. Everyone uses it differently!
I guess you mean you use them to insert ,s and ;s. But the leader key would not be for insert mode, so you can choose anything convenient.
No, I use them with the f and F keys. They repeat the previous character search in forward and backward directions.
Oh, I see. Sorry for assuming. I use the ; for that often, but didn't even know about , for going backwards. (Now I'm thinking that my bunch of maps using , were not such a good idea.)
I find rhysd/clever-f [1] to be more DWIM than Vim's default f/F.
" 0: F is backward search, and repeating f after F searches in the same direction
" 1: F is backward search, and repeating F after F searches in the same direction
let g:clever_f_fix_key_direction = 1
I try not to use vim plug-ins where built in functionality will suffice. I’ve trained vim’s default behaviour into my muscle memory so I’m fine with it. In fact, I used plain old vi (technically Keith Bostic’s nvi [1]) for years and sometimes I find myself preferring it.
I think a lot of people who use vim end up with a ton of unnecessary plugins and they aren’t even aware of half the functionality of plain vi. I might just be a weird minimalist though.
[1] https://sites.google.com/a/bostic.com/keithbostic/vi/
I think a lot of people who use vim end up with a ton of unnecessary plugins and they aren’t even aware of half the functionality of plain vi. I might just be a weird minimalist though.
[1] https://sites.google.com/a/bostic.com/keithbostic/vi/
About 1., you can simply use ctrl-] as an alternative Escape command.
Remap esc to ‘kj‘ instead. It’s faster to type than ‘jj’ it’s on the home row and doesn’t require a custom binding. The sequence kj is rarely used in English or coding.
What a hackjob that is.
> Remap your "capslock" key to "escape."
Isn't it possible to configure vim to just use the actual CapsLock status for the mode switch?
Isn't it possible to configure vim to just use the actual CapsLock status for the mode switch?
I see the value of remaping the esc key to cpaslock, but my hands are quite big and I can reach esc on most keyboards quite effortlessly.
I think this is a bad idea because remapping keys has significant consequences with compatibility as you develop across more platforms. A good vi user is trying to build universal muscle memory, and making personal exceptions kinda ruins the efficacy of the editor.
For example: I switch between dozens of computers, some are transient VMs or cloud instances, and I cannot afford the time (or simply cannot alter the system) to set each one up to my personal VI specs.
(Ironically, I'm a mac fan, but this is my biggest gripe going between every OS and Apple: the command key is absurd; I tried to remap to make everything work like Ctrl but that hoses the entire system and screws up VNC/RemoteDesktop...)
For example: I switch between dozens of computers, some are transient VMs or cloud instances, and I cannot afford the time (or simply cannot alter the system) to set each one up to my personal VI specs.
(Ironically, I'm a mac fan, but this is my biggest gripe going between every OS and Apple: the command key is absurd; I tried to remap to make everything work like Ctrl but that hoses the entire system and screws up VNC/RemoteDesktop...)
I haven't done this completely (I use the jk remap hack in preference to escape) but I agree with this in general.
Emacs is an operating system, and vi is a language, which is widely "spoken". But if you invent your own dialect, you have an MxN problem, of getting M changes to register across the N programs which will listen to you when you speak to them in vi.
And I simply must nibble the bait in your last line: As a Mac native user, the command key, and consistency in commands across every native application, is one of the great features. It means, among other things, that Ctrl-whatever won't be intercepted when I send it to a program that uses it, or alternately, that it won't shadow the OS level affordance.
Back when I was spending five days a week inside a Linux VM, the context switch between Cmd-X and Ctrl-X for cut was pretty rapid and painless. Sure, I'd get the occasional cache miss, but that's harmless.
Emacs is an operating system, and vi is a language, which is widely "spoken". But if you invent your own dialect, you have an MxN problem, of getting M changes to register across the N programs which will listen to you when you speak to them in vi.
And I simply must nibble the bait in your last line: As a Mac native user, the command key, and consistency in commands across every native application, is one of the great features. It means, among other things, that Ctrl-whatever won't be intercepted when I send it to a program that uses it, or alternately, that it won't shadow the OS level affordance.
Back when I was spending five days a week inside a Linux VM, the context switch between Cmd-X and Ctrl-X for cut was pretty rapid and painless. Sure, I'd get the occasional cache miss, but that's harmless.
You should absolutely personalize tools you use extensively. Vim if your a writer or programmer.
It’s very little to cp .vimrc. I do a lot more, have dotfiles git repo scripted to self install.
But yes transient vms are problem. But I’m willing to suffer a little on them to have 20x more enjoyable and productive were I do 90% of my writing.
It’s very little to cp .vimrc. I do a lot more, have dotfiles git repo scripted to self install.
But yes transient vms are problem. But I’m willing to suffer a little on them to have 20x more enjoyable and productive were I do 90% of my writing.
The first thing I do on a new machine is clone my dotfiles from Github. It's fast enough for an action that increases my productivity exponentially and I'll end up saving back that time it took to clone very quickly. I don't switch machines that often anyway.
I wholeheartedly agree with this sentiment. I have a lot of keybindings but I always make sure I can survive without them, such as by dropping into vanilla vim to once in a while to do work and ensuring I'm not completely lost. A user in the vim subreddit refers to this as 'sharpening the saw'.
For the vim enthusiasts reading, I'd like to bring to your attention some other resources released in the last few months
— ThePrimeagen (YouTube): https://www.youtube.com/channel/UC8ENHE5xdFSwx71u3fDH5Xw
— Vim Tricks (newsletter/Twitter): https://vimtricks.com/
— and humbly, myself, Semicolon&Sons: https://www.youtube.com/watch?v=futay9NjOac&list=PLpkoC9yJXD...
— ThePrimeagen (YouTube): https://www.youtube.com/channel/UC8ENHE5xdFSwx71u3fDH5Xw
— Vim Tricks (newsletter/Twitter): https://vimtricks.com/
— and humbly, myself, Semicolon&Sons: https://www.youtube.com/watch?v=futay9NjOac&list=PLpkoC9yJXD...
+100 for ThePrimagen on Youtube. His videos are great for people looking to get started with Vim.
In my opinion, the greatest benefit of using Vim, Emacs or even Acme is how easy it is to create custom tools for your problem at hand, even for one-shot tasks. VSCode is very capable, but it can't compete in this regard (and maybe that's what they want and maybe it's a good call as well).
I've tried using the vim plugin for VSCode many times, and every time I come back to it, it just feels... off? The actual vim keybindings work fine when you're editing the document, but I find that when you want to use some of the other features of the editor, it becomes a bit more tricky/hacky.
If MS made an official set of vim keybindings that had better editor support, or even if there was some sort of kill switch that let me turn off vim key bindings quickly, I would be 100% sold on VSCode, but until then, I'll stick to the terminal.
If MS made an official set of vim keybindings that had better editor support, or even if there was some sort of kill switch that let me turn off vim key bindings quickly, I would be 100% sold on VSCode, but until then, I'll stick to the terminal.
Have you tried the neovim _integration_ VS Code extension? [0] It's not perfect (I'm still in a terminal 95% of the time, but my current VSCode set up is surprisingly not painful and I find myself using it more frequently) but it gets a lot further along than VsVim did for me (which is probably not a far comparison because I have not actually used VsVim in many years) or VSCodeVim when I tried it recently. YMMV, of course.
A word of advice, though, if you plan to check this out... I'd recommend maintaining a separate neovim install specifically for the VS Code integration and make sure that it has fairly basic vimrc with limited plugins. You have to take care with this because (neo)vim plugins don't always play nicely with VS Code and vice versa.
[0]: https://github.com/asvetliakov/vscode-neovim
A word of advice, though, if you plan to check this out... I'd recommend maintaining a separate neovim install specifically for the VS Code integration and make sure that it has fairly basic vimrc with limited plugins. You have to take care with this because (neo)vim plugins don't always play nicely with VS Code and vice versa.
[0]: https://github.com/asvetliakov/vscode-neovim
I recommend swapping your left CTRL and ALT keys when using vim, as well as CAPS and ESC to avoid RSI.
Also, the dot operator is king.
Also, the dot operator is king.
Wow, I had no idea about the dot operator. And TIL about `gd` (moves to the word's definition) and `gf` (for file imports) as well.
I started Vim when the internet went out once and, bored, I finally tried `vimtutor` on the debian command line.
It just opens vim to a txt file that incrementally explains how to make basic edits. I was instantly hooked when I realized how much time "o" and "O" alone would save me over.
I almost never use Vim these days because I was too lazy to port my .vimrc + Vundle plugins to a new laptop at some point, but I use a Vim-mode in every editor I use, even the browser.
It just opens vim to a txt file that incrementally explains how to make basic edits. I was instantly hooked when I realized how much time "o" and "O" alone would save me over.
I almost never use Vim these days because I was too lazy to port my .vimrc + Vundle plugins to a new laptop at some point, but I use a Vim-mode in every editor I use, even the browser.
The best way to understand and use vim is to learn the "grammar" of vim and then practice using it until you have muscle memory for common movement and editing commands.
This stackoverfow post explains how the vi/vim "grammar" works:
https://stackoverflow.com/questions/1218390/what-is-your-mos....
A fun way to develop the muscle memory for the normal mode movement keys is to play Nethack (https://www.nethack.org/) with the number_pad option set to 0 so that hjkl are used for movement, the same basic keys for vi/vim normal mode (https://nethackwiki.com/wiki/Options#number_pad).
This stackoverfow post explains how the vi/vim "grammar" works:
https://stackoverflow.com/questions/1218390/what-is-your-mos....
A fun way to develop the muscle memory for the normal mode movement keys is to play Nethack (https://www.nethack.org/) with the number_pad option set to 0 so that hjkl are used for movement, the same basic keys for vi/vim normal mode (https://nethackwiki.com/wiki/Options#number_pad).
Another fun game to play that focuses a bit more on vim itself: https://vim-adventures.com/
I definitely second playing nethack, whether you want to improve your vim skills or not.
I definitely second playing nethack, whether you want to improve your vim skills or not.
That game is a labor of love by someone - I spent weeks playing it. So much fun solving puzzles and learning at the same time.
If I had a criticism is that I'm not sure much has stuck with me. I still use the same 10-15 commands and all the obscure tricks it taught me are gone.
Its worth the money just for the fun alone. Great to mess with on a laptop when you're on a plane.
the biggest problem is you buy the game for $25 and it only lasts 6 months, that seems a bit crap, doesn't really make sense to me to sell it as a limited time license, which is why I never bought it. But then I'm not exactly the target audience, I already know Vim, but I did enjoy the intro levels when I tried it a while back.
That's true but most people would pay that once or twice, which puts potentially small beans if it increases your productivity. Plus it's fun
I dunno, I don't buy things when I don't think the pricing is fair, regardless of whether I can afford it, as a gamer, $25 gets you a lot of good games that you keep forever. This one, you don't keep, to me it just doesn't feel right. I'm sure others feel differently, but, just putting it out there why I chose not to buy it where otherwise I would have.
Do you really? I've been using as my primary editor for last 10 years or so, I rarely make use of the grammar. I sounds fancy and powerful in theory but I don't end up using it that often (even though I'm aware of it).
That said I'm probably only an intermediate user, because I haven't put in the time to really make things like markers and macros part of my editing habits.
That said I'm probably only an intermediate user, because I haven't put in the time to really make things like markers and macros part of my editing habits.
Thats fine. The main thing is not to confuse technique with repertoire.. like a musical instrument, putting time in to mastering scales and finger technique will get you a lot of finesse in tackling musical pieces but it's the quality of your repertoire (in this context the algorithms/languages/higher problem solving knowledge) is what will be what gets you the money. Still a practising a few scales every now and then...
That SO reply is a classic for a reason. If you don’t use the “grammar” you could be having a nicer time with your editor. Especially when editing code, being able, for instance, to pull out the contents of a pair of brackets, with or without the brackets, instantly, is quite convenient.
The book in the link has a chapter on grammar.
I partially learnt Vim some 20 years ago, but at some point stopped taking in new commands (possibly for lack of repetitive use), and am stuck in a sort of 'good enough' zone, but still awkward for certain things; the ctrl-c/v thing always throws me as I use windows primarily, gvim makes it easy to cheat using the GUI, so I do. Macros are amazing, but I feel there are probably easier ways of achieving most of the things I use them for (they, and regex search/replace are most if what I use Vim for outside of writing code).
You get over it if you use it enough. For me its now the opposite. For a while
I keep accidentally trying to do Ctrl+C/Ctrl+V, but now I find myself trying to
go into Visual mode or Normal mode in programs that dont support that.
I started off with a bunch of mappings, then you can remove them as you get comfortable. Now I only really have mapped "nmap H :nohlsearch<CR>" and "xmap S :sort<CR>".
Whats really tricky is using Vim without the Arrow keys. Normally I am on a desktop so it doesnt matter, but when I use a laptop it makes more sense to use HJKL. Again its just something that you need to force yourself to do or you wont get comfortable with it.
I started off with a bunch of mappings, then you can remove them as you get comfortable. Now I only really have mapped "nmap H :nohlsearch<CR>" and "xmap S :sort<CR>".
Whats really tricky is using Vim without the Arrow keys. Normally I am on a desktop so it doesnt matter, but when I use a laptop it makes more sense to use HJKL. Again its just something that you need to force yourself to do or you wont get comfortable with it.
HJKL makes no sense for me at all. It reminds me of the annoyingly designed computer games I used to play on my Oric as a kid, where the various direction keys to control my 'character' often bore no relation to their relative positions on the keyboard.
H and L are just about OK for left and right, but up and down being another left/right positioned key combo, nestled in between, just doesn't work with the way my brain's wired, at all.
Conversely, on my MacBook Air keyboard, the arrow keys are nicely grouped together in an inverted T formation at bottom right corner of the keyboard, with some space around them. Piss-easy to find and piss-easy to feel which one points in which direction, without even looking at the keyboard.
Strange that almost every tutorial on Vim I've ever read begins with "Don't be tempted to use the arrow keys instead of HJKL.." which, in my opinion is just about the "worst advice evarrr!", especially given the rest of the learning curve which awaits you.
*YMMV --depending on your own particular keyboard layout.
H and L are just about OK for left and right, but up and down being another left/right positioned key combo, nestled in between, just doesn't work with the way my brain's wired, at all.
Conversely, on my MacBook Air keyboard, the arrow keys are nicely grouped together in an inverted T formation at bottom right corner of the keyboard, with some space around them. Piss-easy to find and piss-easy to feel which one points in which direction, without even looking at the keyboard.
Strange that almost every tutorial on Vim I've ever read begins with "Don't be tempted to use the arrow keys instead of HJKL.." which, in my opinion is just about the "worst advice evarrr!", especially given the rest of the learning curve which awaits you.
*YMMV --depending on your own particular keyboard layout.
I agree that HJKL is really uncomfortable for a new user. I still reverse J and K sometime, as my brain thinks "the first key should be Up".
I guess the thinking is, if you open up some existing document, youre already at the top, so the more important key is going down, which the "J" sits right under your index finger.
I totally agree that its awkward, but I also feel that if you can get good with it, youll be way faster than using the arrow keys. Think about it like this: with the arrow keys, you must move your hand. With HJKL, you dont have to move your hand from the home row.
I guess the thinking is, if you open up some existing document, youre already at the top, so the more important key is going down, which the "J" sits right under your index finger.
I totally agree that its awkward, but I also feel that if you can get good with it, youll be way faster than using the arrow keys. Think about it like this: with the arrow keys, you must move your hand. With HJKL, you dont have to move your hand from the home row.
I think the "not moving your hands from the home row" is another relic of a bygone era. It dates back to when people were taught to touch type and that was the starting position. It also dates from a time when keys had to be pressed with some force. Resting your fingers on the keys with a modern laptop keyboard, you're in danger of accidentally typing characters you didn't want to.
I can type pretty fast, though I've never actually measured my WPM speed. But I'm not a touch typist --I still have to look at the keys-- and I don't type 'properly' using all my fingers. I seem to get by with the first three on each hand. So there's no real advantage for me in having my fingers resting on the home row. In pauses for thought [my equivalent of resting on the home row] I usually find I'm waiting with the heels of my hands on the empty space below the keyboard, either side of the trackpad and my fingers just kind of very lightly touching the keys, wherever they happen to fall.
From that position, it really is far more convenient for me to just curl in the fingers of my right hand , which puts the inverted T of the cursor keys right under my finger tips and which I can do without looking, than it is for me to look down at the keys to find HJKL.
I can type pretty fast, though I've never actually measured my WPM speed. But I'm not a touch typist --I still have to look at the keys-- and I don't type 'properly' using all my fingers. I seem to get by with the first three on each hand. So there's no real advantage for me in having my fingers resting on the home row. In pauses for thought [my equivalent of resting on the home row] I usually find I'm waiting with the heels of my hands on the empty space below the keyboard, either side of the trackpad and my fingers just kind of very lightly touching the keys, wherever they happen to fall.
From that position, it really is far more convenient for me to just curl in the fingers of my right hand , which puts the inverted T of the cursor keys right under my finger tips and which I can do without looking, than it is for me to look down at the keys to find HJKL.
I know it sounds like a joke but any book on Vim should have have as its first lesson: how to quit Vim. That's the #1 question I get from vim beginners.
Lol, I made kind of learning material on Vim, and that's exactly what I do.
https://p1v0t.github.io/Doctor/
https://p1v0t.github.io/Doctor/
Buffers are one of the few parts of vim I never really got the hang of. Neither that nor windows are things I can ever remember how to do without fudging it the first time, having to go look up the manual again for how to do it properly, realize I'm wasting more time than I'm saving by trying to learn it, and give up.
Which part of it do you struggle remembering? maybe the wisdom of hn's vim users can help :)
Personally, I can't imagine being productive without windows and buffers. although when I have 3+ buffers open, I usually "cheat" by fzf-finding the file (rather than `:bn`-ing my way there, or `:b` `:b x`).
Personally, I can't imagine being productive without windows and buffers. although when I have 3+ buffers open, I usually "cheat" by fzf-finding the file (rather than `:bn`-ing my way there, or `:b` `:b x`).
I'm sorry to say it, but don't bother with this. It's unfinished and not in depth. The most important Vim resource is "Practical Vim" by Drew Neil. If you haven't read it you shouldn't be using Vim.
I'm not trying to be contrarian here, but why would someone continue to use Vim and Emacs when all of its lovely features have been integrated into products like VCode?
It just reminds me of serious men with beards working on mainframes and AIX power systems when I started my career.
It just reminds me of serious men with beards working on mainframes and AIX power systems when I started my career.
> all of its lovely features
I think this might be only superficially true. One of the meta-features of vim/emacs is, over months and years of use, they slowly teach you how IDEs "work", and invite you to tweak how yours works to your whim.
example: I notice a process is slow in vim. I'm able to profile the problem, identify the binary responsible, replace it with a faster equivalent program, and enjoy that improvement for the rest of my life. Such a thing may be possible in VS Code, but it's against the norm of "just install this plugin", whereas it is the norm in vim/emacs-world.
Some other scattered ideas:
I also think that, since vim and emacs are fundamentally cli tools also gives them an advantage, because you can hook them in to your terminal workflows (git add -p, git commit -v, etc). also, you can dispatch terminal commands seamlessly from inside vim (I get `make build` in two keystrokes: `,d`).
vim (I can't speak for emacs, don't use it) is also more responsive with a much smaller resource footprint and an equivalent feature set. my work laptop can run a web browser and vim for 6+ hours. With vs code, maybe 3 hours.
I think this might be only superficially true. One of the meta-features of vim/emacs is, over months and years of use, they slowly teach you how IDEs "work", and invite you to tweak how yours works to your whim.
example: I notice a process is slow in vim. I'm able to profile the problem, identify the binary responsible, replace it with a faster equivalent program, and enjoy that improvement for the rest of my life. Such a thing may be possible in VS Code, but it's against the norm of "just install this plugin", whereas it is the norm in vim/emacs-world.
Some other scattered ideas:
I also think that, since vim and emacs are fundamentally cli tools also gives them an advantage, because you can hook them in to your terminal workflows (git add -p, git commit -v, etc). also, you can dispatch terminal commands seamlessly from inside vim (I get `make build` in two keystrokes: `,d`).
vim (I can't speak for emacs, don't use it) is also more responsive with a much smaller resource footprint and an equivalent feature set. my work laptop can run a web browser and vim for 6+ hours. With vs code, maybe 3 hours.
Vim is just one piece of the puzzle, it's the editor in the IDE that is unix. Tools like VSCode and IDE's take over too many responsibilities and usually do an inferior job. VSCode will do the window management for instance, opening new tabs for files, file list windows, terminal windows, etc. My desktop environment (dwm or tmux) is much better at this and universal for non development tasks as well. Another bug bear of mine (this one doesn't apply to VSCode) is IDEs that want to be the build system instead of my much more powerful Makefiles.
Because it integrates so well into this environment it can be used as the editor step in other scripts/tools like how it is used in git commit messages. As a quick example of how this can be used here is a script I made for working with tab separated files:
Because it integrates so well into this environment it can be used as the editor step in other scripts/tools like how it is used in git commit messages. As a quick example of how this can be used here is a script I made for working with tab separated files:
tmpout="$1.tmp"
cat $1 | sed "s/\\t/~|/g" | column -t -s~ | \
vim -c 'set nowrap' - +"file $tmpout"
if [[ -f $tmpout ]]; then
<$tmpout sed "s/\\s*|\\s*/\\t/g" > $1
rm $tmpout
fi
A couple good reasons I can think of off the top of my head is that vim is easy to get up and running in headless environments, even with all of the bells and whistles of a modern text editor or IDE.
Another reason is that I really enjoy that vim runs in my terminal. I can easily toggle in and out of vim while doing heavy terminal work, and if I want to rapidly open and close different files while looking around for things vim makes it simple.
There might be an aesthetic or comfort aspect to it, but most tools don't stay as relevant as vim has for mere style points.
Another reason is that I really enjoy that vim runs in my terminal. I can easily toggle in and out of vim while doing heavy terminal work, and if I want to rapidly open and close different files while looking around for things vim makes it simple.
There might be an aesthetic or comfort aspect to it, but most tools don't stay as relevant as vim has for mere style points.
Sure, I use VSCode and Intellij and all the beautiful modern IDEs. But I use them with Vim keybindings turned on. Because extremely common things that you do while programming are extremely quick for me to do with vim commands.
ci" == delete everything within these quotes, and put me in insert mode. vi{:%s/old_var_name/new_var_name/g == rename a variable within a block qaI"<ESC>A",<ESC>jq == make a new macro to quote a line of text and add a comma at the end. Great for taking a bunch of strings I've copied from a text file and putting them into a list in code. But the point here is not this specific macro; I can do all sorts of minor text processing macros for the dumb thing I have to do, and not manually process 100 lines of text to turn it into a piece of json.
ci" == delete everything within these quotes, and put me in insert mode. vi{:%s/old_var_name/new_var_name/g == rename a variable within a block qaI"<ESC>A",<ESC>jq == make a new macro to quote a line of text and add a comma at the end. Great for taking a bunch of strings I've copied from a text file and putting them into a list in code. But the point here is not this specific macro; I can do all sorts of minor text processing macros for the dumb thing I have to do, and not manually process 100 lines of text to turn it into a piece of json.
Just started doing this for RSI reasons. Not having to constantly reach down to those arrow keys is fabulous.
That's funny - I'd have thought using arrow keys would help prevent RSI 'cos you're having to move your whole arm out of a static position. (Or maybe you don't? Do you just twist your wrist in an awkward position?)
With enough plugins, Vim can do everything VSCode can. But using a Vim-emulator in a different editor will always be an "uncanny valley" experience. Also on my system VSCodeVim is so slow it frequently lags behind me while typing.
I don't think most people suggest vim as a replacement for an IDE. In fact, personally I use vim bindings in my IDE because I think I think it's an efficient way to edit text, whereas the IDE provides things vim is not good at (e.g., navigating large code bases by easily jumping to definitions, doing automated refactoring, etc.).
However, there's also times when I don't have the luxury of using an IDE or when I just need to make quick edits to a single file. In these circumstances, I can just fire up vim and quickly do what I need to do because vim is ubiquitous and editing with it is efficient.
However, there's also times when I don't have the luxury of using an IDE or when I just need to make quick edits to a single file. In these circumstances, I can just fire up vim and quickly do what I need to do because vim is ubiquitous and editing with it is efficient.
Can I make a TODO link to a piece of code and have VSCode email it to me periodically? When viewing a particular function, can I have a link to the actual email discussing this feature in a comment, and have VSCode open up the relevant email?
You might be able to get the modal editing of Vim into other editors and IDEs, but you'll never get ability to modify your editor as if it's just another program (while it's running!), which is the main power of Emacs.
Can you please provide examples (or a link) that shows Vim integrated into VSCode?
I think they're referencing vim emulator plugins for VSCode: https://github.com/VSCodeVim/Vim
If you're new to vim, also consider https://kakoune.org/
About a month ago,
I forced myself to try and use nvi,
an (almost) narrowly compatible classic vi clone.
I thought of it as an exercise in constraint, with the aim of getting better at vim. Like vanilla vim without plugins, but Nightmare Difficulty.
I've now completely fallen for it. It's missing most mainstream features and still, I... like it more? I feel like a hipster typing this, but there really is a difference in brainfeel between using a ''huge'' editor I'll never grasp fully versus a tiny one I can learn completely. Tiny sparks joy.
Wikipedia entry on nvi: https://en.wikipedia.org/wiki/Nvi
Edits: grammar, punctuation.
I thought of it as an exercise in constraint, with the aim of getting better at vim. Like vanilla vim without plugins, but Nightmare Difficulty.
I've now completely fallen for it. It's missing most mainstream features and still, I... like it more? I feel like a hipster typing this, but there really is a difference in brainfeel between using a ''huge'' editor I'll never grasp fully versus a tiny one I can learn completely. Tiny sparks joy.
Wikipedia entry on nvi: https://en.wikipedia.org/wiki/Nvi
Edits: grammar, punctuation.
This book looks really cool, and I appreciate what they're doing.
If I could humbly add, one of the hardest things about learning Vim isn't reading a list of commands, but rather _practicing_ them. So I wrote a list of Vim exercises (or études for the musicians), files requiring various edits, and a daily practice schedule that can be used to drill each distinct skill. Once you've mastered it, you can drop it from your schedule. I found it was really the only way to actually commit some of the more esoteric skills to muscle memory.
Here's a sample for how to practice muscle memory around named registers for yank and put, a skill almost no one I know regularly uses because it's hard to learn just by reading. After writing this and working through the ten minute exercise daily for a couple weeks, it became second nature, and now I can't live without it.
https://github.com/steveshogren/10-minute-vim-exercises/blob...
If I could humbly add, one of the hardest things about learning Vim isn't reading a list of commands, but rather _practicing_ them. So I wrote a list of Vim exercises (or études for the musicians), files requiring various edits, and a daily practice schedule that can be used to drill each distinct skill. Once you've mastered it, you can drop it from your schedule. I found it was really the only way to actually commit some of the more esoteric skills to muscle memory.
Here's a sample for how to practice muscle memory around named registers for yank and put, a skill almost no one I know regularly uses because it's hard to learn just by reading. After writing this and working through the ten minute exercise daily for a couple weeks, it became second nature, and now I can't live without it.
https://github.com/steveshogren/10-minute-vim-exercises/blob...
I'm not a Vim master, but I use it a fair bit --mostly for writing server admin, single doc coding, etc. I think I know enough to do the basics like moving chunks of text around, copying/pasting etc. so that I feel fairly productive in that I can do those things as fast [or faster] in Vim as I could in a GUI editor..
But, any time I'm working on something more than a single doc [eg. a website, or a coding project] I reach for something else. I've just never been able to find a way to use Vim comfortably in a multi-document project, without feeling like I'm being a lot less productive than I would be using a GUI, such as TextMate with its built-in project file browser and excellent project wide find/replace.
I'm learning Flutter at the moment and just got into using IntelliJ [in its Android Studio guise] and, at first I installed the IdeaVim plugin, thinking this would give me the best of both worlds; the speed of moving about within single documents of Vim, combined with the project management & code completion capabilities of a dedicated IDE. I ended up disabling it after a couple of days. The mental context switching caused by jumping back and forward between keyboard driven and menu driven operation was just slowing me down, rather than speeding me up.
As an aside: I don't really get why the "Vim saves you having to hunt for menu items" mantra is still so prevalent in this day and age anyway. Maybe in the past when people had to reach for their mouse to find a menu item, it was a valid point in Vim's favour. But a lot of us are working on laptops these days and, frankly, accessing a menu item by tapping on a trackpad right under your fingers is hardly more hassle than recalling some arcane keyboard incantation to do the same in Vim. Plus, most regularly used menu items have keyboard shortcuts which pretty soon become muscle memory anyway. I've not needed to use a menu to access an Open / Close / Save / Save As / Print / Copy / Cut / Paste / Find / Replace / Undo / Redo / Quit... etc. etc. command in decades.
But, any time I'm working on something more than a single doc [eg. a website, or a coding project] I reach for something else. I've just never been able to find a way to use Vim comfortably in a multi-document project, without feeling like I'm being a lot less productive than I would be using a GUI, such as TextMate with its built-in project file browser and excellent project wide find/replace.
I'm learning Flutter at the moment and just got into using IntelliJ [in its Android Studio guise] and, at first I installed the IdeaVim plugin, thinking this would give me the best of both worlds; the speed of moving about within single documents of Vim, combined with the project management & code completion capabilities of a dedicated IDE. I ended up disabling it after a couple of days. The mental context switching caused by jumping back and forward between keyboard driven and menu driven operation was just slowing me down, rather than speeding me up.
As an aside: I don't really get why the "Vim saves you having to hunt for menu items" mantra is still so prevalent in this day and age anyway. Maybe in the past when people had to reach for their mouse to find a menu item, it was a valid point in Vim's favour. But a lot of us are working on laptops these days and, frankly, accessing a menu item by tapping on a trackpad right under your fingers is hardly more hassle than recalling some arcane keyboard incantation to do the same in Vim. Plus, most regularly used menu items have keyboard shortcuts which pretty soon become muscle memory anyway. I've not needed to use a menu to access an Open / Close / Save / Save As / Print / Copy / Cut / Paste / Find / Replace / Undo / Redo / Quit... etc. etc. command in decades.
ctrl-o/ctrl-i to move between buffers
list buffers w/ vim-buftabline
`nnoremap ; :Buffers<cr>`
list buffers w/ vim-buftabline
`nnoremap ; :Buffers<cr>`