Efficient search / edit / continue search workflow?

[shmerl]

Is there a way to

1. Search for something (let's say rg / grep search in files) which opens an fzf lua UI with found entries.
2. Iterate over found entries - open it in some separate place (a tab may be?)
3. Modify that found place
4. Continue iteration over the above until you finish all such modifications

So far if I try to access an entry to edit it (by pressing Enter) it jumps there but closes the search UI. So I need to re-run search after each edit, or alternatively I need to copy the file / line from the found result and open it explicitly somewhere else (like separate editor instance?).

Is there a way to do it better?

[ibhagwan]

There is a much better workflow, a few options:

• First open live_grep and enter a wide capturing regex to narrow down the results
• Then press ctrl-g to toggle to fuzzy search so you’re already working on a smaller set
• Closed the interface? No problem, run :FzfLua grep resume=true and continue where you left off, both search regex and fuzzy query will be resumed so you can continue the ctrl-g back and forth

To further improve on this add a history file to grep and you’ll be able to go back/next on your searches:
https://github.com/ibhagwan/fzf-lua/wiki#how-do-i-setup-input-history-keybinds

Another refinement options is to select all entries you’re interested in and press enter, by default multiple entries will go to quick fix, you can then go back and forth the quickfix wirh :cnext and :cprev (I map these to ]q and [q) and also explore these with :FzfLua quickfix.

[shmerl]

Thanks, I can try some of that. How can I pass resume = true if I'm using more explicit command something like:

:lua require'fzf-lua'.live_grep_native({ cmd = "rg <some rg customization params>" })

[ibhagwan]

:lua require'fzf-lua'.live_grep_native({ cmd = "rg <some rg customization params>" , resume = true })

[shmerl]

Thanks! That works mostly, except position of the search entry in the interface after you do resume resets to the first one. But still it's a big improvement over starting with an empty search.

[ibhagwan]

Thanks! That works mostly, except position of the search entry in the interface after you do resume resets to the first one.

That unfortuntaly is not possible due to fzf limitations being an external process.

[shmerl]

Another refinement options is to select all entries you’re interested in and press enter,

How do you select several entries for it?

[shmerl]

I can take a closer look or see if I can implement deletion directly, to avoid using the inversion idea as a substitute for deletion. If this method can work with 2 and 1 entries, then may be it's good enough. The manual one didn't.

[shmerl]

One possible way to improve the visual method of selection and to allow deleting all entries can be this:

• Add a way to differentiate sending an empty list (nothing selected) to jumping to the list entry. I.e. pressing Enter on a a list with no selections now just jumps to the entry without updating the list to empty.
• Handle selection of 1 out of 2 as well (it's ignoring it now).

Then all deletion scenarios will be essentially covered with the visual method.

[shmerl]

I think I was able to make the above snippet with Ctr+x work to remove one entry out of two, but it doesn't work for removing the last entry

[ibhagwan]

Obviously you cannot create a new list from no entries, why would that be important to “clear” the list? If you’re done with the list’s usefulness move on to the next list, what’s the point of deleting the last entry?

[shmerl]

Well, let's say I finished working on the list and now I want to work on something else (not related to quickfix list). Lingering last entry still shows up in the list for me, so I'd rather remove it. With dd method it can remove all of them.

It's somewhat surprising that default neovim's / vim's features for handling entries in that list are so limited and require literally calling an API function to manipulate instead of having some simple commands. I guess the list was never intended for direct use and rather is a tool for plugins to utilize.

[shmerl]

If anyone needs, I found another tip that helps with these kind of workflows.

Customize your ripgrep call like this (i.e. add --sort=path to however you are using rg):

:lua require('fzf-lua').live_grep_native({ cmd = "rg ... --sort=path" }, resume = true)

This will ensure result of rg is deterministic and sorted (at the cost of running it single threaded). This is super useful when re-running searches especially with resume = true). Non deterministic output of rg makes things very confusing when re-running. Note that without --sort=path rg is parallelized and faster. So use only when needed.