Vim Reference Guide(learnbyexample.github.io)
learnbyexample.github.io
Vim Reference Guide
https://learnbyexample.github.io/vim_reference/Introduction.html
112 comments
I enter my e-mail on that Gumroad link but it doesn't give me the free eBook.
Is this perhaps a cunning way of the OP to collect e-mail addresses?
Is this perhaps a cunning way of the OP to collect e-mail addresses?
After you enter the email, you'll see "View Content" button on the web page itself. You'll also get an email having the same "View Content" button. From there, you can download PDF/EPUB versions.
Great job on this!
> what is all this need for complicated editing features? Why does a text editor require programming capabilities? Why is there even a requirement to learn how to use a text editor? Isn't it enough to have the ability to enter text, use Backspace/Delete/Home/End/Arrow/etc, menu and toolbar, some shortcuts, a search and replace feature and so on? A simple and short answer — to reduce repetitive manual task.
For me, the entry way, what convinced me to try Vim, was the advantage of not needing to move the mouse. That back and forth movement - lifting my hand, grasping for the mouse, moving the cursor to where it needs to be, clicking and dragging to highlight text, ctrl-x, moving the cursor to where it needs to be, ctrl-v, repeated throughout the day just felt inefficient.
But what really makes it feel like a super power is the repetitive tasks thing. Convert hundreds of dates from dd.mm.yyyy to ISO 8601? No problem! Alphabetize those lines? Can do. Convert that Jira ticket title to a git branch name? It's done already.
But "repetitive tasks" would never have convinced me to try it. "Just use cut and paste", I would have countered.
> what is all this need for complicated editing features? Why does a text editor require programming capabilities? Why is there even a requirement to learn how to use a text editor? Isn't it enough to have the ability to enter text, use Backspace/Delete/Home/End/Arrow/etc, menu and toolbar, some shortcuts, a search and replace feature and so on? A simple and short answer — to reduce repetitive manual task.
For me, the entry way, what convinced me to try Vim, was the advantage of not needing to move the mouse. That back and forth movement - lifting my hand, grasping for the mouse, moving the cursor to where it needs to be, clicking and dragging to highlight text, ctrl-x, moving the cursor to where it needs to be, ctrl-v, repeated throughout the day just felt inefficient.
But what really makes it feel like a super power is the repetitive tasks thing. Convert hundreds of dates from dd.mm.yyyy to ISO 8601? No problem! Alphabetize those lines? Can do. Convert that Jira ticket title to a git branch name? It's done already.
But "repetitive tasks" would never have convinced me to try it. "Just use cut and paste", I would have countered.
What finally made me switch was not seeing people editing with vim, but rather how they moved around and navigated, which seemed so much faster than any other editor.
What's the best way to rapidly move around without having to count lines? I sometimes use Ctrl + U and Ctrl + D to move entire pages but always found it a bit more laborious to move around in Vim. 13j seems like it would require me to count exactly 13 lines before I can get there.
I use vim + mouse unfortunately because it is quicker unless there is a better way?
I use vim + mouse unfortunately because it is quicker unless there is a better way?
> What's the best way to rapidly move around without having to count lines?
oooh. I have a treat for you! Check out "hybrid line numbers". I thought they would be weird when I heard about them, but they're awesome, and I never need "absolute line numbers". But the linked article shows you how to set up toggling if you need them.
Basically, they look like this:
Here's an article on them: https://jeffkreeftmeijer.com/vim-number/
oooh. I have a treat for you! Check out "hybrid line numbers". I thought they would be weird when I heard about them, but they're awesome, and I never need "absolute line numbers". But the linked article shows you how to set up toggling if you need them.
Basically, they look like this:
3 Lorem ipsum dolor sit amet,
2 nunc in iaculis ipsum.
1 Suspendisse dapibus odio erat,
98 non varius nulla porttitor at. // <-- You are here
1 Nullam in convallis elit.
2 Sed nec venenatis ligula.
3 consectetur adipiscing elit.
4 Sed hendrerit ac ante sed viverra.
Here's an article on them: https://jeffkreeftmeijer.com/vim-number/
I used to use this method until I tried out easymotion, which really does live up to its name.
https://github.com/easymotion/vim-easymotion
https://github.com/easymotion/vim-easymotion
When I open a file, I fold everything (zM) to get an overview of the file. Then I slowly unfold as I'm browsing, ignoring the parts I don't care about. I set the repeat delay super low and repeat rate super high on my keyboard and just navigate around by holding j/k or {/} (for large folds). Since everything is folded, you're moving about pretty quickly.
If you're looking to use the 20j stuff, you can `:set relativenumber` so that vim shows you line numbers relative to the selected line to avoid counting. I couldn't get used to it.
There's also Hop[0] if you want to go the plugin route.
[0] https://github.com/phaazon/hop.nvim
If you're looking to use the 20j stuff, you can `:set relativenumber` so that vim shows you line numbers relative to the selected line to avoid counting. I couldn't get used to it.
There's also Hop[0] if you want to go the plugin route.
[0] https://github.com/phaazon/hop.nvim
I've always wanted a sort of "hybrid" line numbering scheme. Show me the relative numbers in one column, and the absolute line numbers in another column. You can set up vim so that the absolute number appears on the line your cursor is on (and the other lines display relative nums) but this isn't quite enough.
I want both, dammit!
I want both, dammit!
I use { } to move by paragraph/block quite a bit.
/ or ? to search forward or backward.
C-f and c-b to go a full page. U and d are half.
But for me it’s not only about speed. I guess it just feels nice to use the keyboard, even when it’s a little slower.
/ or ? to search forward or backward.
C-f and c-b to go a full page. U and d are half.
But for me it’s not only about speed. I guess it just feels nice to use the keyboard, even when it’s a little slower.
A lot of the time, you want to be using a more meaningful (as in semantic) command like } or ]] or / - my Vim navigation improved a lot once I started understanding / as a navigation command i.e. a "go where I know this text is" rather than just "find where this text is".
But when you do need to move by lines, `set relativenumber` is very helpful. I have both `set number` and `set relativenumber` in my Vimrc, so I get relative numbers for all other lines except the current one. For the current line, the absolute line number in the file is displayed (which is more useful than the relative "0").
But when you do need to move by lines, `set relativenumber` is very helpful. I have both `set number` and `set relativenumber` in my Vimrc, so I get relative numbers for all other lines except the current one. For the current line, the absolute line number in the file is displayed (which is more useful than the relative "0").
> A lot of the time, you want to be using a more meaningful (as in semantic) command like...
I try never to second guess why someone wants to know something, and if I answer at all, to answer the direct question. Otherwise it might come off as patronizing and gate-keeping.
As an asker, I'm much more open to hearing the answer to an unasked question when I have the answer to my asked question.
My least-favorite genre of dev answer is Q: "How do I X?" A: "Don't X. Y instead."
Also, part of the awesomeness of Vim is that it's personal, how someone uses it. If information is structured in lines in someone's mind, and it makes more sense for them to navigate that way, they aren't doing it wrong.
I try never to second guess why someone wants to know something, and if I answer at all, to answer the direct question. Otherwise it might come off as patronizing and gate-keeping.
As an asker, I'm much more open to hearing the answer to an unasked question when I have the answer to my asked question.
My least-favorite genre of dev answer is Q: "How do I X?" A: "Don't X. Y instead."
Also, part of the awesomeness of Vim is that it's personal, how someone uses it. If information is structured in lines in someone's mind, and it makes more sense for them to navigate that way, they aren't doing it wrong.
I just press and hold j until i'm on the line i want to be on if it's that close.
otherwise ctrl-f and u coupled with zz to center it
gd for go to definition.
using { and } for paragraph navigation is also useful. / is nice for words you know coupled with n and N
and using something like an outline is also nice to use when visually selecting.(i've been using neovim as a backend for vscode so this is built in) and if you use vscode they have a nice go back out feature too ctrl + - (which i forget what it is in vim but probably gb if i had to guess but you are limited to how vim works in that regard.
otherwise ctrl-f and u coupled with zz to center it
gd for go to definition.
using { and } for paragraph navigation is also useful. / is nice for words you know coupled with n and N
and using something like an outline is also nice to use when visually selecting.(i've been using neovim as a backend for vscode so this is built in) and if you use vscode they have a nice go back out feature too ctrl + - (which i forget what it is in vim but probably gb if i had to guess but you are limited to how vim works in that regard.
There is Lightspeed, which is a buffer search tool thing, bound to `s`.
It's pretty nice, but to be honest I just use `/` and `n` a hell of a lot. And `j` is probably my most used character. :)
It's pretty nice, but to be honest I just use `/` and `n` a hell of a lot. And `j` is probably my most used character. :)
> What's the best way to rapidly move around without having to count lines?
Don't? Just turn on line numbers with `set nu`. Add it to your `.vimrc` for a default. In a pinch where you need to copy/paste graphically in your terminal and don't want the line numbers on? `set nonu` to turn them off again.
Sibling comments also have great solutions/different ways of navigating.
Don't? Just turn on line numbers with `set nu`. Add it to your `.vimrc` for a default. In a pinch where you need to copy/paste graphically in your terminal and don't want the line numbers on? `set nonu` to turn them off again.
Sibling comments also have great solutions/different ways of navigating.
I use:
H move to the to of the current view
M move to the middle of the current view
L move to the bottom of the current view
The way I remember them is (H)igh, (M)iddle, (L)ow
Also setting fold to indent and collapsing the whole file with zM is super helpful for navigating large files.
Lastly I use searching a lot with / or ? To just type the pattern I'm looking for # to search for the word under my cursor.
The way I remember them is (H)igh, (M)iddle, (L)ow
Also setting fold to indent and collapsing the whole file with zM is super helpful for navigating large files.
Lastly I use searching a lot with / or ? To just type the pattern I'm looking for # to search for the word under my cursor.
I find using marks along with the associated jumplist (ctrl-o and ctrl-i) and changelist (g; and g.) commands very useful.
#G (i.e. 20G) would put the cursor on line 20, but that's only useful if you have line numbers in your editor. If you have relative line numbers then #j movement is easy since the number you need to jump up or down should already be calculated.
I did turn on relative line numbers and still feels laborious compared to mouse click which happens within 500 ms.
Say I want to go up by 13 lines and on the 4th word:
Step 1: Scan visually on the left gutter for a line number (relative or not)
Step 2: 13j
Step 3: 3e (3 words to the right)
Everything else in vim is fast except navigation for me. With mouse, it is a little bit of a pain to move the hand over to the mouse and the click, but still feels orders of magintude faster than jumbling around with line numbers.
Say I want to go up by 13 lines and on the 4th word:
Step 1: Scan visually on the left gutter for a line number (relative or not)
Step 2: 13j
Step 3: 3e (3 words to the right)
Everything else in vim is fast except navigation for me. With mouse, it is a little bit of a pain to move the hand over to the mouse and the click, but still feels orders of magintude faster than jumbling around with line numbers.
I mostly use / and ? for jumping about in the code. It’s always just a few keystrokes and you’re where you want to be.
[deleted]
If you're willing to use a plugin: easymotion (or, for nvim, hop.nvim)
Hi, great work releasing this! Trying to explain vim concisely is always an interesting challenge and I had a great time reading your attempt in this book. I always find it really interesting on how people try to group certain vim functions in a way that makes sense to people that don't use vim.
Whenever I try to explain vim to other people, I always start super abstract, i.e 'vim grammar is all (count)? verb then object. Learn actions and then the movements to apply the action where you want'. I think you cover that idea pretty well in your 'Vim philosophy and features' section whilst not making it overly abstract and keeping it relatable.
Some things I noticed, you mention registers in the insert mode section before explaining what they are. It seemed odd to me that you used the word before explaining what it meant, but maybe it is unavoidable?
I also noticed you completely left out folds (z, :help fold). Personally, I aggressively fold code I'm not working on so I think they are super important :D. There was a plugin posted recently thats a cool alternative to folding though (similar to emacs narrow) [0] [1].
[0] https://github.com/hoschi/yode-nvim
[1] https://news.ycombinator.com/item?id=30305011
Whenever I try to explain vim to other people, I always start super abstract, i.e 'vim grammar is all (count)? verb then object. Learn actions and then the movements to apply the action where you want'. I think you cover that idea pretty well in your 'Vim philosophy and features' section whilst not making it overly abstract and keeping it relatable.
Some things I noticed, you mention registers in the insert mode section before explaining what they are. It seemed odd to me that you used the word before explaining what it meant, but maybe it is unavoidable?
I also noticed you completely left out folds (z, :help fold). Personally, I aggressively fold code I'm not working on so I think they are super important :D. There was a plugin posted recently thats a cool alternative to folding though (similar to emacs narrow) [0] [1].
[0] https://github.com/hoschi/yode-nvim
[1] https://news.ycombinator.com/item?id=30305011
Thanks for your feedback. And your point about 'Vim philosophy and features' section is interesting. I find it difficult to explain abstractly and I wondered if I should copy-paste some sections from the famous "you don't grok vi" answer (https://stackoverflow.com/a/1220118).
>Some things I noticed, you mention registers in the insert mode section before explaining what they are. It seemed odd to me that you used the word before explaining what it meant, but maybe it is unavoidable?
Yeah, my chapter structuring ended up in many cases like that. For example, I mention how to modify behavior of left/right arrow keys to move across lines using a setting. But, Command-line mode chapter comes later and use of vimrc comes even later. For cases like registers in Insert mode chapter, I linked to the Normal mode section after the bullet points (may be I could move it to the start of section).
>I also noticed you completely left out folds
I knew that there's a fold feature but haven't used them. I think I cover only about three commands with `z` in Normal mode chapter. I don't use multiple buffers in same window, tags, third-party packages, etc - so details on them are light too (or entirely missing).
>Some things I noticed, you mention registers in the insert mode section before explaining what they are. It seemed odd to me that you used the word before explaining what it meant, but maybe it is unavoidable?
Yeah, my chapter structuring ended up in many cases like that. For example, I mention how to modify behavior of left/right arrow keys to move across lines using a setting. But, Command-line mode chapter comes later and use of vimrc comes even later. For cases like registers in Insert mode chapter, I linked to the Normal mode section after the bullet points (may be I could move it to the start of section).
>I also noticed you completely left out folds
I knew that there's a fold feature but haven't used them. I think I cover only about three commands with `z` in Normal mode chapter. I don't use multiple buffers in same window, tags, third-party packages, etc - so details on them are light too (or entirely missing).
Oh yeah, I just realized you completely left that stuff out. That's one of my favorite parts of vim and what I find lacking in 'vim mode' plugins. They get the hotkeys right, but they lack the abstractions of tabs/buffers/windows. What most editors call 'tabs' are windows in vim, and they lack the concept of a vim tab. I use them all the time when I'm doing refactoring work. Being able to organize 'views' in a way that makes sense, then switch between them rapidly is so awesome. You're refactoring some code across 3 files (all open in splits), then you want to look up some other part of the code base for reference. :tabe browse around, read whatever with 100% of the screen devoted to what you're trying to read, then gT and you're back on your old view with 3 buffers open. I have to constantly build up and then destroy these views in other editors. Or just accept that half my screen is cluttered up with irrelevant stuff.
Also the fact that everything in vim is a buffer inside a window means that everything is super consistent! You can switch focus between your plugin windows and your files with the same hotkeys! And unless the plugin writer intentionally changed stuff, the plugin buffer works just like a normal buffer, so all the hotkeys you learned before still apply. It's what I really miss in IntelliJ IDE's. I can see all the different panels, but I cannot switch focus to them without memorizing panel-specific hotkeys! I can see the bloody panel is left of my current focus, let me switch focus by just pressing ctrl+h instead of alt+shift+3.
Anyway, vim is very vast and trying to explain everything is a daunting task. I think you've made a good attempt :).
Also the fact that everything in vim is a buffer inside a window means that everything is super consistent! You can switch focus between your plugin windows and your files with the same hotkeys! And unless the plugin writer intentionally changed stuff, the plugin buffer works just like a normal buffer, so all the hotkeys you learned before still apply. It's what I really miss in IntelliJ IDE's. I can see all the different panels, but I cannot switch focus to them without memorizing panel-specific hotkeys! I can see the bloody panel is left of my current focus, let me switch focus by just pressing ctrl+h instead of alt+shift+3.
Anyway, vim is very vast and trying to explain everything is a daunting task. I think you've made a good attempt :).
When I was first introduced to Vim I thought : Modal editing is a great idea!
I also thought why the hell do I have to hit Esc to get into normal mode!? You couldn't make a key further for the home row. So I refused to use it for a month until I stumbled on a Reddit post on how to swap the Esc key and Caps Lock :
"setxkbmap -option caps:swapescape" on Linux. Somewhere in the settings for MacOs.
For Linux you don't have to swap, there are other clever options.
Turns out that Esc on old "Unix" keyboards use to sit where Caps Lock is on modern keyboards
Another popular option is to have "jk" switch to normal mode as you are unlikely to need to insert that combination of letters.
How almost all introductions to Vim do not mention that historical fact and the fix for it, is beyond me.
Turns out that Esc on old "Unix" keyboards use to sit where Caps Lock is on modern keyboards
Another popular option is to have "jk" switch to normal mode as you are unlikely to need to insert that combination of letters.
How almost all introductions to Vim do not mention that historical fact and the fix for it, is beyond me.
I use Ctrl-c instead of esc, works really nice for me. I prefer it to jk actually. But that's the thing, choice. That's the best thing about our tools and operating systems. Respect for the user choice.
Posting to say that I don't recommend ctrl-c without understanding that it's not equivalent to esc. From the docs:
> Quit insert mode, go back to Normal mode. Do not check for abbreviations. Does not trigger the InsertLeave autocommand event.
If you don't use abbreviations then there but if insert-based plugins aren't working as described, this may be why.
Of course you can solve this with `inoremap <c-c> <esc>`.
> Quit insert mode, go back to Normal mode. Do not check for abbreviations. Does not trigger the InsertLeave autocommand event.
If you don't use abbreviations then there but if insert-based plugins aren't working as described, this may be why.
Of course you can solve this with `inoremap <c-c> <esc>`.
crtl-m for me! i like to map my keys with the keywords i have in my head (control + Mode). i really like how you put it in that last sentence. though i main my macbook for development purposes, my daily driver is a linux machine. i never really knew why i liked it other than i like to fuck around with different distributions... now that i see it in words, i like that the OS respects my choices. if i want to change something, i can. it's not impossible on MacOS, it's just sort of disrespectful how difficult it is to customize your experience!
For others reading this, binding ^M and Ret separately will only work in a GUI, since they send vim the same bytes in a terminal.
I am all for choice. But the default is just plain bad and introductions generally don't even mention Ctrl+c
i think that's what first turns people off from vim. the defaults are (subjectively) terrible from an ease-of-use perspective. usability wise, nothing beats it. maybe emacs competes, but i've never given it a go. i think most introductions would do well with showing people how to change their configurations first. that's why i use neovim anyway.
i took a unix course my third semester at uni and we had an entire 2 weeks dedicated to vim and how to feel more comfortable in our environments. we were only allowed to ssh into our development environments and the professor noted he's had a lot of success after ensuring everyone felt a-okay at the command line. at the end, we had an extra credit assignment where we got to show off our configs and present to the class why we made the choices we made. some kid even got me to start using some cool plugins (goyo, if i remember correctly), he introduced me to neovim!
i took a unix course my third semester at uni and we had an entire 2 weeks dedicated to vim and how to feel more comfortable in our environments. we were only allowed to ssh into our development environments and the professor noted he's had a lot of success after ensuring everyone felt a-okay at the command line. at the end, we had an extra credit assignment where we got to show off our configs and present to the class why we made the choices we made. some kid even got me to start using some cool plugins (goyo, if i remember correctly), he introduced me to neovim!
Swapping caps lock for escape is something that I first started going because of Vim, but now can't live without, in every context! I even started using it on other operating systems, even if I don't use Vim on them (mostly Windows and macOS), because it's so useful.
Only trouble are in some games on Windows where the developers seems to have hardcoded the game to react to the actual Escape key instead of the key in the operating system, so pressing Caps Lock has no effect, and pressing escape does show the pause menu but also turns on caps lock (as I have it switched).
Other than that, life is much better with them swapped.
Only trouble are in some games on Windows where the developers seems to have hardcoded the game to react to the actual Escape key instead of the key in the operating system, so pressing Caps Lock has no effect, and pressing escape does show the pause menu but also turns on caps lock (as I have it switched).
Other than that, life is much better with them swapped.
I just have two escape keys - the actual key and Caps Lock. Do you find that you actually use Caps Lock for anything?
I do, for names in CONSTANT_CASE. But i use the Neo layout, where you press left + right Shift for Caps lock functionality. The Caps lock key itself is the modifier to reach layer 3.
On Linux, not really. Sometimes I disconnect my keyboard and reconnect it again, so the swapping gets restored, and I accidentally hit Caps Lock AND EVERYTHING IS BIG NOW. THEN I RUN THE SWAP COMMAND AND I'M NOW STUCK IN CAPS LOCK MODE unless I could just hit Escape again, which if I didn't swap, I couldn't.
Jokes aside, it's mostly on Windows I have use for caps lock as some games I play use that key for things, so it's handy to have it swapped instead.
Jokes aside, it's mostly on Windows I have use for caps lock as some games I play use that key for things, so it's handy to have it swapped instead.
Same here! I primarily use linux and MacOS and have bound caps lock to escape for both of them. I rarely miss caps lock, it's better to keep your voice down online anyway ;)
I had the same issue, and I've found that most people haven't discovered that ctrl+[ is the same as hitting the escape key, and doesn't require any custom config.
I always found this advice annoying (and I actually do see it in many vim introductions) and didn't find it particularly bad to reach for escape, but I have mostly used 60% keyboards for many years now, so esc is one row lower than normal (where the ~ key is on a fullsize).
Asking people to remap keys feels pretty major, but also there are many things people tell you to replace capslock with. I personally think making it a compose key is a better choice.
Asking people to remap keys feels pretty major, but also there are many things people tell you to replace capslock with. I personally think making it a compose key is a better choice.
The useless context menu key is for me the best compose key
But I've already swapped the caps lock for the ctrl key!
Using Karabiner Elements, you can have tap for escape, hold for control. After about a decade of experimenting, I’ve basically decided that that is how the Caps Lock key should actually function.
The real escape key is the one that should be Caps Lock
The real escape key is the one that should be Caps Lock
I do this and it's really great. I don't understand how people live with hitting ctrl-c in the default layout of a mac keyboard. It's so uncomfortable.
I remap jj to esc. Right on the home row, completely independent of OS and keyboard layout. I can barely find the control key on a Mac...
Oh ya, I'm a jk person myself. But for the times I need esc (even outside of vim) it's tap Caps Lock for me!
There was a post on HN once for a hack to do the same on Linux
Found that : https://www.dannyguo.com/blog/remap-caps-lock-to-escape-and-...
Too bad it is Mac only, no Linux support.
Then do ctrl+[ which sends the esc code :)
if you have jk and kj set to escape all you have to do is mash them at the same time and it works without fail and it's quicker than pressing capslock to escape. well worth the change. and the rare times i need to use j or k next to each other you just press it slower... it's only been a pretty rare thing.
I always feel that how to exit and quit vim should be at the very top of the first page. With a quick explanation for the various ways to do it.
ZQ - in normal mode, quits (notice no colon and capital)
ZZ - in normal mode, saves only if file was modified and quits
:x - same as ZZ
:w - write the file
:wq - writes the file regardless of changes and quits
:q - quit, if no changes
:q! - quit, regardless of changes
:w !sudo tee % - For when you need to save a file you don't have permission to and you forgot to start vim with sudo.
> :w - write the file
> :wq - writes the file regardless of changes and quits
The first one is also "write the file regardless of changes", to be clear. The command version of "saves only if file was modified" is :up (for update). I have that mapped to a normal mode key and rarely ever use `:w`.
> :wq - writes the file regardless of changes and quits
The first one is also "write the file regardless of changes", to be clear. The command version of "saves only if file was modified" is :up (for update). I have that mapped to a normal mode key and rarely ever use `:w`.
Just learned about update, after 18 years of vimming, thanks!
Might also want to note :cq[uit] to quit with an error code. This can often be useful when you're using vim as your $EDITOR and wish to tell the calling process that you want to abort.
Good call, I think I've only used :cq once(?).
:cq is very handy for aborting merges
Oops, I probably could've offered examples. So, when writing a mail I can choose to simply give up instead of dropping me in to a dialog for "save draft/quit?", or to drop out of an edit session in `git add --interactive`, etc. The reason it can be useful in these specific instances is that you don't need to unwind your changes if you've run filters to modify the text for example.
Given that Vim's biggest barrier to entry is its learning curve, I don't think starting out by teaching people 8 ways to do 2 things is the right approach.
Agreed that exiting should be the first thing taught to new Vim users though.
Agreed that exiting should be the first thing taught to new Vim users though.
>> :w !sudo tee %
A king is you. Thanks for this one... I can stop hating myself a little bit more now.
A king is you. Thanks for this one... I can stop hating myself a little bit more now.
There's also :qa for "quit all files" - I guess this is just another modifier, but I never use "a" in any other context.
Neat stuff! Nowadays, I mostly use Cheatsheet[1] to quickly look up things I want to do, but resources like this are always nice for learning new stuff you didn't know about.
One piece of feedback is that I would include "+p and "+yy in the copy and paste section. I feel like that's the first place where people will go to look for "How to copy and paste using clipboard".
[1] https://github.com/sudormrfbin/cheatsheet.nvim
One piece of feedback is that I would include "+p and "+yy in the copy and paste section. I feel like that's the first place where people will go to look for "How to copy and paste using clipboard".
[1] https://github.com/sudormrfbin/cheatsheet.nvim
Thanks.
And that's a good feedback, I'll add something to that effect in the next version.
The interactive cheatsheet looks so cool! Gotta try it out. Could be extended to programming languages too.
And that's a good feedback, I'll add something to that effect in the next version.
The interactive cheatsheet looks so cool! Gotta try it out. Could be extended to programming languages too.
Oh, wow. This type of command discovery with fuzzy search and human readable description is what I've been looking for to enable sublime/vscode/atom/intelij cmd-shift-p type of functionality. This is a must IMHOfor a feature heavy editor nowadays. Thanks for the link.
I can't be the only one to use :x instead of :wq but I never see it in tutorials. It's 50% fewer keys!
ZZ also does the trick, but I always do :wq out of habit. After all, you only write and quit once per file.
ZZ is the same as :x which are both what I would normally want to do - only write if changed.
I would use :wq! to overwrite readonly files more than I would use :wq The only use case I can think of writing when not changed is if there is a process watching the file that I want to trigger.
I think the problem with teaching people how to save and quit in vim is that there are so many ways they might want to do it and nobody wants to dumb it down to a single default. It is a bit like how Zig doesn't have a simple print macro because in real code do you want your output buffered or unbuffered, etc.
I would use :wq! to overwrite readonly files more than I would use :wq The only use case I can think of writing when not changed is if there is a process watching the file that I want to trigger.
I think the problem with teaching people how to save and quit in vim is that there are so many ways they might want to do it and nobody wants to dumb it down to a single default. It is a bit like how Zig doesn't have a simple print macro because in real code do you want your output buffered or unbuffered, etc.
ZZ and ZQ are both very nice.
On the note of saving/quitting and things not being mentioned enough, I only recently learned about :up to only save the file if there were actually changes (probably short for "update). Saves some time, especially with remote files, if you're one to save a lot and not remember if you saved recently already. I think this is closer to how emacs saving works by default. I bind space-f-s to save files, and tend to use that more than :w or similar, so in my case I just updated what that keybind did.
On the note of saving/quitting and things not being mentioned enough, I only recently learned about :up to only save the file if there were actually changes (probably short for "update). Saves some time, especially with remote files, if you're one to save a lot and not remember if you saved recently already. I think this is closer to how emacs saving works by default. I bind space-f-s to save files, and tend to use that more than :w or similar, so in my case I just updated what that keybind did.
I have mapped F2 to save and F3 to save and quit ;)
Probably I should add something about alternate ways, there's another comment with more variations that I didn't cover.
Probably I should add something about alternate ways, there's another comment with more variations that I didn't cover.
This is a fine resource. For those who love vim already but want to really understand it this was shared by my team internally: https://github.com/mhinz/vim-galore
Yeah, Vim galore is a nice resource. Was discussed a couple of months back: https://news.ycombinator.com/item?id=30084913
If you're thinking about learning Vim, take a look at https://kakoune.org/why-kakoune/why-kakoune.html
I used vim for many years, and I prefer kakoune because: 1) Object-verb is better than verb-object (gives visual feedback, and makes it easier to compose commands) 2) Great support for multiple selections
I used vim for many years, and I prefer kakoune because: 1) Object-verb is better than verb-object (gives visual feedback, and makes it easier to compose commands) 2) Great support for multiple selections
Thanks for sharing! Interesting to me given that I already tend to use vim this way - my tendency is to use visual selection followed by verb. How was the learning curve as an experienced vim'er?
Never reached being a vim power user. Somehow I always end back up to an IDE especially when it involves a bigger project. Could someone share some power user examples when only using vim it really shines for programming?
I use "recorded on the fly" macros all the time. But other than that, I use vim to avoid using an IDE as much as possible. I keep in the terminal, have all my tools available, don't have to click around or wait for load times, etc. Vim opens instantly and I can navigate to where I need to go instantly.
For instance, just yesterday, I had a test failed that was comparing two (big) classes of objects, and the test suite spits them out as single long lines as a diff.
But looking at long lines are super hard to read, so I can just do something once (ie: take a vertical chunk of text between zero and the next comma, and append it to end of file) then run that macro 70 times, and suddenly that long line I had to scroll through is all divvied up and I can easily spot where the issue is.
All of this is a bit simpler (believe me!) Compared to trying to remember where a certain menu item or action is. I'd probably have to pull up excel if I didn't have vim.
But you've heard this all before
For instance, just yesterday, I had a test failed that was comparing two (big) classes of objects, and the test suite spits them out as single long lines as a diff.
But looking at long lines are super hard to read, so I can just do something once (ie: take a vertical chunk of text between zero and the next comma, and append it to end of file) then run that macro 70 times, and suddenly that long line I had to scroll through is all divvied up and I can easily spot where the issue is.
All of this is a bit simpler (believe me!) Compared to trying to remember where a certain menu item or action is. I'd probably have to pull up excel if I didn't have vim.
But you've heard this all before
I like Vim's editing model. Vim itself is a truly awesome piece of software. BUT - it doesn't have IDE style features, which I have come to rely on to do my job effectively, built in.
Luckily for me, Vim's editing model exists in the IDEs I use via Vim 'emulation' plugins. In Jetbrains IDEs and in VSCode, the emulation is quite good. In the incredibly rare instance where I need a macro or some similar 'power user' Vim feature, I just pop that file open in Vim.
For me this approach strikes the best balance. I get to use the powerful modal editing that I've come to enjoy, while also getting to take advantage of the many powerful features of IDEs.
Luckily for me, Vim's editing model exists in the IDEs I use via Vim 'emulation' plugins. In Jetbrains IDEs and in VSCode, the emulation is quite good. In the incredibly rare instance where I need a macro or some similar 'power user' Vim feature, I just pop that file open in Vim.
For me this approach strikes the best balance. I get to use the powerful modal editing that I've come to enjoy, while also getting to take advantage of the many powerful features of IDEs.
IdeaVim by JetBrains does macros. Slower than Vim but still.
The best thing about Vim is that you don't have to choose between Vim and an IDE! Any text editor or IDE that's even moderately popular will probably have a decent Vim plugin. The only downside is that you generally won't have access to Vim plugins (abolish.vim is the one I find myself missing the most: https://github.com/tpope/vim-abolish).
Personally, I learned to use Vim via the VsVim plugin for Visual Studio.
Personally, I learned to use Vim via the VsVim plugin for Visual Studio.
I always use https://vim.rtorr.com/
I use nvim in general and it's good but I'd appreciate an editor with modal idea but free of some decades old legacy logic that's not really intuitive (and requires tweaks to bring things in shape). Are there some modern alternatives that fill that role and are decent out of the box?
Check out kakoune mentioned in another comment in this thread: https://news.ycombinator.com/item?id=30694487
Interesting, I'll look into it. Thanks!
What is the point of Vim? I have used it before and to me it just looks like an antiquated text editor. But I'm sure I must be missing something.
It isn't just the look, it really is an antiquated text editor, based on even more antiquated text editors. Though a well maintained one with a very active fork in neovim.
There are arguably better IDEs for programming and easier text editors that are still very powerful and support customisation and extensibility.
Being a reasonably small editor with a text based UI I can easily use it to edit files anywhere and on any sort of hardware with great performance and opening up a file to make a quick change is practically instant. And then being able to navigate around, edit and change different types of text objects isn't something all that common outside of the vi world I think.
It is probably most suited to people who want quick mouseless editing of text and already work in a *nix command line environment. First impressions aren't great and I am sure lots of people give up and use something else including myself. But then my needs changed and I found vim (now neovim) was a surpsiingly good fit. Like most editors it needs a few plugins installed and customised to support more complex needs and they aren't a point and click thing like vscode.
There are arguably better IDEs for programming and easier text editors that are still very powerful and support customisation and extensibility.
Being a reasonably small editor with a text based UI I can easily use it to edit files anywhere and on any sort of hardware with great performance and opening up a file to make a quick change is practically instant. And then being able to navigate around, edit and change different types of text objects isn't something all that common outside of the vi world I think.
It is probably most suited to people who want quick mouseless editing of text and already work in a *nix command line environment. First impressions aren't great and I am sure lots of people give up and use something else including myself. But then my needs changed and I found vim (now neovim) was a surpsiingly good fit. Like most editors it needs a few plugins installed and customised to support more complex needs and they aren't a point and click thing like vscode.
You probably don't need it. I like it because it's lightweight and always available in my terminal, and the modal paradigm of editing is very well suited to editing code. It's more like modifying the structure of the code rather than working at the character-level.
However, I've spent years finding the right set of plugins, shortcuts, and keybindings that work best for me. I've basically turned it into an IDE for myself, but one that I can navigate much more efficiently than something like Pycharm (even with vim mode).
However, I've spent years finding the right set of plugins, shortcuts, and keybindings that work best for me. I've basically turned it into an IDE for myself, but one that I can navigate much more efficiently than something like Pycharm (even with vim mode).
pro-tip: the "Hello World" for any vi/vim reference is to start by showing the user how to exit it. safely, quickly, ideally with no loss of edit state
please, we beg you, for the love of humanity. there have been anecdotal tales of folks trapped inside vi sessions for weeks, months, even years, ultimately passing from lack of water or food
please, we beg you, for the love of humanity. there have been anecdotal tales of folks trapped inside vi sessions for weeks, months, even years, ultimately passing from lack of water or food
[deleted]
Another predator preying on newbies.
Don't waste your money on this. Doing $ vimtutor and then going through the user manual is all it takes to learn Vim. Easy, free, and built-in.
Don't waste your money on this. Doing $ vimtutor and then going through the user manual is all it takes to learn Vim. Easy, free, and built-in.
People write books about things, I don't think they're preying on anybody. It looks like all the material is free on the site anyways but you can pay for an ebook if you want.
> People write books about things, I don't think they're preying on anybody.
Lots of books are written about things people are anxious about or afraid of in the sole purpose of banking on those anxieties and fears.
Step 1: convince vim-curious people that a) it will turn them into elite hackers and b) that it is freaking hard to learn.
Step 2: capitalize on the tension created at step 1 by providing them ways to skip b on the way to (imaginary) a.
Lots of books are written about things people are anxious about or afraid of in the sole purpose of banking on those anxieties and fears.
Step 1: convince vim-curious people that a) it will turn them into elite hackers and b) that it is freaking hard to learn.
Step 2: capitalize on the tension created at step 1 by providing them ways to skip b on the way to (imaginary) a.
I just "purchased" the book on Gumroad for $0. On page seven it states "This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License". Not sure how it's predatory.
Aside: To any newbies that want to read the PDF or Epub version and it's no longer free on Gumroad, hit me up and I'll send you a copy.
Aside: To any newbies that want to read the PDF or Epub version and it's no longer free on Gumroad, hit me up and I'll send you a copy.
> Not sure how it's predatory.
Neither the licence of that thing nor its price tag have anything to do with it.
Neither the licence of that thing nor its price tag have anything to do with it.
They mention vimtutor right on the purchase page, and in the book too.
And they provide a link [1] to free Vim resources available online, on a page that the author maintains themselves.
This is the opposite of what someone "preying on newbies" would do.
[1] https://learnbyexample.github.io/curated_resources/vim.html
And they provide a link [1] to free Vim resources available online, on a page that the author maintains themselves.
This is the opposite of what someone "preying on newbies" would do.
[1] https://learnbyexample.github.io/curated_resources/vim.html
I don't think that this is predatory; even if they're charging for this, it's useful to get different perspectives on teaching. We're all a bit different, sometimes `vimtutor` isn't going to stick.
I mean, taking this logic to its extreme, should universities by completely abolished, since most of the information available in universities is also available online for free?
I mean, taking this logic to its extreme, should universities by completely abolished, since most of the information available in universities is also available online for free?
> I mean, taking this logic to its extreme, should universities by completely abolished, since most of the information available in universities is also available online for free?
That would be a different logic.
That would be a different logic.
How though? All this person is offering is a different tutorial for Vim, and they might eventually charge money for it. Yes, the information is available for free via Vimtutor (or a million other online tutorials), but that doesn't make a paid tutorial predatory, any more than any other paid information tutorial.
It's not a different tutorial. It's a gigantic, messy, incomplete reference card. And yes, it is predatory, just like every other ebook/app/whatever based on the misconception that Vim is hard to learn.
I've been using Vim as my full time editor for a decade (well Neovim for the last five years), so believe me when I say this: Vim is hard to learn. It's not a misconception. Modal editing never really took off, so people's exposure to text editing prior to learning Vim is generally something like MSOffice, which is not modal.
Maybe you're some hypergenius who picked up Vim in an afternoon, but I know several people who I recommended "just go through Vimtutor" and it didn't stick for them.
Maybe you're some hypergenius who picked up Vim in an afternoon, but I know several people who I recommended "just go through Vimtutor" and it didn't stick for them.
12 years, here, 10 of them spent debunking such nonsense and reverting all the silly misconceptions people get from tweets/videos/posts/etc. Vim is _not_ hard to learn. It's more than a misconception, at this point, it's a myth. The learning material is free, easy to follow, and goes very progressively from nothing to advanced without even assuming computer proficiency. The only requirements are a) Vim, b) high school level ESL, c) time.
> Modal editing never really took off, so people's exposure to text editing prior to learning Vim is generally something like MSOffice, which is not modal.
Well, modal editing is just some $NEW_THING you must learn to do $ACTIVITY efficiently. Just like a new framework or ice skating. Not having been exposed to it prior to your first time is not a handicap because no one has. Every budding vimmer is literally equal before modal editing.
> Maybe you're some hypergenius who picked up Vim in an afternoon
It took me 4 months to know enough of Vim and be comfortable enough to ditch my previous editor for good.
> but I know several people who I recommended "just go through Vimtutor" and it didn't stick for them.
Well, that's a dumb advice so no surprise, here: you rigged them for failure and they failed. vimtutor only covers the basics needed for adding a line to /etc/hosts or write a commit message so no wonder why they bailed out if they believed they were going to be wizards after a 30 minutes tutorial. The real learning starts at :help user-manual.
Besides, giving up after vimtutor is perfectly OK. Vim is just one editor among many and it is not for everyone.
Learning Vim is _not_ hard. What _is_ hard is using it efficiently without learning it, which makes people take all kinds of silly shortcuts and spread all kinds of silly ideas.
> Modal editing never really took off, so people's exposure to text editing prior to learning Vim is generally something like MSOffice, which is not modal.
Well, modal editing is just some $NEW_THING you must learn to do $ACTIVITY efficiently. Just like a new framework or ice skating. Not having been exposed to it prior to your first time is not a handicap because no one has. Every budding vimmer is literally equal before modal editing.
> Maybe you're some hypergenius who picked up Vim in an afternoon
It took me 4 months to know enough of Vim and be comfortable enough to ditch my previous editor for good.
> but I know several people who I recommended "just go through Vimtutor" and it didn't stick for them.
Well, that's a dumb advice so no surprise, here: you rigged them for failure and they failed. vimtutor only covers the basics needed for adding a line to /etc/hosts or write a commit message so no wonder why they bailed out if they believed they were going to be wizards after a 30 minutes tutorial. The real learning starts at :help user-manual.
Besides, giving up after vimtutor is perfectly OK. Vim is just one editor among many and it is not for everyone.
Learning Vim is _not_ hard. What _is_ hard is using it efficiently without learning it, which makes people take all kinds of silly shortcuts and spread all kinds of silly ideas.
> It took me 4 months to know enough of Vim and be comfortable enough to ditch my previous editor for good.
OK, but you can be productive with Eclipse or Jetbrains (or even Emacs) in an afternoon. This implies to me that they're easier.
For me, it also took a few months to get to the point where I felt comfortable getting rid of Emacs and use Vim for everything, but it only took me a few days to be productive with Emacs initially. The swap was worth it, but it was a steep learning curve.
OK, but you can be productive with Eclipse or Jetbrains (or even Emacs) in an afternoon. This implies to me that they're easier.
For me, it also took a few months to get to the point where I felt comfortable getting rid of Emacs and use Vim for everything, but it only took me a few days to be productive with Emacs initially. The swap was worth it, but it was a steep learning curve.
Eclipse and friends are more approachable than Vim because they all follow the same familiar model. With so much of the core in common, newcomers and switchers have very little to learn to use those tools efficiently.
Vim being a modal editor, it is very unfamiliar to newcomers and switchers so they have a lot more to learn to use it efficiently.
But "little to learn" doesn't necessarily mean "easy to learn" and "a lot to learn" doesn't necessarily mean "hard to learn". In practice, "little to learn" means "easy to pick up" and "a lot to learn" means "hard to pick up", which is something else entirely. Eclipse, IntelliJ, VS Code, etc. are definitely easier to pick up than Vim but that doesn't make Vim "hard to learn" at all. It just means that, if you want to get something done quickly or don't want to invest too much effort into it, Vim might not be the most appropriate tool in the toolbox.
Take Sublime Text, for example. It followed a familiar editing model but its documentation was so lacking that members of the community had to put up an alternative doc. ST was (I have no idea how it fares today) definitely "easy to pick up" but also "hard to learn", all because of poor documentation.
Obviously, the modes, the wonky ways to copy and paste, etc. have always made Vim "hard to pick up". But with vimtutor as a first step and the very well written and progressive user manual as a second step, it _actually_ is "easy to learn". There is literally no obstacle beside one's own laziness or lack of focus or something external out of one's control. You _really_ move from super basic stuff, to less basic stuff, to cool stuff, to mind-blowing stuff in the most gentle, step-by-step way. The user manual is awesome.
In short, Vim is easy to learn and it has a very smooth learning curve.
The things people have trouble with are:
- the off-putting unfamiliarity of the first contact,
- the lack of menus and things that would make it easier to pick up,
- the unfounded expectations, reinforced by social media bullshit,
- the unfounded fears, reinforced by social media bullshit,
- the perceived need to be productive right now,
- a general taste for battery-included things,
- a general confusion between "learning about something" and "learning something",
- a general aversion for learning and, mostly, being taught,
- and for reading,
- the false impression of being smart enough to get it without learning,
- a goal-oriented approach that seems to justify every fucking shortcut ("I'm a React Dev, give me a config, plz."),
- etc.
Vim being a modal editor, it is very unfamiliar to newcomers and switchers so they have a lot more to learn to use it efficiently.
But "little to learn" doesn't necessarily mean "easy to learn" and "a lot to learn" doesn't necessarily mean "hard to learn". In practice, "little to learn" means "easy to pick up" and "a lot to learn" means "hard to pick up", which is something else entirely. Eclipse, IntelliJ, VS Code, etc. are definitely easier to pick up than Vim but that doesn't make Vim "hard to learn" at all. It just means that, if you want to get something done quickly or don't want to invest too much effort into it, Vim might not be the most appropriate tool in the toolbox.
Take Sublime Text, for example. It followed a familiar editing model but its documentation was so lacking that members of the community had to put up an alternative doc. ST was (I have no idea how it fares today) definitely "easy to pick up" but also "hard to learn", all because of poor documentation.
Obviously, the modes, the wonky ways to copy and paste, etc. have always made Vim "hard to pick up". But with vimtutor as a first step and the very well written and progressive user manual as a second step, it _actually_ is "easy to learn". There is literally no obstacle beside one's own laziness or lack of focus or something external out of one's control. You _really_ move from super basic stuff, to less basic stuff, to cool stuff, to mind-blowing stuff in the most gentle, step-by-step way. The user manual is awesome.
In short, Vim is easy to learn and it has a very smooth learning curve.
The things people have trouble with are:
- the off-putting unfamiliarity of the first contact,
- the lack of menus and things that would make it easier to pick up,
- the unfounded expectations, reinforced by social media bullshit,
- the unfounded fears, reinforced by social media bullshit,
- the perceived need to be productive right now,
- a general taste for battery-included things,
- a general confusion between "learning about something" and "learning something",
- a general aversion for learning and, mostly, being taught,
- and for reading,
- the false impression of being smart enough to get it without learning,
- a goal-oriented approach that seems to justify every fucking shortcut ("I'm a React Dev, give me a config, plz."),
- etc.
Couldn't agree more.
One reason I chose Vim is because I was tired of reaching the limitations in various editors I've tried and I wanted one I wouldn't outgrow.
It's been about 10 years and I'm still learning new things, even though I've had the basics down for quite a while. There have been times I've gone down some deep Vim rabbit holes for a particular project; it's great knowing all of the power is there any time you need it.
One reason I chose Vim is because I was tired of reaching the limitations in various editors I've tried and I wanted one I wouldn't outgrow.
It's been about 10 years and I'm still learning new things, even though I've had the basics down for quite a while. There have been times I've gone down some deep Vim rabbit holes for a particular project; it's great knowing all of the power is there any time you need it.
you have a very weird mix of arrogance and blinders going on here. looking back through the thread, your one consistent argument is people are being 'duped' thinking they'll be 'wizards' by all these earnest, helpful tutorials... and that vim is __not__ hard to learn.
It's simply not the case. Maybe it was the case for you. Maybe you purchased a vim book and didn't become this mythical hacker wizard. maybe vim seems absurdly simple to you because you are a genius. I don't know!
But I do know this - other people have different contexts, different knowledge, different experiences than you do. When you stomp around angrily and arrogantly denouncing a perfectly innocent thing like a vim tutorial, and show zero indication that you understand that other people find things valuable when you cannot see that value... it just makes you look like a fool.
I'd put my money on the notion that very few, if any readers of HN are going to be impressed by your furious denouncement here - rather they are only going to see a weak fool shaking his tiny fists at a perceived slight for no special reason. Maybe they'll chuckle. Put me down for $20 on that action.
It's simply not the case. Maybe it was the case for you. Maybe you purchased a vim book and didn't become this mythical hacker wizard. maybe vim seems absurdly simple to you because you are a genius. I don't know!
But I do know this - other people have different contexts, different knowledge, different experiences than you do. When you stomp around angrily and arrogantly denouncing a perfectly innocent thing like a vim tutorial, and show zero indication that you understand that other people find things valuable when you cannot see that value... it just makes you look like a fool.
I'd put my money on the notion that very few, if any readers of HN are going to be impressed by your furious denouncement here - rather they are only going to see a weak fool shaking his tiny fists at a perceived slight for no special reason. Maybe they'll chuckle. Put me down for $20 on that action.
vim user manual in pdf form is surprisingly difficult to find. Here is one I found: https://begriffs.com/pdf/vim-user-manual.pdf
It's already in Vim, where it matters, so there is no need for such a thing. First, because it may not be up to date (current version is 8.2, with 9.0 around the corner), second, because the links to the reference manual are dead.
Not everyone wants to sit in front of the computer and read the help file. That is, sometimes it's easier to sit down with a printout, or on a tablet, and read it like a book (or as a document with working links, which this one is). Yes, it is certainly valuable to have it right there in the editor, easy to consult at a moment's notice. But saying there's "no need" for it sounds self-absorbed; you don't need it, so neither does anyone else.
> Not everyone wants to sit in front of the computer and read the help file. That is, sometimes it's easier to sit down with a printout, or on a tablet, and read it like a book (or as a document with working links, which this one is).
It's a hands-on tutorial. You don't "read it like a book", you follow it and do the exercises. Besides, only the internal links work, here, so there is no way to dig deeper from the comfort of your couch.
> Yes, it is certainly valuable to have it right there in the editor, easy to consult at a moment's notice.
No. The user manual is not something you "consult at a moment's notice". It's something you focus on, deliberately, during 1-2 hours sittings.
It's a hands-on tutorial. You don't "read it like a book", you follow it and do the exercises. Besides, only the internal links work, here, so there is no way to dig deeper from the comfort of your couch.
> Yes, it is certainly valuable to have it right there in the editor, easy to consult at a moment's notice.
No. The user manual is not something you "consult at a moment's notice". It's something you focus on, deliberately, during 1-2 hours sittings.
> It's a hands-on tutorial. You don't "read it like a book", you follow it and do the exercises.
Well, I have been known to take helpfiles like this and "read them like a book," or at least like a reference manual to a particular group of functions.
> Besides, only the internal links work, here, so there is no way to dig deeper from the comfort of your couch.
Internal links are exactly what I'm looking for, so I can jump from one part of the file to another, but external links in the PDF file work just fine.
> No. The user manual is not something you "consult at a moment's notice". It's something you focus on, deliberately, during 1-2 hours sittings.
Yes. I have consulted user manuals at a moment's notice.
There doesn't seem to be much intersection between my life experience and yours.
Well, I have been known to take helpfiles like this and "read them like a book," or at least like a reference manual to a particular group of functions.
> Besides, only the internal links work, here, so there is no way to dig deeper from the comfort of your couch.
Internal links are exactly what I'm looking for, so I can jump from one part of the file to another, but external links in the PDF file work just fine.
> No. The user manual is not something you "consult at a moment's notice". It's something you focus on, deliberately, during 1-2 hours sittings.
Yes. I have consulted user manuals at a moment's notice.
There doesn't seem to be much intersection between my life experience and yours.
it’s really harsh to say that. I’m sure many people appreciate the material and effort
Not to take away anything from this but I think there are plenty more valuable resources available for free on the web on this topic.
The author (OP of this post) has a page listing some of those free resources available on the web: https://learnbyexample.github.io/curated_resources/vim.html
People appreciate lots of pointless things, and people like to profit from it. Such is life.
"Vim Reference Guide" is intended as a concise learning resource for beginner to intermediate level Vim users. I hope this guide would make it much easier for you to discover Vim features and learning resources than my own blundering experience.
To celebrate the release, ebook version is free to download till 31-Mar-2022:
* https://learnbyexample.gumroad.com/l/vim_reference_guide
* https://leanpub.com/vim_reference_guide
Some of my other ebooks and bundles are on sale and I'm currently creating short 1-3 minute videos to highlight Vim features. You can find these details in the above links.
Visit https://github.com/learnbyexample/vim_reference for markdown source and other details related to the book.
Hope you find these resources useful. Let me know your feedback.
Happy learning :)