I went into a course on document extraction assuming modern OCR was basically an improved version of old OCR. That's wrong: they're two unrelated methodologies that solve the same problem. The old approach, Tesseract is the standard example, is a hand-engineered pipeline, fixed rules for finding lines, then fixed rules for classifying characters. It's cheap to run, and still the right tool for a clean scanned document, a scanned novel doesn't need anything fancier than that. The new approach is fully data-driven, a model trained on examples instead of programmed with rules, and it's what makes real-world text (curved text, receipts, signage) tractable at all.

Even the good version of OCR has a limit though, and the phrase that stuck with me was "eyes without a brain." OCR can see that a cluster of pixels spells the word TOTAL. It has no idea that TOTAL is the field that actually matters, or which of the six numbers on the page belongs to it. Perception and cognition are two completely separate problems.

The fix is putting a reasoning layer on top instead of expecting the OCR model to somehow get smarter. The specific pattern is called ReAct, reason then act, and it's a loop: Thought, what do I need to do next, Action, call a tool like running OCR on a specific region, Observation, look at what came back, then loop again until it's done. What I liked about it was every thought gets logged, so you can actually see why the model made a call instead of just getting a final answer and having to trust it.

The framing that made the whole thing click was thinking of it as a stack instead of a single tool: pixels turn into text, text turns into structure, structure turns into something an agent can actually reason over. I'd been thinking of OCR as the hard part and everything after it as free, but it's actually the opposite, OCR is the easy layer. The part that's still hard is everything you build on top of it.

I was taking a class that used Quarto for basically everything, problem sets, write-ups, the works, which meant constantly running quarto preview file.qmd in a terminal, tabbing over to check the rendered output, then remembering to kill the process when I was done. Except I never remembered. I'd close the terminal instead, and Quarto would keep running in the background, still watching a file I'd stopped editing.

So I wrote a function that does the whole cycle from inside the editor: one keybinding starts the preview, and it doesn't just fire off the process, it tracks the job per buffer so a second call knows to kill the first one instead of stacking previews on top of each other.

local job_id = vim.fn.jobstart({ "quarto", "preview", file, "--timeout", "5" }, {
  on_exit = function(_, code)
    quarto_jobs[buf] = nil
    quarto_cleanup(file)
    if code ~= 0 and code ~= 143 then
      vim.notify("Quarto preview exited with code " .. code, vim.log.levels.ERROR)
    end
  end,
})

The --timeout 5 flag does something I didn't expect the first time I read the Quarto docs: it makes the process self-exit once no browser client is still connected, which means closing the preview tab is enough to trigger cleanup. I don't have to remember to do anything on my end at all.

Cleanup itself was its own problem. Quarto doesn't just render to stdout, it writes an HTML file, a _files directory full of assets, and a .quarto cache, all sitting next to my source file. I didn't want any of that showing up in a git status I'd have to think about, so on_exit calls a cleanup function that deletes all three, every time the job ends.

The bug that took the longest to notice: none of this fired if I just closed the buffer inside Neovim instead of quitting Neovim entirely. The job kept running, the generated files kept sitting there, and I only caught it because I opened a preview, closed the buffer, and later found a .quarto folder from a file I hadn't touched in a week. Fixed with one more autocmd on BufUnload instead of only relying on Neovim actually exiting.

One argument-order thing that cost me more debugging time than it should have: the file path has to come before the flags in the jobstart table, or Quarto reads the whole thing as "preview the current directory" instead of "preview this file." I found it by process of elimination.

At some point my Neovim config had a picker plugin, a dashboard plugin, a notification plugin, a terminal plugin, a file explorer plugin, a zen-mode plugin, and a scratch-buffer plugin, each with its own config file, its own keymap conventions, its own way of doing borders and window styling. Snacks.nvim replaced all of it. I swapped it in over a weekend and deleted six files.

Fewer files is nice but it's not a story. The interesting part is a comment I left in my own config a while back that I finally circled back to:

-- Was disabled on the assumption magick wasn't installed; :checkhealth
-- reports ImageMagick 7.1.2 present and Ghostty detected as a supported
-- terminal (it speaks the kitty graphics protocol), so both requirements
-- are actually met.
image = { enabled = true },

I'd turned off inline image rendering in markdown buffers months earlier because I thought I didn't have ImageMagick installed, and never actually checked. It sat disabled through however many :Lazy sync runs, until I ran :checkhealth for an unrelated reason and saw ImageMagick sitting there, and my terminal already speaking the right graphics protocol. The feature had been available the entire time I was telling myself it wasn't.

The rest of the plugin follows the same shape everywhere: check first, enable conditionally, don't assume. The lazygit integration does the same thing but out loud instead of silently:

function()
  if vim.fn.executable("lazygit") == 1 then
    Snacks.lazygit()
  else
    vim.notify("lazygit not installed. Run: brew install lazygit", vim.log.levels.WARN)
  end
end,

Instead of a "command not found" from a shell-out gone wrong, missing lazygit just tells you what to do about it. Small thing, but it's the difference between a plugin that fails politely and one that fails like a stack trace.

None of this needed eight separate plugins to begin with, which is the lesson. A stack of single-purpose plugins feels more modular until you're maintaining eight sets of keymap conventions and eight border styles that don't match. One plugin that does all of it consistently, written by people who use it themselves, ends up being less config to reason about even though its own opts table is longer than any plugin's used to be. I didn't consolidate for the file count. I consolidated because the eight-plugin version kept breaking in ways a single well-maintained one doesn't.

Neovim 0.12 shipped native support for a handful of LSP features that almost nobody uses, because none of them are switched on by default and the servers that support them are not consistent about it. I found out they existed by reading the LSP client source instead of the docs.

Code lens is the clickable "2 references" or "Run Test" annotation you see above a function in VS Code. Document color swaps a hex code or rgb() value for an actual color swatch, as long as the server understands color, not just a plugin doing regex on the text. Linked editing range means renaming an opening HTML tag updates the closing one automatically, which nvim-ts-autotag never did on its own: autotag creates the closing tag, it never tried to keep the pair in sync afterward.

None of these are safe to always turn on, because asking a server for something it doesn't implement is an error. So the actual code is a small table of method-name-to-module pairs, checked against what the client claims to support:

local capability_features = {
  { "textDocument/codeLens", vim.lsp.codelens },
  { "textDocument/documentColor", vim.lsp.document_color },
  { "textDocument/linkedEditingRange", vim.lsp.linked_editing_range },
}

vim.api.nvim_create_autocmd("LspAttach", {
  callback = function(ev)
    local client = vim.lsp.get_client_by_id(ev.data.client_id)
    for _, feature in ipairs(capability_features) do
      local method, mod = feature[1], feature[2]
      if client:supports_method(method) then
        mod.enable(true, { bufnr = ev.buf })
      end
    end
  end,
})

Every server that attaches to a buffer runs through the same check, and only gets the features it supports: clangd gets code lens, jsonls doesn't, and nothing breaks either way.

The other piece that mattered more: capabilities aren't set per server, they're set once on '*', a config every server inherits before its own table gets merged on top. I almost put capabilities in each server's config instead, which would've worked for the servers I set up by hand. The problem is mason-lspconfig auto-enables any server the moment you install it, so a future :MasonInstall gopls would've quietly come up with Neovim's default capabilities instead of blink.cmp's — no snippets, no proper completion resolution, no folding range for ufo. Setting it once on the wildcard means every server gets the same baseline whether I remembered to configure it individually or not.

I added the wildcard fix after noticing a newly installed server behaving worse than the others, and only found the three LSP capabilities afterward, because I went looking for what else Neovim might be sitting on that I hadn't used yet.

Escape is in the worst possible spot on the keyboard. Top left corner, a hand-stretch away from home row, and you hit it constantly in Vim, every single time you want to leave insert mode. After the mouse was gone (see the last post), Escape became the next obvious issue. So I remapped jk, typed together in insert mode, to act as Escape. Hit j then k fast enough and you're back in normal mode without your hands ever leaving home row.

The problem is obvious if you've ever typed the word "junk" or a sentence with "just kidding" in it. For about two weeks I'd occasionally get kicked out of insert mode mid-word for typing a totally normal jk sequence, and have to retype. It's a rare combination in real writing that it stopped being a problem once I got used to it, but it wasn't zero-cost the way I'd thought before actually using it.

Around the same time I started using the leader key properly. Vim gives you this modifier key, usually mapped to space, that does nothing on its own but becomes the prefix for basically every custom shortcut you build. <leader>ff to find files, <leader>gs for git status, that kind of thing. The appeal isn't any single mapping, it's that space is right under your thumb and never conflicts with an existing Vim command, so you get a second layer of shortcuts without stepping on anything.

The one that actually surprised me was auto-centering scroll. Search for something with / and jump to it, and by default the match lands wherever it happens to land on screen, sometimes right at the bottom edge with barely any context around it. I mapped the search-jump commands to append zz, which recenters the current line in the middle of the window.

None of these are impressive. A remapped key, a modifier, a scroll tweak. What actually changed my editor was doing about a dozen of these small rewires back to back until the friction that used to interrupt every few seconds mostly disappeared. I didn't notice it happening in the moment. I noticed it a month later when I sat down at someone else's default Vim setup and felt like I was working in mud.

That was months ago.

The logic was pretty simple: if the mouse works at all, I'll use it, and if I use it, I'll never get fast at the keyboard equivalent. Clicking to a specific line is easier than thinking about a motion, right until you've done it thousand times and never learned the motion. So I removed the easy option and forced myself to figure out the actual way to do things.

The first week was hard. Not the big stuff: jumping around a file with search and line numbers was easy to adapt to. It was the small stuff: clicking into a specific word to start editing; dragging to select a block of text I wanted to delete; clicking a tab to switch buffers. All of that had to be re-learnt as a keyboard motion, and for a few days I was slower than before, which is an annoying thing when the whole point was supposedly efficiency.

Once f and t motions to jump to a character, visual mode for selections, and buffer-switching keymaps became automatic, I stopped thinking about them at all, which is the whole goal of muscle memory in the first place.

The part I didn't expect: I now notice the problem in other editors. Reaching for a trackpad in VS Code to click somewhere feels like a problem now, not the default. That's probably the real reason that this was worth doing: not that I got faster (I did, eventually) but that the keyboard-only way stopped feeling harder.

I'm not going to pretend this works with everyone. If you're working with someone, or doing anything visual-heavy, a mouse is just correct. But for the kind of solo coding I do most of the day, cutting off the easy path turned out to be the thing that taught me the hard one.