Can I fix the search panel in Emacs?

I use org-roam in Emacs a lot, and sometimes I need to search for something in multiple files. Currently, my choice is `counsel-ag` and `ivy`. But I'm not having a good time with it. The reason is as follows. In other modern text editors like VSCode or JetBrains, the search panel is always there when I'm searching. I can click on any search result on it, view/edit the target file, while in the meantime the search panel doesn't disappear. But in `counsel-ag`, the bottom search panel disappears when I hit the `Enter` or `Esc` key on a search result. Can I just fix the bottom search panel and never let it disappear (Unless I explicitly let it disappear using `C-x 0`, just like other Emacs windows)?

Hit `Alt-Enter` (ivy-call) and the search panel will stay there. Alternatively, hit `C-c C-o` (ivy-occur) to fill a new buffer with the candidates.

> hit `C-c C-o` (ivy-occur) will fill a new buffer with the candidates. Embark provides similar functionality to any completion system, with more options and a few variations. Might be worth looking into?

Definitely recommend looking at Embark. I export the search results to a new buffer, and work my way through those results.

True, but ivy-occur can re-run the search when you hit "g", while embark cannot yet do this.

It very recently acquired this ability (see the issue you filed on GitHub), but it doesn't work that well yet and I'm rethinking the approach. Daniel Mendler has a simpler suggestion for alternative functionality that I find myself agreeing with.

Yep, very cool that you've been working on that!

So the new revert-ish functionality is ready on MELPA and if you get the chance to try it, I'd love to get your thoughts on it, particularly on the design and UX. The problem with reverting an Embark export or collect buffer is that Embark is too general: you can have obtained the candidates from any command at all! If the command is an asynchronous search like `consult-grep` it's very hard to tell when the search is over and all matches have been found without introducing coupling between Embark and the package providing the command (Consult in this example). The command may not even finish ever! It makes perfect sense to run a non-ending command and at some point export the current candidates. So Embark shouldn't even try to wait for a command to finish in general, even if there were some way to do that without coordinating with each package you want to use Embark with. So instead what revert-buffer does in Embark export or collect buffers now is to simply rerun the command you ran in the first place and re-type your input for you. You can modify the input, if you wish, and re-export, if you wish. I like it because it is simple and uniform and it can simulate two operations both of which I wanted: reverting and rerunning with a slightly modified input.

I haven't tried it out yet, but that sounds like a clever and pragmatic approach. Looking forward to test driving it!