-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
Closed
Labels
floatwinfloating windows, popups, hoverfloating windows, popups, hoverhas:workaroundissue is not fixed but can be circumvented until thenissue is not fixed but can be circumvented until thenui
Description
When you use nvim_open_win
with relative=win
and point win=
to a floating window, then the new float will be relative to the original non-floating window.
Steps to reproduce using nvim -u NORC
local function popup(win, bg)
win = win or vim.api.nvim_get_current_win()
local buf = vim.api.nvim_create_buf(false, true)
local ret = vim.api.nvim_open_win(buf, true, {
relative = "win",
win = win,
col = 4,
row = 4,
width = 20,
height = 10,
})
vim.api.nvim_win_set_option(ret, "winhl", "Normal:" .. bg .. ",EndOfBuffer:" .. bg)
return ret
end
vim.cmd([[hi Popup1 guibg=red]])
vim.cmd([[hi Popup2 guibg=yellow]])
local p1 = popup(nil, "Popup1")
local p2 = popup(p1, "Popup2")
Actual behaviour
Both the yellow and red floating window will be shown at the same place
Expected behaviour
The second yellow window should be positioned relative to the first one, with an offset of 4 rows and 4 columns
Other weird stuff
-
When doing a vsplit of the current window, and then running the code when the second window is active, you'll see that:
- the red popup opens in the right window
- the yellow popup opens in the left window (still at the wrong position)
-
Probably related to nvim_win_get_position not work after nvim_open_win #13403:
nvim_win_get_position
always returns[0,0]
for floats -
vim.api.nvim_win_get_number
of the floating window, returns the window number of the window where the float was created.
MunifTanjim
Metadata
Metadata
Assignees
Labels
floatwinfloating windows, popups, hoverfloating windows, popups, hoverhas:workaroundissue is not fixed but can be circumvented until thenissue is not fixed but can be circumvented until thenui