If we scroll down to the README, we can use the table of contents to jump straight to the quick start section. But you'll see that this involves manually git cloneing Packer onto our computer. And that's because we don't yet have a package manager to install our package manager. But that's okay, let's jump over to the bootstrapping section, and you'll see they've provided some code that we can add to our config to automatically install Packer for us if it doesn't exist. So let's jump into our .files repository, and we'll open up NeoVim, and then we'll browse to our nvim-init.lua file. I'm going to copy this line and paste it above using Shift-P, and then we'll change this to say, plugins.

I'm going to copy this line and paste it above using Shift-P, and then we'll change this to say, plugins. The reason I put this at the top is just so that any options or keymaps that I define will take precedence over anything that comes from a plugin. Let's go ahead and save this file, and then we'll edit nvim-lua-user-plugins.lua. We'll jump back over to GitHub, and we'll copy this snippet, and then we can paste it in over here. So at the top, we're defining an ensurePacker function. And all this does is check if the Packer directory exists, and if not, it'll automatically git clone Packer for us, and then run the packadd command to automatically initialize Packer.

And all this does is check if the Packer directory exists, and if not, it'll automatically git clone Packer for us, and then run the packadd command to automatically initialize Packer, so we don't need to restart NeoVim. If the bootstrapping occurs, we return true, otherwise, we return false, and we'll use this later. We then come down to where we're calling our ensurePacker function, and we're storing the return value. Next up, we come down to where we're calling the startup function, and this boots up Packer and then lets us define our plugins. You'll see that this snippet came with a plugin definition for Packer itself, and that's just

and then lets us define our plugins. You'll see that this snippet came with a plugin definition for Packer itself, and that's just so that it can keep itself up to date. If we come down past the plugins, you'll see that we're checking if the bootstrap occurred, and if so, we run the packasync command to automatically install our plugins for the first time. Now, this is all you need to get started, but there are a few other things I like to do. If we jump back over to the readme, and we scroll back up to the quick start section, we'll see this paragraph on automatically running Packer compile whenever plugins.lua

Now while I remember, up here in the startup method, we were returning, but if we do this, then our auto-command below won't work, so let's go ahead and remove that, because we don't need to return anything from this module. Let's come back down to our auto-command down the bottom. So this is a pretty good example of what auto-commands in NeoVim look like, where we can listen for events and then run commands. Every auto-command should be defined inside an auto-group or au-group, using any name you like. So in this case, they're using packer-user-config. The first thing you want to do inside an auto-group is run auto-command with the exclamation point.

So in this case, they're using packer-user-config. The first thing you want to do inside an auto-group is run auto-command with the exclamation point at the end, and this just clears out any existing auto-commands for this group. This is useful if we resource this file, just to make sure we don't end up with multiple versions of the same auto-command. If we look at the auto-command itself, we're listening for the buff-write-post event, which happens after we save a file, and in this case, it's only going to look for that event if it happens on a file called plugins.lua. When that happens, we call source on the file that triggered the auto-command, which in this case was plugins.lua.

When that happens, we call source on the file that triggered the auto-command, which in this case was plugins.lua. After that, we're calling the packer.compile command. Now I actually prefer to remove this part, because sometimes we can get errors compiling if we haven't yet installed our plugins. So I prefer to just manually call packer.sync, which will automatically install our plugins and run the compilation for us. Now there is one more thing I like to do. If we come back over to GitHub, and we'll go to the table of contents down to this Customize Initialization section, you'll see that instead of calling packer.startup, we can call packer.init.

If we come back over to GitHub, and we'll go to the table of contents down to this Customize Initialization section, you'll see that instead of calling packer.startup, we can call packer.init instead, and pass in any number of configuration options we want to customize Packer's behavior. So let's switch back to Neovim, and I'm going to paste in my own version of this. So I'll come up to before we're calling packer.startup, and I'll paste in mine here. So first we're calling packer.reset, which they recommend in the docs, and then the packer.init command, where I'm passing in my configuration options. The first one here is the compile path, and this is where Packer will place the compiled version of our plugin definition. By default, it places this in our configuration directory.

One problem with this, though, is that with the kitty theme I'm using, the pop-up window is almost illegible. So I'm going to go ahead and I'm going to comment these lines out until we've installed a custom theme for Neovim later on. Now that we're calling the init command, we no longer want to call the startup command. So let's go ahead and delete that line, and we'll delete the closing end tag for that as well. I'll then select these lines, and we'll use 9up, and then we'll use the = command to automatically fix the indentation. Now we still need access to this use function.

to automatically fix the indentation. Now we still need access to this use function. So let's go ahead and import that by saying localUse equals require Packer.use. We'll go ahead and save this file. In fact, let's quit out of Neovim, and then we'll open it up again where we're expecting Packer to install everything for the first time. And there we go. Everything's already up to date because we only just cloned Packer, so of course there's not going to be any updates for it yet. We can press Q to close this window, and I'll use Control-O to jump back to where I

Now these use statements are just referring to GitHub repositories with the author's name and the name of the repository. So let's go ahead and save this file, which will trigger our auto command to automatically resource this, and now we should be able to call Packer sync, and this will install our new plugin. If we press Q and then come back over here, let's try it out. If I say gcc, that will automatically comment the line I'm on, and if I press it again, gcc, it'll just toggle the commenting. If I copy this line and I'll paste it four times using 4p, we'll see that we can also select these lines, and I can use gc on its own to comment them, or alternatively I could.