feat(actions): add select_preview_*

[antoinemadec]

@fdschmidt93 this is what we talked about in https://github.com/nvim-telescope/telescope.nvim/issues/1978

In short: it copies the lines of the preview in a scratch buffer. I decided not to go with the keep_last_buf method (https://github.com/nvim-telescope/telescope.nvim/issues/1978#issuecomment-1141717644) as it would have required to implement keep_last_buffer for each previewer.

What do you think ?

For info, I tested it with git commits previews and file previews. Everything works fine.

Regarding filetype detection : it sometimes cannot detect it with content only. A way to make it work would be to call plenary with the filename extension. IMO, this is a not realistic usecase as select_* would be more useful when dealing with files. Also, ft can be forced with opts.

[fdschmidt93]

Just a heads up, I have a deadline end of next week and may or may not attend to this in detail in between -- apologies for having to wait a bit on this here from my end.

I decided not to go with the keep_last_buf method (#1978 (comment)) as it would have required to implement keep_last_buffer for each previewer. What do you think ? For info, I tested it with git commits previews and file previews. Everything works fine.

I'm afraid there will be a ton of disappointed users missing highlighting as per the original preview for eg git pickers ;) I'd have to have a closer look at the previewers code again, but I suppose with a bit of RFC it should be straightforward to just keep the buffer instead incl. original highlighting? I'd argue that would be preferred.

The primary consideration from my end remains that we ideally retain the preview buffer as that buffer may have special highlighting (eg many git pickers) and preview buffers per se already as such are a "copy" of what's being ultimately selected (e.g. find_files actually reads file into a throw-away buffer).

Thoughts?

[antoinemadec]

From what i understand "keeping the preview buffer" currently only works with the "new_buffer_previewer".

That wouldn't work with any other previewer.

I will look into it and double check to make sure I'm not mistaken.

As far as git pickers go, 'git commits' is working alright with this PR. Will keep you posted, but work is gonna be super intense until mid July so i might not be super responsive.

[antoinemadec]

If doable, clean and scalable, i agree that keeping the preview buffer would be the best way to go.

[fdschmidt93]

As far as git pickers go, 'git commits' is working alright with this PR.

I now redid the steps manually of detecting the filetype set syntax and then it works for me for :Telescope git_commits (I was tricked by regex_highlighter in code.. which is filetype detection haha, actual manual regex highlighting is for the other previewers as mention below). Not a 100% sure if that's an issue on my end or with this PR as it doesn't work out-of-the-box for my config. I'll look into it. Nevertheless, what I'm referring to should affect a few git previewers (branches, commit message, autocommands, highlights).

From what i understand "keeping the preview buffer" currently only works with the "new_buffer_previewer".

The plan eventually is to make everything a buffer previewer since that simplifies a few things. I hope to come around to seeing https://github.com/nvim-telescope/telescope.nvim/pull/1910 through :) then you can retain the terminal buffers for the corresponding custom command, e.g. git-delta. So (at least) I wouldn't be too concerned to support the other previewers now.

Will keep you posted, but work is gonna be super intense until mid July so i might not be super responsive.

No worries :) thanks!

[antoinemadec]

@fdschmidt93 I had a bit of bandwidth so I took a look at the keep_last_buf solution.

For previewers using new_buffer_previewer it requires updating all of them to make sure the keep_last_buf option is properly passed to the defaulter.

Today, it's not done on any of previewers in buffer_previewer.lua. Also, there is no guarantee that custom previewers using new_buffer_previewer would properly pass this option.

This is the lack of scalability I was alluding to.

Here is what could be done:

• in buffer_previewer.lua: modify all the previewers to pass opts.keep_last_buf properly
• in select_preview(): add a clear message when get_global_key("last_preview_bufnr") returns nil (i.e. last preview buffer wasn't kept)

What do you think ?

[fdschmidt93]

Apologies for only coming back to this now!

opts.keep_last_buf is a bit of funny business. I think an easy way to this without convoluting existing logic could be something like this

https://github.com/nvim-telescope/telescope.nvim/blob/8c563017200bebd76153feb1046ecdf2db26c9d4/lua/telescope/previewers/buffer_previewer.lua#L331-L338

We could change

-- from
if opts.keep_last_buf then 
-- to
if self.keep_last_buf

and pass through opts.keep_last_buf in the Previewer to be able to post-hoc inject that the user actually wants to keep the last buffer for the current previewer. You could then access the previewer from self.state.bufnr (as keep_last_bufnr only stores the bufnr upon preview). While a bit whacky, this would not really work for term previewers until we'd rely on open_term previewers there (#1910 not really motivation atm).

For the time being, I'd generally be OK with doing the above and leaving a TODO to for whenever buffer previewers will be getting refactored. That is

1. Attempt to keep_last_buf with above for buffer previewers (relevant for 90%+ usage I suppose)
2. I haven't thought about that too much, but for term previewers, we'd then get text and attempt to detect filetype

But maybe it's overkill and users would only care about the text after all.

Thoughts, @Conni2461 ? My suggestion is a bit meh, but generally I feel we should keep the buffer if possible.

[Conni2461]

I think we dont need this PR at all. I dont want people to get into previewers. Its a preview, and we should not provide easy access to just open it because its not a real buffer. They are just scratch buffers.

Unless you have a specific reason to enter the previewer, see octo.nvim and that should be decided by the extension developer, not by endusers. And with that in mind i think the current iteration of keep_last_buf is good enough. Is it perfect, hell no, but the demand isn't here to improve it. I introduced it 1 1/2 years ago and since then he is the second person to ask for that feature.

The use case was and still is. You write your picker that very specifically creates the preview buffer with very specific highlighting and then you say i wanna keep the previewer so you can open it in another window on selection.