Persistent Search with Neovim and Telescope

I’ve been doing a lot of deep refactoring in SBLive’s biggest Rails codebase lately, and something that’s come up as noticeably missing from my Neovim setup, which is using Telescope.nvim for my file browser and searching, is the ability for me to see a persistent list of search results for whatever code I’m trying to refactor.

This is what Telescope’s live grep searching looks like — it’s pretty great. I can use the arrow keys to scroll through the results and the window on the right side shows a preview of that line within the file. It’s super useful for thing like finding every instance of .delay in a codebase.

The problem is that as soon as I select one of the results, or as soon as I click on any other window, I lose those search results. I’ve got to redo the search and figure out where I was exactly within them all over again every time. I haven’t noticed this previously because 90% of the time that’s not a big deal at all and meshes well with how I write code.

But…. I’ve got dozens of instances of .delay in this codebase and it’s so frustrating having to redo the same search dozens of times when what I really want is just to have a persistent list of the search results for me to look through at my leisure. I know other people want it too because it’s come up more than once in Telescope’s issues:

The best advice I really found online was this Reddit post that told me that Ctrl-q puts all of the results in the quickfix list. That is almost exactly what I want… except the quickfix list seems to be sort of painful to interact with, and the time I spent trying to learn started feeling like a sunk cost so I moved on with life.

Then, this morning, I was hit by a silly little epiphany that I’m sure was mentioned on every page I encountered while searching for a solution:

Open a new buffer. :enew
Put the search results in the buffer. :%! rg --vimgrep '\.delay' .

It’s quick and easy, doesn’t require installing anything else, and I feel like a bit of a fool for having spent more than a few minutes being bothered by this problem in the first place.