Intro
Every programmer needs a way to write their code, whether using a general-purpose text editor like the one that comes bundled with your Operating System, a source code editor like VS Code or an Integrated Development Environment (IDE) like one of those from JetBrains. The one thing in common with all these editors I’ve mentioned is that they have a graphical user interface. However, there’s another family of editors that are terminal-based, for example, Vim, GNU Emacs and others like GNU nano.
I think my first exposure to these terminal-based editors was when I needed to edit files while working from the terminal, probably in my early Linux days, and most likely when setting up Linux VPSes and editing config files. Most Ubuntu VPS setup tutorials typically mention nano, as I understand it’s available by default without requiring additional installation.
I can’t remember how I found myself using Vim, but I do know that I preferred it to GNU nano! To this day, I always install Vim on any machine I’m using — not because I use it as my primary editor, but because that’s what I wanna use when I need to edit files while working in the terminal.
I know the Vim basics, having gone through vimtutor a while ago. I have always wanted to know Vim better, and be able to comfortably and productively use it for day-to-day work. It requires putting in a bit of work, and constant practice in order to build muscle memory. I just never quite got to doing this.
So many editors
My first programming language was Java, and I used Netbeans IDE for it, though I also experimented with Eclipse. When I got into building WordPress websites and tinkering with PHP, I used Notepad++, being on a Windows machine at the time. However, I later switched to Atom, and also experimented with Brackets. By the time I was getting into python programming, I liked Sublime Text, so I used it for a while. Then I discovered VS Code, and decided to switch to it! I was used to the Sublime Text key bindings, so the Sublime Text Keymap and Settings Importer extension was always handy. I still kept Sublime Text because I felt that it was more lightweight and faster, so I’d use it when I needed to make one-off edits, or just as a general purpose editor.
So VS Code has remained my main code editor, even though I'd have more lightweight editors lying around — I have since replaced Sublime Text with Zed, which I use when I'm not working on a specific project, e.g when I want to scribble something down or edit a file quickly.
Talk is cheap …
Alright, back to the Vim discussion! As I mentioned earlier, it's always been at the back of my mind to dig deeper into it and get more comfortable with it, as part of my own personal development as a programmer.
The thing is, I enjoy working from the terminal, but there are lots of important things I don't know well that would make me more productive in this environment, where I interact with files in one way or the other. Being proficient with Vim is one of those things.
Now, couple of days before writing this post, I started looking into resources I could use to up my Vim game. I bookmarked the following, with a plan to go through them and practice daily:
Alongside this, I also bookmarked some tmux resources, because I think it’s an equally important tool
However, before I could dive deep into these resources, another programmer, in a local WhatsApp group for programmers, suggested trying out Neovim, specifically the AstroNvim distribution. At this point, I'd already come across Neovim, and seen lots of folks on YouTube using it, but never really got to check it out. This time, I decided to look into Neovim.
I checked out the AstroNvim website, and I was amazed! Before diving in though, I decided to find out more on YouTube, so I came across this video, which compared various Neovim distributions:
Now I was presented with even more options, all of which looked awesome! Throughout the video, one thing that I particularly liked was which-key, a plugin that shows you available keybindings when you pause mid-command. This really blew my mind! Anyway, the YouTube algorithm then brought up the following video, where ThePrimeagen goes through an article “Beginners should use a preconfigured Neovim distribution“, and gives his take.
ThePrimeagen strongly advocates for Kickstart as the ideal starting point for new Neovim users, preferring it over heavier, pre-configured distributions like LunarVim or AstroNvim.
His advice can be broken down into the following key points:
The Best "First Step": ThePrimeagen believes Kickstart is a "really great first step" because it provides exactly what a user needs without being overwhelming. He contrasts this with full distributions, where "diving in deep" can be bewildering due to the sheer amount of configuration and abstraction involved.
Minimal and Educational: He praises Kickstart for being contained within a single file and acting as a "constrained version" of a setup. This simplicity makes it a "Launchpad" for users to build their own unique configuration, rather than getting stuck in someone else's ecosystem.
Avoids Complexity: ThePrimeagen argues that with heavy distributions, understanding how to make edits or fix issues requires a "huge leap" in knowledge regarding project structure, Lua, and plugin management (e.g., understanding init, after, plugin, etc.). Kickstart avoids this barrier to entry.
Kickstart vs. Distros: ThePrimeagen holds the "opposite take" to the idea that beginners must use complex distros. He suggests that pre-configured distributions (like LazyVim) are better suited for users who already "know it all," are tired of configuring their own editor, and just want a working environment. For those actually starting their journey, he insists: "start off with Kickstart".
I resonated with ThePrimeagen’s arguments, because my current Vim setup is very minimal, and I have good control over it, compared to the time when I used the Janus Vim distribution, which seems to no longer be maintained. I was convinced to go with the Kickstart approach, as it felt like the right balance between "works immediately" and "I understand what's happening."
Here we go
I found that I didn’t actually have to uninstall vim in order to use Neovim, because Neovim has its own configuration, and you launch it via nvim, so it can coexist with vim.
On Fedora, installation was straightforward:
sudo dnf install -y neovim python3-neovim
Setting up Kickstart was simple:
git clone https://github.com/nvim-lua/kickstart.nvim.git ~/.config/nvim
nvim
First Customizations
Theme: Catppuccin Mocha
I love Catppuccin, I use it wherever it’s supported (which is almost everywhere!), so I wanted to keep my Catppuccin Mocha theme from my Vim setup. In Kickstart, this meant replacing the default tokyonight theme. I found the colorscheme plugin section in init.lua and swapped it out:
{
'catppuccin/nvim',
name = 'catppuccin',
priority = 1000,
config = function()
require('catppuccin').setup {
flavour = 'mocha', -- latte, frappe, macchiato, mocha
transparent_background = false,
integrations = {
blink_cmp = true,
gitsigns = true,
nvimtree = true,
treesitter = true,
telescope = true,
mason = true,
which_key = true,
},
}
vim.cmd.colorscheme 'catppuccin'
end,
},
Enabling Nerd Font Support
My Fedora setup script(s) already installed JetBrains Mono Nerd Font and Fantasque Sans Mono Nerd Font. To enable the fancy icons in Neovim, I just needed to flip one setting:
vim.g.have_nerd_font = true -- Changed from false
Adding Neo-tree File Explorer
Kickstart is minimal by design—it doesn't even include a file explorer by default! It expects you to use Telescope for navigation (Space + s + f), which is actually faster once you get used to it.
But coming from VSCode, I wanted a traditional tree view available. Kickstart includes an optional Neo-tree plugin that's commented out. I just uncommented this line:
require 'kickstart.plugins.neo-tree',
Now I can toggle the file tree with \ (backslash).
Fixing Language Server Names
I hit my first real error when trying to configure language servers. The Mason package names don't always match what you'd expect. I tried to install lua_ls but got an error:
Cannot find package "lua_ls"
The correct name is lua-language-server (hyphens, not underscores). This pattern held for other servers too:
ensure_installed = {
'lua-language-server', -- Not lua_ls
'stylua',
'pyright', -- Python
'gopls', -- Go
'bash-language-server', -- Shell scripts
}
Pro tip: Run :Mason in Neovim to browse all available packages and see their exact names.
Understanding Which-Key
As mentioned earlier, one of the best discoveries I made was which-key.
Press Space and wait ~300ms? A popup shows all leader key commands. Press g and wait? See all the g commands like gd (go to definition).
It makes Neovim self-documenting. You don't need to memorize everything upfront—just start typing and which-key shows you what's possible. Sweet!
The Health Check
Neovim includes a built-in health check system: :checkhealth
This was useful for validating my setup. The output showed:
Everything important working:
Warnings I could safely ignore:
Missing support for languages I don't use (PHP, Java, Julia)
Optional providers (Node.js, Perl, Ruby) - only needed for specific plugins
tree-sitter-cli not installed - even though it’s really only required if you're developing parsers, I decided to install it, but encountered an error due to missing C headers
Installing tree-sitter (I already have Rust set up on my machine):
cargo install tree-sitter-cli
But it failed due to compilation errors which I resolved by installing the missing development packages:
sudo dnf install clang-devel libstdc++-devel
After that, cargo install tree-sitter-cli completed successfully, though, in hindsight, I could have skipped this entirely since it's only needed for parser development, not everyday use.
Kickstart's health check warned about the missing neovim npm package. Instead of using npm install -g, I used Volta (which I already use for Node.js version management):
volta install neovim
This keeps everything consistent with my existing toolchain.
Reflections: Why Bother?
This isn't about proving anything or cargo-culting what "real developers" use. It's about finding a workflow that matches how I think and work.
For me, that means having powerful text manipulation at my fingertips, and working in a fast, lightweight environment. I also want to understand my tools deeply instead of treating them as black boxes.
I'm glad I got started with Neovim via Kickstart, I think it was the right call. The single-file approach meant I could read and understand my entire config. Not abandoning my old vim setup removed the pressure, I had a fallback if I got stuck.
:checkhealth immediately showed what was working and what needed attention. Turns out most things just worked. LSP, completion, fuzzy finding, git integration, all there from the start. And it was noticeably snappier than VSCode, even with plugins.
The learning curve wasn't as steep as I thought. With which-key and a good starter config, discovery is built into the workflow. You don't have to memorize keybindings, you learn them by seeing them.
Neovim with Kickstart gets me there while keeping the learning curve manageable. The setup took maybe an hour, but I already have a fully functional development environment that rivals VSCode's capabilities for my stack.
What's Next
Now I actually have to use it. Daily. On real projects. I want to learn the navigation patterns deeply, especially text objects. I'll add plugins gradually as I discover needs, not pre-emptively.
I need to get comfortable with Telescope for navigation instead of always reaching for the file tree. And I want to explore the debugging support (nvim-dap) once I hit something I can't solve with print statements.
