[vim/vim] Make popup behave like a normal window (#5639)

[Liu-Cheng Xu]

Is your feature request related something that is currently hard to do? Please describe.

1. It's difficult to show what the user has input in a popup, especially for the multi-byte chars, see liuchengxu/vim-clap#320. vim-clap now has to mock this manually which is definitely brittle and limited.

2. It's difficult to keep the natual modal feature of vim. As the dissussion in liuchengxu/vim-clap#51, we could use the normal mode mappings for more convient actions, but it's not possible for popup right now. I don't want to mock insert/normal mode in popup again.

Describe the solution you'd like
Let popup focusable and we can use it like the normal window.

Describe alternatives you've considered

Additional context

Neovim's floating_win doesn't have these issues as it's a normal window.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[andrey pechorin]

If i understand correct - the ability to focus on popup window is controversy with vim popup ideology =/

[Liu-Cheng Xu]

Making popup focusable is my thought to resolve the difficulties I mentioned above. If there are some other ways out, I'm all ears :(.

[andrey pechorin]

+1. This is unnecessary api limitation. Please add this behaviour as option "focusable".

[ma...@prabir.me]

+1 I would also like the popup to be focusable so that it can be used like a normal window/buffer. Neovim doesn't have this issue.

Here is another use case for me. This is vim-lsp  using hover to show information about the word under the cursor. Most rust projects have big docs including great examples and I would like to move around and copy text from popup, search inside the popup and use all my vim knowledge there.

Right now the solution for me is to open the website or use neovim.

[Bram Moolenaar]

> +1 I would also like the popup to be focusable so that it can be used like
> a normal window/buffer. Neovim doesn't have this issue.
>
> Here is another use case for me. This is vim-lsp

> <https://github.com/prabirshrestha/vim-lsp> using hover to show

> information about the word under the cursor. Most rust projects have big
> docs including great examples and I would like to move around and copy text
> from popup, search inside the popup and use all my vim knowledge there.
>
> Right now the solution for me is to open the website or use neovim.

I have been thinking of this, but it raises many questions:

- How to focus a popup? I imagine in most cases you want to switch
between the current window and the popup, back and forth. This
matters especially if you already have a dozen split windows, you
don't want to cycle through all of them to reach the popup, and you
don't want to cycle through all windows to end up in the one you were
coming from.

- If there is more than one focusable popup, how to reach each of them?
Perhaps some are connected to a specific window (e.g. for completion
or anchored to text), or some are unrelated to a specific window (e.g.
help).

- What if the focused popup window closes? What if it closes while you
are typing (since they might be under control of some async plugin)?

- How to avoid this turns into an avalanche of more feature requests?
Aka creeping featurism.

--
He who laughs last, thinks slowest.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Blay263]

I think the use cases have been detailed above and are limited. Neovim provides a proof of concept. Not having the popup focusable is blocking specific functionality that is already available in Neovim.

[ma...@prabir.me]

From a plugin author there are only two features I would need i.e. allow to pass an option for popup for focusable: true/false when creating popup and capability to focus on the popup or move focus to another buffer/win. Neovim has a win_gotoid() to focus to popup which avoids creating a new api since it treats popup as just any other window with buffer. Based on the api we might need a third once that says which one currently focused.

As for the experience it is like any other buffer or window. You can only be currently focused in a buffer or popup and not multiple. Use / for search, jkhl for movements and so on.

Here is how vim-lsp works when trying to show popup for hovering under a symbol that gives doc.

nmap <buffer> K <plug>(lsp-hover)  

lsp-hover is same as preview window concept in vim but instead of using preview window it uses popup if it exists.

We have a flag to allow autofocus for lsp-hover. if it is true we autofocus to popup window and if false the focus remains in the buffer. By default we have set it to false so it doesn't focus in the popup. The popup closes when cursor moves since it is not on focus. We then have a concept of double tap which means if the user again presses K when the popup is open it focus inside the popup. Inside the popup they can use all the features of normal buffer and cursor movement doesn't close the popup.

For fuzzy finder style popup it also becomes important. I have tried multiple approaches ie. using custom prompt similar to ctrlp, denite style where the prompt is a buffer. I'm leaning to denite style pattern but that means it won't work in popup. vim-clap already seems to be hitting this issue.

(Not related to popup but is there an event similar to InsertCharPre but that works in normal code so we can look at v:char and see what character is pressed? This would solve the issue of using prompt to work in multibyte chars and avoid this https://github.com/prabirshrestha/quickpick.vim/blob/68465f4654f83d4a711afe1059a104f9c16f4ac7/autoload/quickpick.vim#L48-L57. getchar() isn't an option since it is blocking. This would solve the prompt issue but not popup issue)

[Christian Brabandt]

On Mo, 05 Okt 2020, Blay263 wrote:
> On Monday, October 5, 2020 at 10:28:08 AM UTC-4 Bram Moolenaar wrote:
>> I have been thinking of this, but it raises many questions:
>>
>> - How to focus a popup? I imagine in most cases you want to switch
>> between the current window and the popup, back and forth. This
>> matters especially if you already have a dozen split windows, you
>> don't want to cycle through all of them to reach the popup, and
>> you don't want to cycle through all windows to end up in the one
>> you were coming from.

Can't we amend CTRL-W_P to this? E.g. if there exists a popup window, go
to that one, else if there exists a preview window go to that one else
error. I would imagine, that the preview window is not of that much use
now with popup windows.

>> - If there is more than one focusable popup, how to reach each of
>> them? Perhaps some are connected to a specific window (e.g. for
>> completion or anchored to text), or some are unrelated to a
>> specific window (e.g. help).
>>
>> - What if the focused popup window closes? What if it closes while
>> you are typing (since they might be under control of some async
>> plugin)?
>>
>> - How to avoid this turns into an avalanche of more feature
>> requests? Aka creeping featurism.
>

> I think the use cases have been detailed above and are limited. Neovim
> provides a proof of concept. Not having the popup focusable is
> blocking specific functionality that is already available in Neovim.

So how does Neovim answer those questions raised?


Best,
Christian
--
Sie denkt: Wird er der Meine sein, ist bald auch all' das Seine mein.

[Bram Moolenaar]

Christian wrote:

> On Mo, 05 Okt 2020, Blay263 wrote:
> > On Monday, October 5, 2020 at 10:28:08 AM UTC-4 Bram Moolenaar wrote:
> >> I have been thinking of this, but it raises many questions:
> >>
> >> - How to focus a popup? I imagine in most cases you want to switch
> >> between the current window and the popup, back and forth. This
> >> matters especially if you already have a dozen split windows, you
> >> don't want to cycle through all of them to reach the popup, and
> >> you don't want to cycle through all windows to end up in the one
> >> you were coming from.
>
> Can't we amend CTRL-W_P to this? E.g. if there exists a popup window, go
> to that one, else if there exists a preview window go to that one else
> error. I would imagine, that the preview window is not of that much use
> now with popup windows.

Yeah, that could work. To remain backwards compatible CTRL-W P would
cycle through any preview and focusable popup windows. After the last
one back to the current window. Also, we can make Esc in Normal mode go
back to the current window, as it functions as a "get out of here" key.

I was thinking of a "focusable" flag for popups. That would require
another command to go to non-focusable popup windows (if you really want
to). Another way could be to have some kind of priority. Or let it
depend on the buffer type. Anyway, still lot of choices to get right.

--
Just remember...if the world didn't suck, we'd all fall off.

[ma...@prabir.me]

Here are the different phases I think we need to have based on my priority.

1. Focus (useful for fuzzy finders as well as peeking into docs/diagnostics error that are long or big)

a. "focusable" flag

b. win_gotoid(winid) to move focus to popup

2. All insert mode for popup (useful for fuzzy finders)

3. Cycle with Ctrl+W P

If we have #1 we don't need to worry about #3 or how to get out of popup though having a unified approach would make it consistent across different plugins.

I'm currently primarily interested in #1 and #2 only.

[ma...@prabir.me]

@Bram wondering if there has been any more thoughts on focusable popup windows? Wouldn't a focusable flag and support for win_gotoid(windid) be enough?

[Prabir Shrestha]

I sent a PR to allow win_gotoid(id) to focus to popup at #7555. I have also attached sample code to try out as well as a demo.

Please try it out and provide feedback before I go ahead updating docs and writing tests for it.