This course came about as a result of wanting a more targeted way of practicing using new vim commands I wanted to pick up, rather than just trying to use them in my regular code editing sessions. When I would try to use new commands during code editing, my productivity took a hit because I was trying to do two different things at once: thinking about code vs practicing my muscle memory.
So, I made a separate environment for practicing, one that had an interactive editor, progress tracking, and achievement goals to let me see which areas I should work on, like speed and efficiency (# of keystrokes). When I realized it would be useful for beginners too, I added lessons to go along with it and this course is the result!
Let me know what you guys think about it :)
I feel like vim tutorials mostly focus on navigating and editing a single file, which is great! But I mostly struggle with how to replicate opening a whole directory in VSCode, which makes it easy to browse the directory, switch between files, open multiple panels, etc.
I'm almost certain vim does all these things out of the box, but tutorials always end at "this is how you edit some text quickly" and never cover "this is how you do software engineering".
So I have the same issue as you, I really like using neovim for smaller projects as its easy to work on them through the shell. But when it comes to big projects I go back to VSCode with the Vim emulator extension as it just makes using the tree much easier for me in VSCode. I have setup custom keybindings and settings to launch the directory when needed or the command palette works great to launch other files. I wish there was a resource to help switch VSCode to neovim while retaining some of the "most" used VSCode features.
:set nu
/ whatever you want to find [return]
i
*edit stuff and use arrow keys for nav*
:wq
Or :q to quit without saving
The fact that less is installed on many more systems than nano is a testament to the bad assumptions too many devs make about who will be using these systems in the future. And yes, it’s not hard to "apt -y install nano" except at work where we have proxies and internal repos, so now I need to use vim to reconfigure apt sources just so I can use a more normal editor that doesn’t require arcane incantations to perform basic config file editing.
It's also derailing someone's Show HN with a very old and generic online argument.
Prepare and paste this into your terminal:
echo "another line" | sudo tee -a /etc/apt/sources.list
The frustration is that probably there are fixes for all these things, which if I were an expert I would know. But meanwhile I can use an ordinary visual text editor and I don't have to learn anything new.
The modal nature of Vim is one of it's key features and makes a lot of sense. If you consider the keyboard the primary, if not singular, means of interaction, then there will be times you want to use the keyboard to type text and times you want to use the keyboard to control the editor behavior. In a "normal" editor, you have to use modifier keys to enter commands. In Vim, you do it by changing modes. It's actually quite powerful but you can't get past your own assumptions about efficiency.
Is that a fact, or you just parroted other people who made similar claim?
> Also, why do I have to have a special mode to insert things?
First and foremost Vim is a modal text editor. If you don't like that Vim is probably not for you. Your comment is kind of like saying I'm really trying to like chocolate, but I don't like the flavour.
There's a Vim way of doing things, if you really take the time to learn it then the questions you are asking will all be resolved.
I do, I hate accidental wrapping on left/right so much and see absolutely no use to it.
But you may configure it, :help 'whichwrap'
Also, why do I have to have a special mode to insert things?
Because if your alphabet keys do always insert, you have to hold some control key to enter commands and movements, and not if not. That’s the point of being modal. Otherwise there are plenty of emacs-alikes to train pinkies on, and no need for yet another notepad+.
No, because those are features, not bugs. If don't want them - you don't have to even think about them.
>Like, why can't I hit right at the end of a line, and move to the next line? Who thinks that is a good idea?
It's not that you can't. The idea behind vim-like navigation is that you don't press those arrows (or hjkl for that matter) in a consecutive manner (or hold) unless you really have to. 99% of the time you jump to some place in the text (a character, or line, a word, a nth line etc).
Funnily enough, Vim is short for "Vi IMproved", and its predecessor vi is short for "visual"!
---
Taking the time to learn Vim yields significant rewards if you're willing to meet it on its own terms. I certainly grant you that it's not for everyone. It's the agony and the ecstasy of deep tools. No pain, no gain.
> The frustration is that probably there are fixes for all these things, which if I were an expert I would know.
I would submit that if you were an expert, you would not have the same list of gripes. To wit:
> Like, why can't I hit right at the end of a line, and move to the next line?
This is a fair complaint, but one that's actually never occurred to me as a Vim user, because:
> Why do I have to have a special mode to insert things?
It's a core part of Vim's design! In fact, insert mode is The other mode (Normal mode) is where the real power is. It's not so much about moving chunks of text around with the keyboard as about moving the cursor.
Vim divides normal mode key commands into motions and operators. operators add/remove/change text, and motions move the cursor.
For instance:
- `d` is an operator deletes text.
- `w` is a motion that moves the cursor to the start of the next word
- `12w` does this 12 times (practically every motion can be repeated like this)
But the rubber really meets the road when you combine them.
If you hit `d` once in normal mode, nothing happens: you've started a command but Vim is waiting for you to finish it by entering a motion. `dw` deletes from the cursor up to the start of the next word (you can guess what `d12w` does).
> And why does the help system never tell me what I want?
Perhaps start with `:help help` :)
set -o vi
And get vim in your bash shell. Then you wonder what the default mode is, and it turns out it’s emacs and you can do wild things like ctrl-A to go to the beginning of the line.
And now I cringe when ever I see someone painstakingly left-arrow for 30 seconds to edit something at the beginning of their bash prompt.
I know this is probably something that sounds like someone too far down the rabbit-hole to see where they came from, but I'm not sure why you'd want to do that. The horizontal movement is probably adjacent to the vertical movement on your keyboard. Just use the appropriate movement to get where you want to go?
> Also, why do I have to have a special mode to insert things?
Because then you can use the regular keyboard, i.e. keys that would normally insert characters, as control inputs.
> But meanwhile I can use an ordinary visual text editor and I don't have to learn anything new.
You don't have to learn anything new because you don't want to do anything new.
You're absolutely right. You do sound far down the rabbit hole! I am used to being able to hold down the right key and traverse my entire document, as far as I like. Why would I want to stop at the end of a line? Any time I'm editing multiline text - like, say, English - that is essentially arbitrary.
The regular keyboard... right... but what if there were some kind of special key that could be pressed to issue controls? Why is that worse than having a special key that goes into control mode? This is analogous to having caps lock, but no shift key.
Again, you're right, I don't want to do anything new. Why would I? I want to get on with my job. If the response to my complaints is "the problem is with you, my son", without any idea of the ultimate benefits I might gain from changing, then yeah, I'll pass. Honestly, this applies not just to you, but to all the responses below... they're all like "if you try it, one day you will understand". That's probably what people say about Morris Dancing.
What do you mean by this? Do you mean the right arrow key?
The mode paradigm was definitely weird to me too at first, but it eventually makes sense, especially when you start using macros.
I agree about the help system - it hasn't been very helpful to me either. I usually am better off consulting stackoverflow or vim's wiki for how to do something.
Vim took me quite a bit of time to learn beyond the basics, but once I learned it, it became a productivity boon. It's nice to have the same powerful text editor available wherever I ssh to, right in the terminal, in the same place I'm using all my shell commands.
You don't really move a caret around in vim, you process units of text and lines.
set whichwrap+=<,>,h,l,[,]
Source: https://vim.fandom.com/wiki/Automatically_wrap_left_and_righ...
Then do that?
:h whichwrap
Wish I had the time to improve on the course I launched but I ended up starting a company shortly after launching my course and getting into YC.
(This is basically a copy-paste of previous comments I’ve made, I haven’t tried your tutorial beyond the first lesson.)
If you're going to disable the mouse and the arrow keys and really commit to the home row, more power to you. That is probably the best way to master Vim. But I think a significant number of people looking at Vim tutorials have never used the editor, and I think they deserve to know that there is an easy way to make the editor more comfortable and more familiar.
Someone down-thread used a metaphor to say 'the best way to learn a new language is by immersion' which is something I would agree with. But opening Vim for the first time feels like being dropped into a foreign country where no one speaks your language. Imagine how frustrated you would be to find that the people there actually do speak a language that you know, they're just refusing to understand you because you haven't issued the magic words, "set mouse=a"
Having mouse support gives you a superset of functionality. Often this can be useful, like if you have on your hand on the mouse using another application.
Saying "why even bother" using vim if you add features just makes no sense.
I felt the same way when first learning vim, since it was completely different from the code editors I'd used in the past, it was strange not being able to use the mouse in the way I was used to.
Although, it would help to show beginners exactly why abandoning the mouse will be better in the long run. It wouldn't do well for them to always rely on it in place of more efficient commands. Some people might always use the arrow keys instead of hjkl, for example, when hjkl will be better in the long run since they are on the home row.
A key ethos of Vim is that once you climb the initial learning curve, you're on a path of increased efficiency for the long haul. Moving the hand to the mouse, dragging the cursor to the spot you want, then moving the hand back to the keyboard, is objectively slower than key-based movement commands for someone who has climbed the learning curve and I'm confident that could be proven empirically though I'm not aware of any such proof. There may be certain exceptional cases where the mouse is faster, but for most editor usage it would not be. I'm not sure if you agree w/ that and are just criticizing how tutorials introduce people to Vim, that they should start w/ the mouse to lower the learning curve, which might be an okay argument.
I’ve been using Vim as my primary editor for 25 years and at this point the keyboard nav is burnt into me.
I still use two finger scrolling on my track pad though. If I’ve been in another window I might also start the cursor at a point with trackpad.
It works fine over ssh too.
I think most newbies that care enough to try Vim know there is a Vim Way. They know about Vim Golf.
That get tiring all the time when you’re starting out. Sometimes they just want to get the job done until they learn, I’m ok with that. Just have a go.
It’s absolutely fine to make use of all the features Vim provides and use it any way you want because you’re always going to me slowly learning more.
I tried to explain the benefits of vim in the "Why Vim?" section, but I should really go into why using and learning vim will be slower at first than using the editor you're already comfortable with, and how it might be worth it in the end.
Thanks for the feedback!
I bet I could untrain with sufficient work but it's no longer worth it.
Also, I think scaring people away from arrow keys is premature. It's not that big a deal.
But the worst part was making Vim provide with things that you'd expect programming editors to have. So many options, what's best is up to opinion, integrating language servers, getting intellisense to work as you would expect, searching the project folder for file names.
Then I realized that all I'm trying to do is make Neovim behave like VS Code with the extra addition of keyboard navigation, which I can get behind. But at my current career level I'd rather spent those 5-10 hours configuring an editor in learning more about <insert whatever language/framework I'm learning>.
I mean, just another Vim introduction when you already have the free options (vimtutor etc.) and FEM's "Vim Fundamentals" won't fix my pains with getting it to work as I'm expecting it to work.
So 10 hours on a config is only .5%, which is the productivity gain you need to realise to get that time back in one year (assuming you also spend 0 hours on fighting vscode).
Unless you're retiring within the year, that calculus doesn't make sense.
The productivity boost you get with from Emacs/vim is huge once you learn it well.
I strongly believe that learning one of these two editors is probably the easiest and biggest skills leap you can take as an intermediate or senior developer.
No other skill you can learn will have as big of a payoff to your productivity given the relatively small effort to get proficient.
https://github.com/vscode-neovim/vscode-neovim
I highly recommend this if you know vim keybindings and want an IDE experience.
Frequently I find myself frustrated that I can't undo exactly what I need to, and it ends up undoing more than I want it to. I never had this problem with vim but with vscode, I probably experience it once a day.
https://github.com/nvim-lua/kickstart.nvim/blob/master/init....
It’s been a few years since I last tried so hopefully this has improved. I tried the vim plugin for Jetbrains and found it lacked window navigation and support for things like registers that I use a lot in vim.
At the time I was using webstorm (at a client’s insistence) and found that for the weird JS project we were working on Tern.js was actually better at refactoring and navigating anyway so I just went back to using it with Vim.
You aren't always able to use an IDE.
You aren't always editing code.
You also don't have to wait on an IDE to support your language.
Short version: vim is not vi.
Longer version: I use vim because I am way faster with it than any standard editor. I personally barely customize my vim at all, but there is a large community whose hobby is installing dozens of plugins to turn it into a full IDE and/or making it a highly personalized experience.
Exception being spacemacs/evil, which is why that's the only thing I prefer using over vim
I believe when vi was originally created, the Esc key was often placed to the left of Q, where the Tab key is now located on QWERTY layouts.
I used vimtutor and openvim to get started, and they're fantastic free resources.
It was only when I couldn't find something to fix my specific problem that I stated in the top comment, did I start building this.
One day I asked myself: Is there a way to scroll in the browser without using a mouse or arrow keys?. Enter Vimium.:)
I have tried in the past Emacs, but I have an operating system, and I don't need a new one (for now). So now you can take MacVim only from my cold hands. P.S. > You can paste the buffer in insert mode with ctrl+r+0.
> Vim forces you to glue together lots of inefficient commands to manipulate text
> Vim’s nasty bells and whistles you need to actually be efficient at manipulating text
I'm not really good at css though, so there's that.
One thing that I still need though, is proper syntax highlighting. I wish there is an easy way for vim to do it rather than just too many plugins here and there.
1. Prefer sftp over scp whenever it's available. The scp protocol is pretty obsoleted. Just substitute `scp` with `sftp` in the command.
2. Turn on ssh multiplexing to drastically shorten the wait time when opening a file.
In addition to surround, what other plugins do you think beginners should almost always use?
There are actually 34 lessons right now (you can see the lessons if you click on the chapters to expand them).
Please let me know if there are topics that you want to see, I wanna add what people want to learn!
Same as the last time you posted it: learning Vim has nothing to do with muscle memory and doing it outside of Vim is pointless. Plus, the "master Vim" claim is dubious given how basic the lessons seem to be.
:help user-manual is easy, built-in, and it goes way beyond this. And it's free.
>Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
> learning Vim has nothing to do with muscle memory and doing it outside of Vim is pointles
He fairly expressed his opinion of the OP's project. I don't agree with this opinion, but let's not be such snowflakes. The commentator did not insult the creator.
I used vimtutor and openvim and they were great starters!
It was only when I tried to find something to fix my specific problem that I stated in the top comment, did I build this.
See this definition for muscle memory from Wikipedia:
"Muscle memory is a form of procedural memory that involves consolidating a specific motor task into memory through repetition, which has been used synonymously with motor learning. When a movement is repeated over time, the brain creates a long-term muscle memory for that task, eventually allowing it to be performed with little to no conscious effort. This process decreases the need for attention and creates maximum efficiency within the motor and memory systems. Muscle memory is found in many everyday activities that become automatic and improve with practice, such as riding bicycles, driving motor vehicles, playing ball sports, typing on keyboards, entering PINs, playing musical instruments, poker, martial arts, and dancing."
I don't see why Vim commands would be any different from typing on keyboards, or playing a musical instrument. They are tactile, and rely on motor control.
> and doing it outside of Vim is pointless
I see no reason at all why this should be true. Does the tool let the learner use keyboard to practice memorizing the commands, and they produce the exact same effects as inside Vim? If yes, then by what claim do you say it is pointless? A claim that this tool isn't "the real Vim" feels like a "no true Scotsman" fallacy.
This whole comment reads like sour grapes. Are you mad that it isn't free? Just come out and say that. Perhaps reference Socrates, and how he was angry at the suggestion he charged money for education. Or just point out the free resources and leave it at that. No need to attack him so strongly.
And before someone else says it, yes, I wrote a book about Vim, and no, it isn't free ;)
They are not tactile and they don't rely on motor control. It's typing them on your keyboard that is tactile and relies on motor control. I make use of muscle memory to type these words, not to decide what to type. Learning Vim is learning how to decide what to type, learning how to type it or to type it quickly is just learning typing.
The "memory system" mentioned in that quote is definitely involved in learning and using Vim but the other "system" mentioned, the "motor system" only deals with _typing_ things. The real hero, here, would be the "language system" in charge of assembling commands.
> I see no reason at all why this should be true.
And yet it is.
> Does the tool let the learner use keyboard to practice memorizing the commands, and they produce the exact same effects as inside Vim? If yes, then by what claim do you say it is pointless?
The learner can do all that within Vim itself so why do it outside Vim, which is freely available and comes with an extensive yet very approachable tutorial that goes way beyond what is offered in those online knock-offs?
Again, the tool in question only seems to cover very basic topics that are not going to help anyone "master Vim" anyway so why bother with it at all?
And again, learning Vim, let alone "mastering" it, has nothing to do with muscle memory and rote learning at all.
Vim itself comes with everything one needs to learn it. Learn Vim in Vim.
> Are you mad that it isn't free? Just come out and say that.
Well, I noticed that it went from $25 to $10 between posts. Who knows? Maybe it will be free by the third repost? Whatever the cost, the claims are false and there are much better ways to learn Vim anyway.
> No need to attack him so strongly.
Persons curious about Vim don't really need to be fed outlandish claims and promises one can't deliver either.
I agree with your point about muscle memory. Learning !== muscle memory. However it does make it more comfortable to edit code by not having to expend energy remembering the vim command to do something (since you can just focus on editing code). Practicing new vim commands in the interactive editor has helped me use them faster when coding. I feel that my muscle memory is built faster when practicing in a targeted way.
The interactive editor aims to bring the skills you develop while practicing in it, into your daily code editing, by making you practice on code snippets (for all the lessons after the first 2).
In addition, in my opinion, vimtutor and :help are slightly difficult for a complete beginner to parse because they overwhelm with a little too much information. I tried to fix this by making each lesson focused on a single topic, with short and simple explanations.
Thank you for your feedback, I appreciate it!
An issue keeping me from wanting to use this: holding down the directional keys doesn't move the cursor multiple times - it's one keypress per movement. In the desktop environment, one can hold 'j' to go down, and since there is so much vertical movement, it's important that that's replicated.
If only Vim itself was an interactive editor.
> In addition, in my opinion, vimtutor and :help are slightly difficult for a complete beginner to parse because they overwhelm with a little too much information.
Except I mentioned :help user-manual, which is built-in and offers a very gentle, progressive, learning curve. Not overwhelming at all.
Vimtutor only introduces the basics and :help, assuming you mean "the reference manual" as opposed to "the user manual", is not suitable for the first steps of learning at all: most of it is really just a reference for when you are not quite sure about the specifics of a command or function.
> I tried to fix this by making each lesson focused on a single topic, with short and simple explanations.
Not much more than the user manual, then, and judging by the lesson titles, quite less.
It is really good for remembering shortcuts for regular desktop applications, but I felt that it wasn't really meant for learning a code editor like vim.
It did not have an interactive code editor, with the ability to edit lines of code inside of it. In addition, it does not measure progress in terms of speed and # of keystrokes, so you aren't able to see how you could improve. If I recall correctly, it is just meant for remembering the command keystrokes and typing them out (kind of like using flashcards).
Also, as of right now, shortcutfoo is $8 monthly, but it allows access to all shortcut courses.
Please correct me if I'm wrong, I used shortcutfoo a few years ago.
It would be difficult for a lot of people to say they've fully learned vim though, since it has a lot of things to discover. Many people who've been using vim for years still find out new tricks. This aspect of vim is appealing, in a way.
Besides that once you learn that you enter edit mode by pressing i - ESC to exit it. :w to save, :q to quit and :q! to force quit / quit without saving. Then you can get by just fine.
You can of course do magic with vim, but that's more in the tinkerer territory~
You gain access with the email you use to purchase (the buy button is all the way at the bottom, which I could with improving its location). Thanks for letting me know!
Congrats!
I also paid for https://vimvalley.com/ and am a satisfied customer.
However, if you've seen people use it in real life or in youtube videos, and think that it's cool being able to execute precise and fast commands without needing to move your hands from the keyboard, to edit code exactly how you want to, definitely try it!
This is the price we pay for having easy-to-use computers. People have developed an expectation that everything should be easy and if it's not easy for beginners then it's bad.
Some things are just hard! That doesn't make them bad. Some of the best things in life actually take years of study to learn.
If you're using a tool for 8 hours a day, everyday, for years, you won't be a beginner for very long.
The program must be optimized for the people who are going to use it for thousands of hours. Not for the users who are heard about vim yesterday.
Tools which are eminently transparent in how you use them are great to get started, and to continue with if you don't want to spend any more time.
But so are tools which you need to actively invest effort into using. These can unlock ways of using something which are more powerful and rely on the time you put in to learn them -- true for a computer, but there are plenty of other devices in the world where this is the case too.
I'm not really in this camp though, I would prefer vim commands to somehow be more "discoverable".
Much easier said than done, though.
Edit: hmm, can't find any errors. Can you reply with the first 3 letters of your email? You can also contact me via the email located at the bottom of the page.
1. I switched to :autochdir, so that in any buffer, the current working directory is that of the file. Then I dumped :autochdir due to certain annoyances and found a nice way of emulating its good behaviors.
2. I started using sessions to save and recover the states of the buffers. I associate sessions with certain tasks and can return to those tasks quickly.
3. I started using a buffer navigator.
Regarding (1) here is the setup:
:let $top=getcwd()
:au BufWinEnter * exec "lcd " . expand('%:h')
:au BufWinEnter * if expand("%") == "" | exec "lcd $top" | endif
:au BufWinEnter *.git/* exec "lcd $top"
The $top variable captures the top level directory on startup; I refer to it in command lines when I need it using $top. Why the dollar sign? Ah, this makes it an environment variable. Vim is much better about interpolating environment variables than other variables; there are more places you can use them thanks to the dollar sigil.
The other three commands above set up a local chdir (lcd) to the directory of the file containing the buffer. The third rule is smart: if we are editing something under .git/ then we go back to the top. This is what autochdir gets wrong. What do we edit under .git? Oh, COMMIT_EDITMSG, for one thing! I want to be in the repository root when editing a commit message.
Regarding 2, here is my setup for working with sessions:
:nmap + :wa<Bar>exe "mksession! " . v:this_session<CR>
:command -nargs=1 S exec "mksession! " . expand('$top/') . expand('<args>')
Regarding 3, there are many buffer navigators. I'm using bufexplorer (version 7.4.32). I make the following tweak to the plugin/bufexplorer.vim file:
" added before the other maps
if !hasmapto('BufExplorer') && g:bufExplorerDisableDefaultKeyMapping == 0
nnoremap <script> <silent> <unique> <Leader>\ :BufExplorer<CR>
endif
Mostly I use the LRU view in buffer explorer (most recently used buffer goes to top, pushing others down). Should be called MRU, but everyone who knows memory cache hierarchies understands LRU.
The above three things are very simple, and have a big payoff. I have many more tricks in my vimrc. For instance I use a C program called autotab to analyze a sample of lines from the loaded file and adjust the indentation settings.
Do vim users know if there was anything like Select next occurrence in vim? Feature discovery is not one of vims strong suites
EDIT: More specifically by multi-cursor editing I mean selecting multiple occurrences of a word, and then editing in place. For example selecting all occurrences of the word user -> (getUser, setUserId, variable declarations with user) and then replacing them with account. This can be done with vim but is nowhere near as fast, since every change needs to be done one-by-one. Or selecting all the above occurrences, and pasting them somewhere for an interface declaration.
I'm sure there is a way to do this More Properly, but the kind of thing I'd do is:
:%s/user/account/g
:%s/User/Account/g
If you wanted to check each one interactively, end with gc instead of g.
Vim is the reason I'm real confident with regexes, even nonsense with grouping and quantifiers etc. etc., and while I can see people not wanting to have to acquire that power, I must say it's also very handy outside of text editing.
> selecting all the above occurrences, and pasting them somewhere for an interface declaration.
I don't really understand the behavior desired here, but I'll bet there's something similar.
I agree discoverability is not great; to be honest I can't remember how I discovered the plethora of commands I use, though I do have a habit of reading the help a decent amount. That's how I discovered "g?" (Rot13) :D
As noted in a sibling, you can press * (shift+8) in normal mode with your cursor over a word to find the next instance of the word. This also updates the search pattern so you can use n and shift+n to navigate forward and back between matches.
If you combine this with other bits of the vim "grammar" (which I do think encourages a kind of feature discovery, although I agree there's a large learning "hump" to get over to take advantage of it), you can use something like cgn to change the currently-focused search match, n to navigate to the next search match, and . to replay the command.
So while it's not exactly the same as multi-cursor, you can achieve something very similar (and just as fast) with the following sequence:
1. In normal mode, place the cursor over the symbol you wish to edit
2. Press key: \* (read: "find the next occurrence of the current symbol and update the search pattern to be that string")
3. Press keys: cgn (read: "change the search match under the cursor")
4. Type the new symbol
5. Press ESC to return to normal mode
6. Press keys: n. (read "find the next occurrence of the search pattern [set in step 2] and repeat the last command [the edit from steps 3-5]")
7. Repeat 6 until all symbols are replaced
It may seem complex compared to something like multi-cursor editing, but the nice thing here is that there are concepts here that are extensible beyond the scope of that specific edit, and can yield similar "speedy" workflows but on a much wider set of tasks.
- c[something] is a pattern that means "change [the given region]", so you could construct similar commands with different regions (`ciw` to change inside the current word, `ca{` to change the current curly-bracketed region (inclusive), and so on)
- [something]gn is a pattern that means "[do something] to the next search match", so you could delete it with `dgn`.
- . can replay many types of commands, so if I have a more complex sequence of edits to apply starting at a search match, I could do that too (not just simply replacing the symbol).
It's a very powerful paradigm.
You can press '*' in normal mode to search for the word under the cursor.
Type : and write `%s/user/account/g`.
Although you won't get a real-time preview and will only see the changes after they've happened, unless you use a bunch of extensions(I use nvim).
In Neovim, you can just :set inccommand=nosplit (actually, it's the default now).