A Website for Learning Vim
vim.is
vim.is
Also, a lot of beginners are perplexed why vi uses "hjkl" keys for cursor movement. It's because the 1976 ADM-3A terminal didn't have any dedicated arrow keys like the 1986 IBM PC 101-key layout: https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys
Without background info like that, learning vi can seem like memorizing random incoherent trivia.
I really don't understand why people get hung up on this. Vim supports arrow keys. hjkl are convenient alternatives but if you're at the point of not being comfortable switching between normal and insert mode just use the arrow keys. Insisting othereise is insisting you learn everything at once, which is demotivating and unnecessary.
Arrow keys are more versatile too. They do the behavior you expect in pretty much any mode.
While I don't approve of this on a practical level, I have to admit that I find the logic of the joke hilarious. You were in insert mode, and you pressed the arrow key, so it ... inserted an arrow.
Maybe because tutorials like vimtutor and this thread's website immediately blast hjkl finger exercises at the brand new user with no context whatsoever. The student is now wondering why they are pressing a seemingly arbitrary and random alphabet key just to move a cursor around.
E.g. vimtutor 1st screen:
Now, make sure that your Caps-Lock key is NOT depressed and press
the j key enough times to move the cursor so that lesson 1.1
completely fills the screen.
You can use the h and l keys to move the cursor.
Also, in my case, I learned classic vi (not vim) on DEC UNIX and the arrow keys did not work. Instead, the arrow keys inserted funny control characters depending the terminal emulation. So people used to be forced into using hjkl.
So vi/vim use those keys not /only/ because some old terminal, but because some old terminal used those keys /and/ there was a benefit to it.
Having my fingers leave home row as little as possible is vastly superior to reaching for arrow keys and having to reposition my fingers on home row.
With vi that made immediate sense to me. Switching to HHKB layout made even more sense, because I now can reach both CTRL and backspace easily without lifting my fingers from home row.
I did change my keymap even further, so that arrow keys are mapped to fn+hjkl. This way, I can navigate everything just with hjkl (:
Yeah once you get used to vim way of working with text you can essentially never go back.
I launched it 10 months ago on [2]HN and that launch ended up leading me down the path to start a company and get accepted into YC.
It's cool to see other people's take on a problem but this feels eerily similar to my tool, down to some of the copy, layout, and pricing.
Also please add some advanced exercises!
And before the "but it is already on your server!" You know what else is installed on almost every *NIX server? Nano. A text editor that needs no deep introduction to be productive or that you have to reconfigure basic keybinds like the arrow keys "because it could break a system not used since the 1970s!"
I know Vim well, I've used Vim a lot, still don't understand the strange obsession people have with getting others into it. You want some professional advice? Don't learn Vim, learn Nano, and use the time you saved to learn VSCode better.
[0] https://insights.stackoverflow.com/survey/2021#most-popular-...
For me, the most useful part of vim is that once you learn how to use it, you can switch text editors without needing to relearn most of their shortcuts.
Last time I tried za and it didn’t work. These extensions stop right at the impedance raising point, it’s something you should know beforehand.
Jetbrains editors have by far the best implementation, but it's not there and I don't think it's possible, due to inherent lag
I suspect some variation is the same for many; it's a likely driver of demand for vim bindings (which are ubiquitous).
Even if people's daily usage of vim is much lower than their GUI-IDE of choice, the aggregate is likely far higher than reported.
> Which development environments did you use regularly over the past year, and which do you want to work with over the next year? Please check all that apply.
Pretty fair question if I've ever seen one.
One case where I find a mouse/trackpad essential: editing LaTeX documents. Being able to control-click to jump between a spot in the compiled .pdf and the corresponding source code, or the reverse, is invaluable (a feature supported in TeXShop, for instance). I realize that one can probably set up a similar system in vim. But, the appeal of vim for me was that, at the cost of learning a bunch of arcane keyboard shortcuts, I could go mouseless and as a consequence be faster. If I'm going to keep the mouse, the value proposition seems a lot worse.
Source: my experience of using vim for the last ~20 years
The other editors do not involve any learning if you don't learn anything about them, Vim involves a lot of learning if you learn most of its features. However to use Vim in the way you present the other editors, you don't have to learn much at all, arrow keys work, the gui version has window menus for most options.
Want to use Vim without the learning? i to insert, ESC to go back from insertion mode, arrow keys to navigate, there you are, you are basically using Vim at the level that you want people to use other editors.
If I want much more than that I'll have to learn the features and keybindings of the other editors too. Last time I checked the knowledge of how to search, split panes, switch buffers, search and replace etc. wasn't magically inserted into my brain as soon as I open my copy of VSCode or Nano.
> you have to reconfigure basic keybinds like the arrow keys
Since when do arrow keys not work in Vim by default?
Learning all of Vims features vs. learning only the minimum in other editors is not a fair comparison.
Whereas, trying to do pane-like things in vim requires Googling (more efficient in my experience than trying to use the built-in manual) and then reading some stackexchange answer that devolves into a philosophical discussion about the merits of buffers versus tabs.
Alright, that aside, when all is said and done I think a lot of people just want to edit their file. Parent comment about having to go to Google to do simple things makes a good point, and the response that "actually, I think having to read a bunch of troglodytes arguing with each other on Stack Overflow is an important part of the experience" is the kind of thing that makes it hard for everyone else to take vim fanatics seriously.
Soon or later you have to reach for the mouse to scroll through the browser, or change/rearrange windows, even with all the fancy Vim plug-ins.
And you're bang on wrt nano existing everywhere vim does!
But if you don't care about that aspect, I agree with you, just stick with the boring thing that works. I don't think vim really saves me much time in the long run, but it sure makes my daily tasks more fun.
If my professional opinion, learning vim or emacs will give you a tool that will last you several lifetimes and can grow with you as you customize it to your specific needs.
The reason someone might advocate for its adoption can lead to greater availability (this is why there's a vim mode in pretty much every other text editor). Or they think it's a better way to edit text and want others to experience it. I would love if I could edit text in everything as I do in vim because editing text in the more "intuitive" way is slow and clunky and frustrating.
I think what's more peculiar is the strange obsession people have with dumping on vim or on the people who are advocating for its use. It reads as petty and insecure.
I realize my experience is n=1, my editing needs might not by typical or generalizable, etc. But I do think it is important to push back a bit on vim boosterism.
> I only want to save other people the same trouble.
Pick one!
To be frank, it's annoying to go to a HN comments page and find the inevitable "popular tool x sucks because I didn't like it" comments. It seems like they're everywhere, on every link about every tool or product on HN. It's a buzzkill. Of course not everybody is going to like Vim. This link isn't trying to convince anybody of anything, it's just there for anybody trying to learn.
Your lack of proficiency in vim does not mean it is fundamentally slower.
I learned vim to, say, like, a low-moderate-ish proficiency? Basically forced myself to use it everywhere at work and home. After a few weeks of this... I went back to just vanilla IDEs/Editors.
For me, it was just a mix of not liking some stuff being handled in vim bindings and some stuff being handled by the IDE's bindings. I'm sure there's a bunch've plugins or customizations that'd smooth it over, but... vim also made me realize, I'm a pretty meat and potatoes text editing kinda guy. I like to shift lines, expand selections in a context aware way, and copy/paste. When I split panes, I do it with the mouse like a cave man. So the bulk of vims power was either lost on me, or felt like it got in the way of my minimal needs.
Also, I pretty much never ssh onto an individual machine to edit anything substantial these days, so... the selling point of having some bedrock transferable "everywhere" skill is kinda moot.
[0] https://nrf.com/resources/top-retailers/top-100-retailers/to...
Honestly if an editor doesn't have VIM mode, I don't use it.
20 years ago, this list would have had a bunch of different names on it.
20 years from now, it will be different names still.
Meanwhile, vim will still be there, and my knowledge in it built 20 years ago will be serving me still 20 years from now.
> you have to reconfigure basic keybinds like the arrow keys "because it could break a system not used since the 1970s!"
Never had to do that on Nixos, Ubuntu, Amazon Linux, RHEL, MacOS or WSL
For my workflow with lots of context switching between code and commands, using only a terminal is more efficient use of my time. VSCode cannot do that in a way that works for me
But ignoring all of that, many use [neo]vim because they simply enjoy it. Enjoyment does not need justification
Here's some other professional advice: people liked vim because it is modal, that means the coding process itself can be automated, scripted on, insanely fast and can completely forego mouse/touchpad input.
Vim bindings by themselves are great, but they are not fully vim, for instance, most vim bindings including this website does not support `:norm`
I don't begrudge anyone that says "wow, I don't want to take the time to research every damn feature of my IDE, just let me work", that's totally reasonable, and any of those IDEs will let you get the job done - for me - the time invested is worth it because of how much of my life is spent editing files on my computer.
This is an artifact of the structure of the question. They're not asking what you use the most, they're asking what you use at all. Check all that apply.
So then you check Notepad++ even if you're a Linux developer who primarily uses vim or emacs but have Notepad++ on your rarely used Windows VM. You check Visual Studio or VS code if you had to contribute to an existing project which is tied to its build system, even if you avoid it whenever possible.
A quarter of all developers use vim. That's not a small number and it's not for no reason.
This is indeed not a good reason to learn Vim nowadays indeed. Vi has more chance to be present than nano on a stripped image by the way but I digress.
For me Vim started to make sense when remote work has begun to be the new normal. VPNs make with remote desktops make everything slower. I worked in places where we had to use two VPNs at the same time. Then I saw the hacker wizard kid using vim like he was Edward Scissorhands and how much more productive he was.
Especially true now, with so many reasons not to use it AND the sufficience of :help and vimtutor for the rest of the reasons.
I find that the best teacher in this case is a necessity. Find yourself on a basic command line with no nano or the likes, just good old vi, not even vim. Then go on with that important mission you're on! Traumatizing? Yes, but a chance at adaptation too.
I handily accept that I don't know a big part of vim. At the same time I use it daily and went as far as developing vim script to automate stuff that are repetitive to me.
Vim bindings are quite easy to pick up and fairly straightforward though, but that should just take a cheat sheet and some usage.
Another super simple example is replacing a word. Let's say I know how to delete, how to word, and how to enter insert mode. Putting that together I get dwi - except using cw achieves the same thing.
Now, almost every single key has it's use and I likely only have muscle memory on about 20 keys, when it gets to the vim command line, I know even less. But I'm not quite worried about it.
EDIT Found it! This guy is brilliant. http://derekwyatt.org/vim/tutorials/index.html
Edit: There are a lot of great Vim videos on thoughtbot's YouTube channel, too.
And a confession - I probably only use 25% of what its capabilities are. And some of what I do is totally "wrong" like when not inserting I use K for up, Enter to go down and space to go right. If I want to go to the beginning of a line, I hit enter (down) which takes me to the beginning of the next line. Then K (up) to get to the line. Totally "wrong" but it's what I've done for years and do it without even thinking about it.
It kind of brings to mind this bit from the first Perl State of the Onion...
"...I believe that learnability is a laudable goal, but frequently misplaced. The purpose of a language is not to help you learn the language, but to help you learn other things by using the language. We don’t water down English to make it easy to learn. We prefer English to remain a rich language, quirky, sloppy, and full of redundancy. Same for Perl.
A corollary to that is, while we don’t water down the language itself, we do allow people to speak subsets of the language. We don’t expect a five-year-old to speak with the same diction as a fifty-year-old. We don’t expect a native German speaker to use the same subset of English as a native Mandarin speaker. Similarly, we don’t look down on people for using subsets of Perl. There are certainly enough of them. You can write Perl programs that resemble sed, or awk, or C, or Lisp, or Python. This is Officially Okay in Perl culture. By way of contrast, try writing in the C subset of C++ and they’ll make a laughingstock of you."
I don't think there is any point in using vim over an IDE but it is often quicker to edit config files in vim or navigate text so I use it for that.
Some people prefer guided tutorials that give you direct feedback (e.g. correct / incorrect).
Vimtutor is perfect for self-guided and self-motivated
Lots of complaints here boil down to "I can't [insert IDE feature here, e.g. use a debugger]". Of course you can't. You'd have a bad time using a hammer to put in a screw, too. But you can sure use a hammer to put in a nail.
If you want text editing, use vim. If you want an IDE, use Emacs, or VSCode, or whatever. Just don't complain about the hammer when you actually need a screwdriver.
Open up terminal
vimtutor
Enjoy the tutorial
https://mobile.twitter.com/vasudevram/status/124858356689776...
Maybe one challenge in grasping it is that if you look at any one feature in isolation, it sorta looks like a negligible amount of time savings (if at all), and at the cost of weird key combinations. So maybe instead imagine if you took the top 200 common actions you do when editing code and recognize that over your career you might perform those actions many, many millions of times. Now shave 100ms to 5000ms (or more in some cases) off of each one.
I dunno if that helps, but anytime I have to use something other than vim, it's incredible how slow and tedious it is to do even the most basic things, and it feels exponentially worse with any sort of bigger editing tasks.
Boo!
Seriously though, love the project!
which you can't do because you can't leave the first one
It's just our minds don't work that way when thinking about editing text. The way I view text is visual. I don't think in terms of delete 4 lines, go line 435 and dw to delete a word. Copying and pasting text is a nightmare. Navigating from insert mode to visual mode to select and paste text. It's impossible to design a less intuitive text-editor.
The thing is that you can do both in Vim. 4dd is faster but harder to learn and commit to, it's not in any way required though and you can stick to vim basics and go the regular select and delete route too (via mouse, v, etc.)
Some people consider this a bug, others consider it a feature.
I use both VS Code and (Neo)Vim on a regular basis. A huge advantage of VS Code is that for many languages, it works pretty darn well out of the box. I do a lot of ECMAScript development, and I have exactly two extensions installed for VS Code: ESlint and GitLens (plus some themes, but I don't consider those functional). My init.vim file is nearly 400 lines long, and that includes everything to provide a reasonable IDE-like experience (fuzzy finder, Ctrl-P, NerdTree, Airline, Git, various mappings, etc). Granted, I did not type all 400 lines (that is, they are copied from other user's configuration files), but I still stitched a lot together. And that's fine, for me. I get that some people don't want to spend their time tweaking their tools to that degree. VS Code is still a convivial tool[0], in my opinion. It simply starts from a different place.
> Now, why exactly would I want to go into edit mode to type 4dd to delete 4 lines instead of select and delete.
Because it's faster and more flexible.
> The way I view text is visual.
Vim allows you to select text easily. For example V4j will select this and the 4 lines below, vi{ will select all lines between curly brackets and vt( will select characters from this up to the character before (.
> Copying and pasting text is a nightmare.
Copying and pasting text is a bliss.
> It's impossible to design a less intuitive text-editor.
The learning curve is steep for sure, but with a little bit of effort you will edit text in a more convenient, flexible and faster way than before.
Intuitiveness (or lack thereof) isn't a strong reason for dissuading use of a tool that you'll be using over a lifetime. Any tool you're using that you hope to be competent in requires learning and practice to become proficient in.
> It's just our minds don't work that way when thinking about editing text. The way I view text is visual. I don't think in terms of delete 4 lines, go line 435 and dw to delete a word.
Visually, if you want to delete a paragraph, how would you go about that? In most text editors you might grab your mouse and click on one end and drag through to the other end of the text and press backspace. In vim you can just tell your editor to delete the paragraph. Or maybe you want to change what's inside the parentheses, so you tell your editor you want to change what's inside the parentheses and you do that. If anything, the 'normal' way of text editing has almost nothing to do with how my mind models editing text while vim allows me to tell the editor exactly what I want it to do and it performs it.
That's the problem with telling the editor to do exactly what you tell it to do. Telling a machine to do exactly what you want is programming. For text editing doing what I want with 95% percent precision is more than enough. If that fails I can press CTRL + Backspace to delete few more words. How would you delete a paragraph in vim? I reckon something like:
1) Visually see the line where the paragraph is
2) Jump to that line with 100 gg
3) Run another command to delete the paragraph. Now again some thinking needs here is it a code block between curly braces {} or is it a textual paragraph but why is that thinking required when I can actually see it in front of me and select it.
4) Get back to insert mode
In a normal text-editor:
1) Visually see the line and select it with cursor and delete it.
I think more experienced vim users would use "dip" for text (<d>elete <i>n <p>aragraph) or "di}"/"di{" (<d>elete <i>n <brace>) for stuff in braces.
If you want to change something instead? "cip" (<c>hange <i>n <p>aragraph) or "ci{"/"ci}" (<c>hange <i>n <braces>).
> Now again some thinking needs here is it a code block between curly braces {} or is it a textual paragraph but why is that thinking required when I can actually see it in front of me and select it.
There is almost no overhead to performing this action when you are even modestly proficient in vim, no more than the cognitive load it takes you to decide you must use a mouse to select that portion of text, which also requires more precision since you must accurately place the cursor both at the start and end points.
`dip` will delete all contiguous lines (ie: lines between blanks) `cip` will change in paragraph, (delete text and then put you in insert mode)
Here's another one: if the cursor is in the middle of a line, and you want to delete the rest of the line to change it, do you click and drag the mouse? Our do you hold shift, press down, backspace, and then press up again to get back to where you were?
I just press `C`
The vim "every key is a command" mode is called `normal` for a reason
Please speak for yourself, sir. I do 2-5 line rearrangements and jumps very often and hate to do “home home shift+ down down down shift- ctrl_x scroll scroll scroll scroll …” instead of “4dd'a”. When it’s hard to count lines, you can “V/something<CR>” or “V30j” and adjust with jk to select more or less. When it’s a block, “%v%”. Vim always has less-movement ways even when you can’t calculate precisely and my mind can’t work in a “wait for 50 key-repeats” mode.
But I’ve felt what you’re describing at the time when my knowledge was shallow and I didn’t really know the essential part of vim.
It's impossible to design a less intuitive text-editor.
This one I agree with.
Like everything in the software world, because some Google engineers used it, it became world wide famous. There's a saying in german that I love, basically amounting to, "they also cook with water". In short, there is no real tool that has "secret sauce" or is "super magical". It's an editor, that's all.
Say what you will but nano is is fine for me via SSH, VS Code for everything else.
Looks like many of the comments take a similar stance, which I'm actually surprised at.
The rest of your post is fine though. You do you :)
I'm skeptical to this claim because vi/vim's widespread usage predate google itself, by decades. It used to be the only way to really edit something in the 1980s on unix systems, unless you preferred ed.
Vim's modal system extends way beyond some special cases. The most time save I have using it are probably not fancy stuff but quick movement across lines and within lines.
Use whatever tool works best for you. I use vim because it is far and away the most efficient way to edit text - especially code. Anytime I have to use something else it's amazing how sluggish and tedious it feels to do the most basic operations - it feels a lot like trying to run in knee-deep water. I've extensively used many (most?) of the major editors on the planet (including many obscure ones) over several decades. I had to be forced to use vim at first because it seemed so terrible. Believe me, it's not my editor of choice because of some randos at Google, haha.