Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a layout option to hide prompt, results or preview separately #1301

Closed
happenslol opened this issue Oct 2, 2021 · 6 comments
Closed
Labels
enhancement Enhancement to performance, inner workings or existent features

Comments

@happenslol
Copy link

Is your feature request related to a problem? Please describe.
I've been looking into using more of the builtin pickers and I quite like the use of telescope for lsp related things like code actions or references. It feels to me like telescope could fill a role similar to what rofi is used for when it comes to desktop customization (audio switchers, power menus, wifi menus, etc.), since at the core it can be used as a picker for arbitrary sources.

However, there's always a picker and a list of results, which doesn't make sense for every use case. For code actions there's no need to have a prompt since you'll be choosing from a list of 1-5 options most of the time, and in other cases you might not want to see results and only the preview of an action.

Describe the solution you'd like
I think it would be best if it was possible to disable the prompt or the results similar to how previewer = false lets you hide the preview. Hiding the prompt would automatically place your cursor in the results list and make the window non-editable.

It would also be great if the results list could have a dynamic length with the cursor layout strategy, that would improve the look even further.

Describe alternatives you've considered
It's possible to use different plugins like lspsaga for this or nvim-lsputils for this, however these usually come with a whole other set of features and options; and don't offer the flexibility and unified API of using telescope for all picking related business.

Additional context
I'd be interested in contributing for this, but I haven't looked at the relevant parts in the code yet. I don't know if hiding the prompt would require substantial changes, so please give me a heads up if that's the case.

Here's an image of what my code action prompt currently looks like:
image

@happenslol happenslol added the enhancement Enhancement to performance, inner workings or existent features label Oct 2, 2021
@fdschmidt93
Copy link
Member

I don't know if hiding the prompt would require substantial changes, so please give me a heads up if that's the case.

In brief, telescope right now very deeply centers around the prompt. For instance, leaving the prompt closes all windows, changes to the prompt is what triggers the finding loop, handles mappings and so forth.

While I'd say it's quite the challenge for a first PR to achieve your proposal and might be a very interesting PR prior to spinning telescope core out of the main repo (for context, see discussion at #1228), which I've come to think is something we should probably long ways down the road strive for. For instance, why shouldn't nvim-cmp be able to embed telescope-core for fuzzy finding completion items? But maybe rambling too much here.

Anyways, if you are keen on getting started, a rough sketch to get going:

  1. Go over Picker:new and Picker:find in pickers.lua
  2. Generalize pickers.on_close_prompt
  3. Look at actions._close and how everything is closed from there

I think the primary complexity stems from the fact that the prompt buffer currently handles all the mappings, which maybe then be redirected to the results buffer in case no prompt is shown? Maybe that's already all that is. See the last lines of Picker:find to get an idea of what I'm referring to. Happy to answer more questions.

However, maybe better to also let another team member comment/greenlight as to whether we'd be open for that.

@happenslol
Copy link
Author

In brief, telescope right now very deeply centers around the prompt. For instance, leaving the prompt closes all windows, changes to the prompt is what triggers the finding loop, handles mappings and so forth.

Whelp, I suspected as much. The first thing I'd write for a fuzzy finder is a prompt, so it makes sense that everything wraps around that. Anyways, don't worry about rambling, it's interesting to me that you see the matter of using the core parts as a generic popup/fuzzy finding/results display library similarly. All of the pickers currently implemented show that telescope can serve as not just a fuzzy finder per se, but a base for all sorts of popup-based interactions.

I'll have a look at the files and see how it goes. I won't put too much work into it until someone else chimes in on the feasability of a PR for this feature. Thanks for the thorough response!

@Conni2461
Copy link
Member

toggling preview was implemented here: #1305 you just have to map toggle_preview

We decided against hiding prompt and result: #1305 (comment)

Closing

@Zane-
Copy link

Zane- commented May 19, 2022

I'm curious, why is hiding the results not viable? I feel like there are many different use cases for that. For example, opening a simple prompt to get the selected line, then running a command based on it in an action. I don't need to see results for that, and infact, my results is just an empty table, but it still shows up as empty space, which would be nice to remove.

@Shougo
Copy link

Shougo commented May 20, 2022

Can you upload the screenshot? It is hard to understand for me.

@Conni2461
Copy link
Member

I'm curious, why is hiding the results not viable

just because its technically possible to do, doesn't mean it is a good fit for the goals of this project. We are primarily a fuzzy finder and wish to keep it that way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement to performance, inner workings or existent features
Projects
None yet
Development

No branches or pull requests

5 participants