Vim as Your IDE: Building a Workflow That Sticks

People say you can use Vim as a full IDE. They're right, but the path there matters. I've seen people try to configure everything on day one and burn out. Here's a more gradual approach.

Phase 1: Learn Vanilla Vim First

Before plugins, before themes, before anything: spend a month in vanilla Vim. This sounds painful. It's not.

The goal is to separate Vim's actual capabilities from what you add on top. Vanilla Vim has:

• Excellent search with :grep and /pattern
• Multiple buffers and windows
• Macros (q{register} to record, @{register} to play)
• Registers for clipboard history

Most developers don't use 20% of this.

Phase 2: Add Structure

A minimal setup that works everywhere:

set number relativenumber
set expandtab tabstop=2 shiftwidth=2
set incsearch hlsearch ignorecase smartcase
set autoindent

Relative line numbers alone change navigation. 5j jumps down exactly 5 lines when you can see the number.

Phase 3: Language Features

For a modern IDE experience, two things matter:

1. Language Server Protocol (LSP): Gives you autocomplete, go-to-definition, inline errors. In NeoVim, nvim-lspconfig handles this.

2. Fuzzy finding: fzf.vim or telescope.nvim for finding files and searching code. Replaces a lot of what you'd use the filesystem sidebar for.

The Honest Part

Some things are genuinely better in GUI editors. Visual Git diffs. Step-through debugging with a nice UI. Refactoring tools.

You don't have to choose one tool for everything. Use Vim for text editing. Use whatever you like for the things it does better. The goal isn't purity — it's speed.

What Vim gives you is a mode of editing that transfers everywhere: the terminal, config files, notes. That's the workflow that sticks.