1. Introduction
Published: 2024-07-03 09:12:43

In this series I will recreate my current neovim configuration, which I recently build from scratch.

This introduction is different from other similar tutorials I have seen in two ways
- I my configuration to be **re-sourceable**
- I will focus on improving a specific workflow.

In this process, I have read a lot of documentation, to understand what really happens in all the plugins I use. I will not only show how I set it up, but also try to recreate _my_ process of learning, helping you not just recreate my configuration, but also have a better foundation for making your own decisions about how this should work for you.

I will not cover all basic vim/neovim functionality and options, but I have a companion series, [Concepts of Vim and Neovim](https://dev.to/stroiman/series/27946), where I explain some more fundamental concepts in depth, e.g. the use of leader keys, autocommands and autogroups, etc.

So if you are vim/neovim savvy, you can just read this series, but if you are new to neovim, or perhaps like me until recently, copied someone else's profile and made a few adaptions, the companion series can be helpful.

Note: The complete series is not written yet. I will publish articles as I get them written.

## I Want my Configuration to be Re-Sourceable

In most other neovim tutorials, they often quit and restart neovim after making changes. 

That is something that annoys me. For almost all the years I've been using vim, I've been able to just reload my configuration after I made changes, and have the changes take effect. Often I make a change because I detect an commonly repeating editing pattern. I just want to be able to make a change to optimise that specific task immediately.

This change is made while I was in the progress of editing production code, so of course I want to be able to jump right back to where i was and continue.

Having to quit and reopen vim completely breaks the flow, and should be avoided as much as possible.

Plugin managers generally aren't written with this goal in mind - so in order to get this to work properly, I need to deviate a bit from the idiomatic way the plugin manager works.

### A word of warning.

It can never be guaranteed that re-sourcing the configuration will work correctly all the time. Executing the configuration is not a _special_ command, it merely runs the code in the script in the current state of vim/neovim.

Therefore, you can easily have undesired state that will not be removed. In particular, if you remove a plug that has already been loaded, it will stay loaded and cause trouble. A specific plugin may also not work well with reloading.

Also, as I deviate from the idiomatic way of using the plugin manager, my approach could have unintended effects in the future. But I do rely on publicly documented features, so they _should_ continue to work.

## Focus on Improving Workflow

Many tutorials follow the steps:
- Set some default options
- Add a plugin manager
- Add completion and lsp plugins
- Add more awesome plugins and show how fancy they are

I rather start with
- I am working with my neovim configuration, let's make it easy to quickly edit and apply changes.
- Some stuff annoyed me in this process, let me fix those.
- My configuration is getting bigger, I want to modularise it.
- I want to make it easier to navigate the files in my configuration.

This is the order in which I was making changes to the configuration myself, and I think it will be much more helpful and a better learning experience, as it becomes more apparent _why_ I make each change; which process does this setting support.

I also think that it will help you get into the mindset, that when you discover a pattern in _your_ workflow, you will try making the change to fix it.
## Inspiration

I learned from others, and I want to give credit to them. Also, they may use fancy plugins I don't find to be helpful, but maybe you would.

The first two resources were helpful in my early vim journey, and I highly recommend at least checking out VimCasts.

- [VimCasts](http://vimcasts.org/) by Drew Neil still has a lot of _very helpful_ information about basic vim functionality, e.g. did you know that you can [paste in _insert_-mode](http://vimcasts.org/episodes/pasting-from-insert-mode/) using <kbd>&lt;Ctrl&gt;+r 0</kbd>?
- [Learn VimScript the Hard Way](https://learnvimscriptthehardway.stevelosh.com/) by Steve Losh. Although learning vimscript is not the most helpful if you use neovim, you should learn lua instead, understanding the principles about the package folder structure is still helpful. E.g. if you want to change the default tab-settings for a specific filetype, the easiest is _still_ to add a vim file in the `ftplugin/` folder.

Newer videos specifically about setting up neovim in lua that helped in my neovim journey

  - [Neovim RC From Scratch](https://www.youtube.com/watch?v=w7i4amO_zaE&t=1166s) by [ThePrimeagen](https://www.youtube.com/@ThePrimeagen)
- [Neovim for Newbs](https://www.youtube.com/playlist?list=PLsz00TDipIffreIaUNk64KxTIkQaGguqn)'s by [TypeCraft](https://www.typecraft.dev/)
- [Josean Martinez](https://www.youtube.com/@joseanmartinez) often publishes great videos, not just about neovim, but also configuring the terminal and tmux.

## A little bit of history

I have been using vim for almost 15 years. My original configuration was very small, and adapted, very much inspired by VimCasts. I started using it for Rails development (I think it was actually because of the extremely great [rails plugin](https://github.com/tpope/vim-rails) by [Tim Pope](https://github.com/tpope) that I started with vim in the first place). To get it working, I needed to copy code I didn't understand, but I had a great editor for rails.

I started learning more about vim, started to understand what happened in my config, started to get my own ideas about how to improve the workflow, and particularly reading Learn Vimscript ... made me start writing my own plugins in vimscript, replaced pathogen with vundle, and later vim-plug.

Eventually I started checking out neovim and used it in parallel with vim. The same config was symlinked betweed the two my configuration had `if`/`else` statements as I started to add neovim replacements to vim plugins, and still have it usable in both editors. But eventually I dropped legacy vim altogether.

As more and more plugins started to be developed in lua, my _one large vim config file_ started to have inline lua code in my vimscript initialisation to configure the new plugins. And I started to realise that _soon_ I need to create replace my `init.vim` with  `init.lua`.

Eventually, about a years ago, I did it. The original version was very much copy/paste from ThePrimeagen's video mentioned above. This was later adjusted, after watching videos by TypeCraft and Josean Martinez.

But all that time, my neovim lua config was a copy of other people's configurations, and in the process I had made a mess, and re-sourcing everything didn't work well. It also dependend on [lsp-zero](https://github.com/VonHeikemen/lsp-zero.nvim), which is a wrapper around other plugins, that I later learned and understood more.

During that year, I learned to understand more about lua, plugin managers, etc.

It was about time that I wrote a configuration that was mine from scratch, not code copied from someone else.

## But first ...

I started this configuration from scratch, while I already har a working configuration. Before starting, I wanted to make sure I could easily switch between configuration back and forth between the original working, and new work-in-progress configuration. In the next article in the series, I will show how I created a sandbox for the new configuration.