Feature: Re-use focused window for displaying results live instead of a preview window

[enoryw]

Have you RTFM'd?

• I have done proper research

Feature Request

Feature: Re-use focused window for displaying results live instead of a preview window The idea is to feel like vim's / by interacting with the existing buffer. This brief demo of Emacs's Swiper package best conveys this and provides the best UI (IMO, since it ditches floating windows which are self-limiting): it is simply opens a prompt at the bottom of the screen. For file/buffer-related pickers where the preview is a file, re-use window to display the "preview" and for other pickers like a help picker where it makes sense, create a split window and display its previews there. When cancelling the picker, the window layout and buffer position is restored if it was changed, else selecting the item would simply close the picker because the contents are already inserted into the window.

---

Motivation: it feels natural and part of vim's UI to interact with the existing buffer you're searching on. It avoids short-lived floating windows for preview which is not space-efficient. Re-using windows respects window options for consistent viewing experience. The following fzf-lua options resemble Swiper's (Ivy) UI (snacks picker looks exactly like Swiper's UI and even preserves options like number, relativenumber, and gitsigns by default so it's close):

  winopts = {
    fullscreen = true,
    border = "none",
    preview = {
      border = "none",
      vertical = "up:70%",
      layout = "vertical",
    },
  },

This gives the feeling of re-using the buffer; however, a preview window in place of the position of the existing buffer still has problems, the second being the main issue:

• Contents of the preview window does not match existing buffer's position for blines and pickers that begin searching from the current buffer (it always starts from top of the preview of a file). This is only relevant when the search result is empty or if results are already visible on the screen (imagine using vim's /, to search for a string already visible on the screen--it just gets highlighted and the position of the buffer stays the same) since it gets replaced as you search. When I work with Swiper in Emacs, this is a nice touch that makes it feel like the plugin is fully integrated into the editor.

• There's a flicker that happens and is unavoidable when a preview window is created--this is evident when it replaces the existing buffer is on the screen with the intention of appearing as if it's the existing buffer (the preview would take up the majority of the space so nearly the screen flashes). I see @folke saying there should be no flickering (I'm not the OP of that thread but this feature request is raised having shared similar thoughts with OP)--I guess what's misunderstood is that in Swiper, there is no preview generated since it's acting on the existing buffer so there is no flicker at all. There's no flicker at all when using vim's / or Swiper because they work with the existing window.

I actually found that with both of these issues combined, it's disorientating to use existing pickers in Neovim when they are configured in fullscreen to replicate Swiper's UI for maximum space efficiency because the illusion of re-using the window for the buffer is visibly distracting with the nearly full screen flicker. I would rather settle with floating windows if the FR is not possible because of these issues. I assume this might be why Neovim pickers tend to default to heavy use of floating windows even for pickers that would benefit from fullscreen previews (files, buffers, help pickers, etc.).

---

EDIT: Made some adjustments in language to try to be more technically correct regarding windows and buffers.

[ibhagwan]

Ty for openin this @enoryw, this seems to only make sense for blines ano grep_curbuf, otherwise we will eventually have to swirch away from the current buffer anyways.

How does swiper deal with results outside the current buffer?

[enoryw]

The window for the buffer that was focused when Swiper is launched will be re-used to show all the results for all pickers where it makes sense (files, buffers, etc.). It feels natural because you can cancel the picker and restore the previous state or accept and it will just close the picker because the buffer is already in the window. For pickers like a help picker, it opens a split and shows its hovered result in that window [https://www.youtube.com/watch?v=QcPenVmmQyM&t=147s](timestamped demo because I nuked my Emacs config). For all these pickers, you use C-p/C-n to select prev/next without previewing, and hold the Alt key if you want the preview for that item (or just default to previewing and hold for non-previewing)--this is a nice QoL behavior to quickly selectively disable previewing if you know the file is big or don't care for previewing a subset of results and is more convenient than toggling preview on/off (which can also be done, of course).

There's no real benefit functionality-wise to the feature request but describing it in words don't really do it justice how integrated the Swiper is integrated with Emacs simply by using a normal window for its results live, i.e. no flickering of the whole screen because it doesn't involve giant floating windows (happens when fzf-lua/telescope/snacks picker's layouts try to resemble Swiper's space-efficient Ivy-style UI). Re-uses the window where it makes sense or do a split and re-use that otherwise for all the results as they are hovered. Cancel the picker to restore previous window layout if it was changed as well as buffer position or select the item and the prompt simply exits because the insertion of its contents to the window was already done live (with existing window options respected. i.e. "WYSIWYG". A window actually acting like a window for different buffers as opposed to short-lived floating windows).

---

P.S. Unrelated to this FR: for grep and friends, Swiper also highlights the matching parts of the string in the live buffer like vim's / (rg is is used for searching and applies to all files in the results, not just those from open buffers), not just in fzf's item results (this is a whole separate FR which I'm also not sure if it's worth the effort to implement. I saw the FR was brought up to telescope but nothing came of it along with a FR essentially the same as the raised here).