Editor’s note: This is the fifth in a series of introductory posts on vim, the super fast text editor. If you’re new to vim then you’ll definitely want to start with the first post which you can find here. This is however a good stand alone post and a great starting point if you’re learning about vimrc’s.
If you’re like I was when I was new to vim, which was someone who was new to everything, then your vimrc is something mystical that you just kind of do what your told with and you’re always moving around with a bit of trepidation and blind faith.
Hopefully by the end of this post I’ll have you all up to speed on a vimrc, what it is, where it is, what it does, and what you can do with it.
What is your vimrc?
Firstly, your vimrc is a file; a special file.
If vim was a cup of coffee, your vimrc would be ‘the usual’. It’s the triple soy latte, half-strength decaf, caramel syrup with a cinnamon stick and two sugars on top of an ordinary long black.
It’s a file that contains initialization commands (we’re getting there) that tell vim how you want it to behave. More specifically, they’re commands that you will want vim to execute every single time you use vim.
Actually, you don’t need a vimrc. You can type all the same commands using command-line mode, each time you start vim. Except that every time you end a vim session, it will forget those commands. However, this could eventually rack up to hundreds of commands that you need to enter every time you fire vim up.
No thank you.
Your vimrc is a place to store all of these commands so that vim can execute them every time automatically.
In your vimrc you can change default settings, fix typo’s automatically, program new key bindings (because even though vim has almost all the most common editing tasks covered, it still knew that individuals would have custom tastes, so it made sure it had your back there too, because that is the wonder of vim), make abbreviations for commonly used long words or phrases, loading plugins, and even more serious and complicated trickery.
Before we even get into plugins and extensions and what-not, you need to know that vim has piles of customization options built right in that you are completely at liberty to tweak and adjust to your liking. Remember in my third vim post I gave you a screen shot:
See the numbers down the left side of the screen? Those are line numbers and they are ‘off’ by default.
It’s probably also a different colour (excuse me, ‘color’) layout to yours.
Both these and many more are things you can change/toggle/adjust using your vimrc.
How do you do that?
By inputting lines of code modifying vim’s default settings using vimscript.
Vimscript is a scripting language for vim. It’s the language of command-line mode commands.
I keep calling it your vimrc, because that’s what it is. It is a file that you write yourself and play with to make vim work exactly the way you want it to work. Once it starts to get bigger, it becomes more and more customized to suit your needs/habits/personality. It will do this because you will be the one who makes it that way. It will become a reflection of your habits and preferences and the kind of work you do most of the time.
If you’re using vim on your own device and for the first time, you won’t have a vimrc; you’ll have to create it. This is as easy as creating any other text file on your computer. If you have already read my other introductory posts (I assume you have), then you’re already pretty familiar with vim, so you can use vim to create it.
Before we do that we have to learn a bit more about your vimrc.
Taking out some of the mystery
Whenever vim fires up, it is programmed to automatically search for a file called ‘vimrc’ in certain locations. If it finds this file it will execute it.
Yes, it does all this automatically, and yes, when you have your vimrc, it will find it and it will work, but it’s not magic even though it all feels a bit mystical at first.
If you’ve been following along, and are a first time vim user, and are using vim on your own machine, vim will be working under the default vimrc called ‘defaults.vim’ found somewhere in your $VIMRUNTIME (this is called an environment variable, I’ll explain a bit about them in a minute).
Sigh. Windows to the rescue again. Actually, gVim on Windows has a _vimrc file already created for you, but it will be empty.
If there is no vimrc, then vim will find the default one instead and use it.
But not for long.
You will be creating your personal user vimrc today (or editing the empty _vimrc file on Windows), and putting it where your user vimrc is supposed to go.
What does the ‘rc’ stand for anyway?
So the ‘rc’ part of vimrc actually is a bit mystical. There has long been a lot of speculation about possible names for this acronymish subscript including ‘runtime configuration’ or ‘runtime commands’ or a few other possibilities. However according to this website which apparently quotes “Brian Kernighan and Dennis Ritchie” (important names you should know) it seems pretty settled that it stands for ‘run commands’. In any case, it is a relic from the CTSS operating system (a UNIX precursor from the 60’s) and since I’m not a programmer from the 60’s, I’ll never know for sure. There are ‘rc’ files for a number of other programs too, such as your bashrc for bash.
Whether it’s definitely the original acronym or not, run commands is a good name.
Your vimrc contains, essentially, a list of ‘run commands’ which adjusts vim default settings to suit your needs.
How and where to find your vimrc
So your vimrc is a ‘hidden’ file in Linux and Mac, but it’s not hidden in windows gVim.
All that means is when you look for it in Linux and Mac you won’t see it, unless you specify that you want to see your hidden files, but it’s there (I mean, it will be after you make one).
The next important thing is the location.
Your vimrc is going to go in your home folder (your user account folder), because it’s your vimrc, and no one else’s.
Vim will find it by searching for your $HOME or your $VIM environment variables.
The first place vim finds it, it will set that as the default location for your $MYVIMRC which is your vimrc environment variable.
Now if you’re like I was and when I knew nothing about anything, I was trying to learn everything about everything at the same time, then environment variables just sound like a lot of techno babble.
An environment variable is a ‘dynamic-named value’ which is a horrendous thing to say to a beginner. It’s actually a pretty difficult thing to describe simply.
You can sort of think of an environment variable as a box that you can put something in. Your OS stores information in these ‘boxes’ so that it can just reference the ‘box’ whenever it needs that information. That way programs can source the ‘environment variable’ which will contain the relevant information that is unique to your device/account/OS. In the context of your $HOME, $VIM and $MYVIMRC variables, what goes into that box is a file path.
They are called variables because the path will vary from user to user, OS to OS and even from one device to the next. The simplest way that they can vary is the name of your user account, which is probably your name, which is probably different to my name.
Importantly however, is that whatever the file path looks like, each environment variable specifies a particular place. $HOME will always be the location of your home folder, and it will be set to the file path of your home folder. This is the first place vim looks to find your vimrc (because it’s yours).
So where is your home folder? I might be stretching the limits of the scope of this article, but once upon a time I still would’ve been a bit confused and curious at this point so…
UNIX based systems (Mac and Linux) have a ‘hierarchical’ file structure. This starts at the ‘root’ folder (Um, OK, these are actually called directories, not folders, so I’m going to call them directories from now on, hope that’s cool) which is the primary filesystem directory that stores basically everything, except for a couple of things needed to boot your OS (whole other post… whole other day). This directory is represented as simply:
Also known as the ‘forward slash’. Everything in UNIX starts here.
On Linux, inside the ‘root’ directory is a ‘home’ directory. Inside that are individual user directories. Your user directory will be whatever you called it when you configured your Distro.
On your Mac, inside the ‘root’ directory is a ‘Users’ directory. Inside that, as you might have guessed, you will find all user account directories including a ‘shared’ and a ‘guest’ directory. Your user directory will be located here and will be whatever you called it when you configured your Mac (probably your first name, or some cheesy alias).
In both Linux and Mac your $HOME environment variable will be set to your individual user directory. This is the best and most common location for your vimrc, and is one of the first places that vim looks for it (specifically vim looks at your $HOME to see if it’s there).
To make things easy, this:
is the symbol to signify when you’re talking about your user directory (your home directory). So memorize this:
home = ~/
Remember that super cool ADM-3A terminal keyboard? Remember that button at the top right?
So if you’re using Linux or Mac, then your vimrc file path will look like this:
The dot at the front is what makes it a hidden file.
Windows uses directories named drives, like ‘C:’, which should be very familiar to anyone who uses windows.
Your home folder will be the one which is again named for your user account, so it will look something like this:
Stored as the $HOME environment variable is the full path name, which you can see by getting into vim and typing:
so the location of your vimrc will look something like this:
Now, for Windows gVim users, another place to put it is in your $VIM environment variable path, which will look more like this:
This is where the empty _vimrc file is located that gVim came with, however it’s not the typical location, so you should instead still put your vimrc in your $HOME (or move the existing empty _vimrc file into your $HOME environment.
There are other places you can put your vimrc, but $HOME is the best and safest place. It’s where vim looks first, and when it finds it, it stops looking. You would only put it somewhere else if you had a good reason, and if you did, you would know it.
The only other thing I’ll mention before we move on is that there can also be a ‘system vimrc’, which you might find on a multi-user system like a remote cluster or server or something. This will be a vimrc that is sourced when any user starts a vim session on that system and vim looks for this before it looks for your user vimrc. But we’re not making one of those today, so that’s all I’m going to say about that.
Chances are if you’re a noob then that all just freaked you right out.
So just to recap,
- vimrc is a special file that contains custom options to make vim work the way you want it to work.
- $HOME is an environment variable which is set to the path of your home directory and is where vim looks first to find your vimrc. It’s definitely the best place to put your vimrc.
- Your vimrc path will look like this “~/.vimrc” for UNIX OS’ and “C:\path\to\home\_vimrc” for Windows.
- Vim is programmed to automatically search for this file.
- If it finds it it will execute the files contents.
- Every time you close your vim session it forgets the commands, and it finds and executes your vimrc fresh every time you start Vim.
Creating your vimrc
This is the easy part.
So now that you know what your vimrc is, and where it goes hopefully this part will feel quite sensible.
The first thing we want to do is start vim. So do this in your usual way, so that you can see the welcome screen.
Now we just want to make sure you don’t have a vimrc yet, before we go making one, so type this in from normal mode:
This will appear at the bottom of your buffer window. If you have a vimrc the path to the file will replace the command when you press enter. In gVim in Windows, this will point to the empty vimrc file.
If you don’t have a vimrc it will just be left blank.
Now if you’re using Linux or Mac you’re going to type this in:
This will create a new/empty buffer in vim which will write to a file named .vimrc in your home folder when you save it.
If you’re using Windows, probably the easiest thing to do is to type this:
This will create a new/empty buffer which will write to a file named _vimrc in your home folder when you save it.
Congratulations, you just created your vimrc. Now you need to fill it up.
So what goes into your vimrc?
First and foremost, code goes into your vimrc.
Specifically, command-line mode commands.
What commands you put into your vimrc is up to you.
There’s a really good rule of thumb bouncing around cyberspace to this effect:
“never have anything in your vimrc that you don’t understand”
Which is excellent advice, especially for beginners.
It is basically an extension of the idea that your vimrc is yours, and no one elses. If you just copy and paste random vimrc’s off the web they might do all sorts of funky things, and likely not even work properly on your machine.
If something does go wrong you’ll have no idea how to fix it.
I think the other underlying idea in this is that you should really only add things to your vimrc as you find that you need them. This way it only ever does what you need it to do, and reduces clutter. You will always know what’s in there because you did it yourself, and you did it for a reason, so you’ll understand what it’s for.
There is however an example vimrc on the vim wiki (and in the vim help documentation) that makes a great starting point. You can also take a peek at the ‘defaults.vim’ file too.
There are also tons of other example vimrc’s that users post all over the web, especially GitHub and the r/vim sub-reddit. There’s also heaps of great tricks tucked into the distant corners of stack overflow and other places.
I (and most anyone else who uses vim) still do not recommend just going and copy/pasting this, or any other, example in your own vimrc.
The point I’m making is just that if there’s something you want vim to do, especially when you’re a beginner, there’s a good chance someone has some code to do it and you can find it if you look in the right places and you learn what it does.
I also think that, as a very new vim user, you should stick to the absolute bare minimum for a while, and get used to using vim first. Once you start to get comfortable, there’ll be things that start to pop up that you’ll wish you could improve. Your vimrc should be thought of as a step by step process of finding a problem to solve, and solving it, one at a time.
Having said all that…
There are in fact a couple of lines of code that virtually every vim user has in their vimrc, unless they have a reason not to.
They can be thought of as the vimsentials. So I will go through them here and explain what each does.
Then I’ll go through a couple of other useful things that you might also be interested in down the track too. Nothing that hasn’t been said before, just some of the more common and convenient commands that will help make vim look pretty and feel even prettier.
1. Disable Vi compatibility
‘set’ tells vim that you want to turn on or off (or toggle, or set number or string) some built-in setting in vim from the default. In the case above, what you’re asking vim to do is to stop being vi compatible. By default vim is configured to be familiar to vi users, but anyone who has never used vi will be better off not using it this way (although some might disagree).
Technically vim does this by default when you create your vimrc, but it doesn’t always work depending on certain things, so it’s definitely better to have this in your vimrc as a fail safe.
If you do have this, it should go first, before anything else, because it affects the behaviour of other commands, and will overwrite certain options when it executes.
2. Auto detect filetype by filename extension and contents
filetype indent plugin on
This is a very handy command. This command does a few things. Firstly, it’s important to note that:
filetype plugin on
filetype indent on
Will all work too. The first command however, bundles them all into one.
‘filetype’ is the command to detect individual filetypes in vim. It does this by way of the file extension used and by the reading the contents of the file if need be.
‘plugin’ when bundled with filetypes will load the plugin specific to a particular filetype (if it exists) when that filetype is detected. Vim has heaps of filetype plugins, and you can write your own if you need to.
‘indent’ when bundled with filetypes will set the indentation settings in vim specific to that filetype when it is detected.
Altogether, these commands will detect a filetype, load the corresponding plugin and set the indentation options specifically for that filetype, which can be important for certain programming languages, like python.
One of the improvements that vim made over vi was filetype detection. This command takes full advantage of that improvement.
So this command won’t work very well unless you’re using the ‘set nocompatible’ command.
3. Syntax highlighting
Another vim special. This turns on vim syntax highlighting and sets all highlight colours to default. This is what makes vim really colourful. That’s pretty much it.
This is the catch-all version of syntax highlighting, great for beginners. Also when we go into colour schemes they will go after this setting and overwrite the defaults.
4. Display line numbers to the left
Pretty straightforward. This is the command that displays the line numbers on the left side of the screen as you saw in my screenshot above.
Not absolutely necessary, but a common and helpful command. Allow me to demonstrate.
If you didn’t already have enough ways to get around in vim then check out:
Xgg – where X is some line number
This will move the cursor to line X in your vim buffer. Obviously this would be near impossible to do without the line numbers visible (although it would work, you just have to guess what the line numbers are).
The above four commands are vimrc bread and butter. They are in the Vim wiki vimrc example, the vimrc_example.vim file that comes with vim, and they are in the vimrc default file that vim uses when it can’t find yours.
Despite everything I’ve said, I highly recommend these as your first additions to your new .vimrc file (so does Bram). Unless you have a very specific reason not to have any of them, then they will be very useful.
There are a few other basic settings that are recommended by many vim users, but they’re very easy to find and figure out.
Are you still awake?
Cool, now I’ll go into some of the other more general kinds of things you can put in your vimrc and I’ll offer some guidance in how you can use them.
The next one in particular is also vim bread and butter, but it requires some detailed attention.
The first and absolutely most important thing you need to know about this command is that no matter where you come from in the world it’s spelled ‘colorscheme’ not ‘colourscheme’, so don’t say I didn’t tell you.
The colorscheme is arguably the most self-explanatory setting command in vim. It’s literally just:
which is literally telling vim, I want a colour scheme and I want it to be ‘this’ one.
On my spankin new MacBook Pro one of my personal preferences is:
When I first started learning about vim, colour schemes had me stumped for quite a shameful amount of time before I figured out what was going on.
I have very high praises for the tutorial I used when I started with vim, but when you’re a beginner to the command line, to GitHub, and to vim, doing what it asked here is no idle task. In the end I got frustrated and just copy/pasted the source code for a couple of colour schemes into fresh documents and saved them onto my laptop (which still required figuring out where to put them and a few other niggly details which I’ll explain here).
The tutorial guide I used said something to this effect:
You can download color scheme’s from GitHub and many other places… so do that, then select the one you want.
Good. That answered my first question “are they pre-installed?”.
No, no they’re not.
Actually I didn’t know it at the time, but there is a small selection of colour schemes ready to go they are in a folder named ‘colors’ somewhere in your $VIMRUNTIME path, but not the typical location that colour schemes go when you install them yourself. So if you’re feeling lazy, you can just go right ahead and use one of them instead of going through what I’m about to explain below.
The one you can see in my screenshots is from this default selection on my work laptop and is called ‘evening’, I’ve since changed my preference to ‘elflord’.
Next question, what are they?
Colour schemes are .vim files containing more command-line commands telling vim how to layout the colours of your vim buffer (custom syntax highlighting). There are many hundreds, possibly thousands of vim colour schemes, the majority of them written by individual vim users, and many are slight modifications of others, all generously donated by them over the years for others to download and use at their leisure.
GitHub is Facebook for programmers, only way, way more useful and way less life-suckingly distracting. It’s actually nothing like Facebook. It’s awesome.
GitHub is a social media-ish platform for the sharing and distribution of code, primarily, but they’ll say you can share just about anything else too. GitHub is actually a web hosting service for Git repositories (another post… another day). They have quite a nice tutorial that you can use when you first sign up to show you enough to be able to look at other people’s repos and view/download their source code. It only takes 10-20 minutes to complete and the hardest part is picking a cheesy user name.
Most importantly, GitHub is a place where you can go to download colour schemes for vim; lots, and lots, and lots of colour schemes (if you haven’t guessed by now I’m an Aussie, so I’m going to keep spelling it ‘colour’ unless I’m specifically referring to the command itself and together we’ll all try not to get too confused).
First you have to get a GitHub account which will make you feel cool. Then do the tutorial to get familiar with some of the basics.
Then you have to go here:
This repo has 700+ vim colour schemes. More than you should ever need (at least until you’re clever enough to write your own). It has instructions for downloading them directly (which requires at the minimum a basic familiarity with bash), or you can use the big green ‘download or clone’ button at the top right of the page to download them as a zip file, then unzip them into their destination folder which I’ll explain next.
Or if you just want to be a real cave man like I was, you can look at the ‘raw’ code for some colour schemes and just copy and paste any that you want, into a document and save it on your machine for now, and figure out GitHub later.
So where do vim colour schemes go?
First you need to create another hidden thing (if it’s not there already, but if you didn’t have a vimrc, then you probably don’t have this one either), which will be a folder in your home directory named ‘~/.vim’
Inside that you need another folder named ‘colors’ (spelled colors) which is not ‘hidden’.
So the file path will look like this:
When you call on a colour scheme for vim to use, it will look in this folder for it.
Obviously the built-in colour schemes are not here because this folder won’t exist until you create it.
More specifically vim will search your $VIMRUNTIME path for the ‘colors’ folder, if the colour scheme you’re looking for is not in the built-in subset, it will keep looking. Once you create your ~/.vim/colors/ folder, it will look there too.
Inside here is where your colour scheme files will go. It’s where virtually everyone puts their colors folder, so this is where you’re going to put it too (don’t argue).
If you’re a Windows user then your $VIMRUNTIME path will look more like this:
and in here is the colors folder containing the built-ins. This is a perfectly good place to download colour schemes for a Windows machine. The reason I don’t recommend putting downloaded colour schemes into the default folder in UNIX is because the location is really obscure and could vary, most importantly it is not in $HOME.
If you’re clever you can fork them from GitHub, otherwise you can just download them as a zipped file and unzip them into there.
Hopefully that’s enough information for past me to be able to figure it out in less than a week (seriously, a week!)
Once you have a ~/.vim/colors folder filled with hundreds of wonderful and wacky named colour scheme scripts you’re all set to go ahead and check them out. Before you set a colour scheme in your vimrc, you need to figure out which one you like.
There are lots of ways you can do this. You can just use one of the ones I like:
- lots of others
Create a text file with the names of all the colour schemes in it, then open that file in vim, so you can see them all right in front of you while trying them out. However this can take a while.
But it makes it easy to just go through each of them one at a time.
Another tip is to put a few lines of code (or whatever else you’re likely to use vim for) in the document too, so that you can see what it will look like for each colour scheme.
So how do you select the colour scheme you want to look at?
OK, fine, I’ll explain a bit about command-line mode too.
Explaining command-line mode like a barbarian
I haven’t formally explained command-line mode yet, even though I probably should have done it three posts ago, so I’m just going to do the quick and dirty explanation here for our colour scheme purposes.
Command-line mode can be accessed very easily from Normal mode by pressing your colon key:
As you’ve probably realised, we’ve done this quite a few times already.
For example is one of vim’s many exit commands.
Command-line mode is pretty self-explanatory in that, it is the mode in which you enter commands to vim, much like you would any other command line, like DOS or bash.
When you hit the colon you will see one appear at the bottom left of your vim buffer. You are now in command-line mode, one of the four main modes that I discussed in my first post. In command-line mode you can do a lot.
All we want to do right now is type:
then press your key called ‘tab’. It will autocomplete the word so that it looks like this:
then leave a space, and type in the name of a colorscheme you want to check out.
As I said previously, all of the commands in your vimrc can be entered into command-line mode.
That was a lot to take in.
We’re almost there.
A couple more things you might like
That’s about all you need to know about for now to have a minimal vimrc running. Actually everything above, except for the colour scheme, is set up in the default.vim file that vim uses before you create your own, but of course it’s nice to have your own, and to know how it’s all done right? You’re welcome.
But who honestly wants to be left with the same old vim they’ve been using up to this point?
How about I leave you with a small buffet of options that you can look at and decide if any of them might work for you.
You can always come back to it later.
Vim has tons of built-in commands. But there will always be some things you want it to do that it just can’t quite. So vim allows you to map (or remap) certain key bindings to accomplish specific tasks.
Here’s one example that I promised you a while ago:
nnoremap Y y$
Remember when I said ‘Y’ doesn’t work the same as ‘D’ and ‘C’?
Well this fixes that.
‘nnoremap’ tells vim to do a few things.
Firstly, the ‘n’ at the start makes this is a normal mode remapping. Meaning it will only affect normal mode.
Secondly, the ‘noremap’ will prevent the key binding from doing anything unexpected. This makes it useful for remapping a key that had a previous function.
‘Y’ is the key binding that you will use in vim, and it will henceforth perform the function of the next command sequence ‘y$’.
‘y’ – is to yank some text
‘$’ – is the motion command ‘from character under the cursor to the end of the line’
So what we’ve done is change the function of ‘Y’, which normally does the same thing as ‘yy’, to now behave the same way as ‘D’ and ‘C’. Make sense?
You can use the ‘nnoremap’ ‘noremap’ ‘map’ ‘nmap’ and other remapping commands to expand vim’s functionality enormously. For more information about remapping keys get into vim and check out:
(I haven’t talk about vim help documentation yet, but we’ll get to it)
Abbreviations are very useful, and infinitely customisable. They can be used to create short sequences to expand long words that you use a lot, or for fixing common typo’s, or a bunch of other time-saving commands.
Here’s a few that I use just to give you some ideas:
iabbrev teh the
Pretty obvious here, changes a very common typo for me from ‘teh’ to ‘the’.
iabbrev dline #—————————–
I use this one as a line separator, the ‘d’ stands for dash, the hash indicates a commented line in .txt files and some programming languages.
iabbrev mdline _______
This is for line breaks in Markdown files, and yes, it is in fact easier to write ‘mdline’ than it is to repeatedly bash the underscore button (thankyouverymuch) and just feels nicer to type.
These all work when you’re typing in insert mode.
The only caution with these is not to let your abbreviated command be something you will use as an ordinary term, because vim will change it automatically every time.
Finally, you can use ‘abbr’ in place of ‘abbreviate’, and vim will autocomplete, but that’s just being lazy isn’t it?
Don’t shorten commands in your vimrc.
Set commands are all the commands that begin with ‘set’. They are switches which alter vim’s default settings. ‘set nocompatible’ is an example of this.
Some other common examples include:
Turning this on will display the cursor location in the bottom right of the window in the format row,column.
This will display the current command sequence of an incomplete command in the bottom right of the window.
This bloody brilliant command works in command-line mode. It will display a list of possible autocompletions available for the current text string you are typing. For example if you type in:
Then press <tab>, it will display a list of all possible commands beginning with the letter a. Obviously the list will get smaller as you include more characters. If you type in:
then press <tab> it will display these terms:
set setfiletype setglobal setlocal
That should definitely be enough to get you started.
Vimrc files can be a source of frustration for noobs and even intermediate vim users alike. When you just go throwing anything in from anywhere, you’re far more likely to run into trouble.
If you start slow, and add incrementally to your vimrc, you’ll have a lot more success, and when things do go wrong it will be much easier to troubleshoot.
This post was a behemoth. I definitely went into more detail than my other posts, but I did that’s because it’s really important to get your vimrc right, and to have a good understanding of it from the get go. I still consider this the ‘bare bones basics’ of your vimrc really.
There is tons more great information out there about vimrc’s, I just hope that I’ve consolidated some of the most important information for you and made it a bit less mysterious and confusing.
This post was intended to be everything I wish I had when I was first getting my head around my vimrc.
For more information on building a good vimrc then check out the following resources:
- The vim help documentation in vim itself see:
- Or you can read the documentation online here
- Or you can download the help docs in pdf form from here
- The Vim Wiki vimrc page
- This great guide for not making a bad vimrc
- This article for tips on editing your vimrc on the fly
My last post in this series will be dedicated to pointing you to great resources for digging deep into vim, but since this post is could stand fairly well on its own, I wanted to include these references here.
The next post will probably be a lot smaller than this one and will be all about one little feature which just blew my mind away when I discovered it, macro recording.
I hope so.
Thanks so much for reading, I really hope you enjoyed this post and didn’t find it too confusing. If you’re a beginner… time and patience. In the near future you’ll look back and wonder what all the fuss was about.
A special thanks goes out to Romain Lafourcade (romainl) for consistent professional feedback on these posts, and being a source of helpful information for this post in particular.