feat(pick): Add side-by-side preview support

[somnam]

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Since using mini.pick I missed having the preview pane visible next to the picker - it shows more context then and helps to narrow down the search faster (or maybe I'm just too used to it 😅). This is an attempt at implementing this feature.

Example screenshots from implementation:

There's no change in current behavior. This can be enabled only by setting new preview options.

[echasnovski]

Thanks for the PR!

This is not something that I'd want to be a part of 'mini.pick' itself. This adds significant complications to code for something that I don't think adds a lot to the usability.

I am open to try to expose as minimal information as possible by custom events, but other than that this is not planned as a part of 'mini.pick'.

[somnam]

I am open to try to expose as minimal information as possible by custom events, but other than that this is not planned as a part of 'mini.pick'.

Seems fair. A PR exposing some of the private interfaces from mini.pick that would allow implementing this in a personal config would be considered?

[echasnovski]

A PR exposing some of the private interfaces from mini.pick that would allow implementing this in a personal config would be considered?

Probably no, as it will mean documenting and testing something that is currently private. My thinking was more along the lines of triggering relevant events in relevant times to make this use case less painful.

Besides, it is already somewhat possible to implement a separate preview window with currently exposed functionality. Here is an example in the discussion which also has other thoughts about separate preview window.

[somnam]

Besides, it is already somewhat possible to implement a separate preview window with currently exposed functionality. #1476 (reply in thread) in the discussion which also has other thoughts about separate preview window.

Yeah, my initial implementation was something similar I guess, a timer that fired every 100 ms and updated a preview window. I tossed that away as it was cpu-intensive and more of a hackish workaround rather than an actual solution. Diving into the mini.pick code allowed this to have no cpu overhead and work according to how mini.pick operates. Guess back to the drawing board then.

[echasnovski]

I tossed that away as it was cpu-intensive and more of a hackish workaround rather than an actual solution.

Did you measure it or is this from a feeling? The linked implementation has an early return via if vim.deep_equal(preview_item, matches.current) then return end which I is usually performant enough to be called even every 10 ms.

[somnam]

I probably overstated the "intensive" part. With my own timer-based preview visible alongside the picker nvim would idle at ~ 3% cpu use while showing the picker without preview idled at ~ 0.7%. 3% wasn't much, but a 4x increase non the less 😅.

[somnam]

Probably no, as it will mean documenting and testing something that is currently private. My thinking was more along the lines of triggering relevant events in relevant times to make this use case less painful.

Thanks for this tip. I've prepared a minimal PR that helps to implement the side preview without using timers. Please take a look if this could be considered: #2276