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

BufWinEnter not called for floating window buffer #27121

Closed
stevearc opened this issue Jan 21, 2024 · 6 comments
Closed

BufWinEnter not called for floating window buffer #27121

stevearc opened this issue Jan 21, 2024 · 6 comments
Labels
bug-regression wrong behavior that was introduced in a previous commit (please bisect) events events, autocommands float floating windows
Milestone

Comments

@stevearc
Copy link
Sponsor Contributor

Problem

When opening a floating window with nvim_open_win and enter = false, the BufWinEnter autocmd is not called for the buffer.

Steps to reproduce

Here is a minimal repro

local bufnr = vim.api.nvim_create_buf(false, true)
vim.api.nvim_buf_set_lines(bufnr, 0, 1, false, { "Waiting..." })

vim.api.nvim_create_autocmd("BufWinEnter", {
	desc = "Aerial render symbols after buffer loads in window",
	buffer = bufnr,
	once = true,
	callback = function(params)
		vim.api.nvim_buf_set_lines(params.buf, 0, 1, false, { "BufWinEnter called" })
	end,
})

vim.api.nvim_open_win(bufnr, false, {
	relative = "editor",
	row = 2,
	col = 2,
	width = 40,
	height = 20,
	style = "minimal",
})

Sourcing this file on nightly produces a floating window that says "Waiting...". Sourcing it in 0.9.x produces a floating window that says "BufWinEnter called". BufWinEnter is called if we pass enter = true in nvim_open_win. This also does not appear to occur with splits.

Expected behavior

BufWinEnter should be called when the buffer is first displayed in the floating window

Neovim version (nvim -v)

v0.10.0-dev-2143+g3f188bc53

Vim (not Nvim) behaves the same?

N/A

Operating system/version

Ubuntu 22.04

Terminal name/version

kitty 0.31.0

$TERM environment variable

tmux-256color

Installation

build from source

@stevearc stevearc added the bug issues reporting wrong behavior label Jan 21, 2024
@zeertzjq zeertzjq added events events, autocommands float floating windows bug-regression wrong behavior that was introduced in a previous commit (please bisect) and removed bug issues reporting wrong behavior labels Jan 21, 2024
@zeertzjq zeertzjq added this to the 0.10 milestone Jan 21, 2024
@zeertzjq
Copy link
Member

zeertzjq commented Jan 21, 2024

Related #15300

@justinmk

This comment was marked as resolved.

@zeertzjq
Copy link
Member

Hmm, the current behavior is inconsistent with nvim_win_set_buf

@stevearc
Copy link
Sponsor Contributor Author

If enter = false why would you expect BufWinEnter to fire?

I would expect BufEnter to not fire, since we're not entering the buffer, but from :help BufWinEnter:

BufWinEnter			After a buffer is displayed in a window.  This
				may be when the buffer is loaded (after
				processing modelines) or when a hidden buffer
				is displayed (and is no longer hidden).

That to me sounds like it should fire even if the window doesn't have focus. Another way to put it: I would expect there to be an invariant that if a buffer is displayed in a window, BufWinEnter has been dispatched.

@glepnir
Copy link
Member

glepnir commented Jan 22, 2024

there use enter as condition so when it's false . BufWinEnter not fired in win_set_buf, maybe can trigger it under win_set_buf

Boolean noautocmd = !enter || fconfig.noautocmd;
win_set_buf(wp, buf, noautocmd, err);

@asmodeus812
Copy link

@justinmk Not sure if related, but on the contrary, if we create the hover window, and set focused = false, vim.fn.win_gettype() still returns "popup", if we call it right after the hover is opened. even though the focus stays on the main window, and does not enter the hover (this happens with pretty much all popup windows)

seandewar added a commit to seandewar/neovim that referenced this issue Feb 7, 2024
Problem: BufWinEnter is not fired when not entering a new window, even when the
buffer is now no longer hidden and buffer-related autocommands are not blocked
(`!noautocmd`).

Solution: fire it in the context of the new window and buffer.
Be wary of autocommands screwing us over! For example, it's possible for
`nvim_win_set_config` to be used in an autocommand to move a window to a
different tabpage (in contrast, things like `wincmd T` actually create a *new*
window, so it may not have been possible before, meaning other parts of Nvim
could assume windows can't do this...).

Also add some test coverage for `nvim_open_win` autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Feb 11, 2024
…r && !noautocmd`

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(`!noautocmd`).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like `:{s}buffer`.

Be wary of autocommands screwing us over! For example, it's possible for
`nvim_win_set_config` to be used in an autocommand to move a window to a
different tabpage (in contrast, things like `wincmd T` actually create a *new*
window, so it may not have been possible before, meaning other parts of Nvim
could assume windows can't do this...).

Also, bail early from `win_set_buf` if setting the temp curwin fails; this
shouldn't be possible, as the callers check that `wp` is valid, but in case
that's ever not true, `win_set_buf` will no longer continue setting a buffer for
the wrong window.

Note that `pum_create_float_preview` also uses `win_set_buf`, but from a glance,
doesn't look like it properly checks for autocmds screwing things up
(`win_enter`, `nvim_create_buf`...). I haven't addressed that here.

Also adds some test coverage for `nvim_open_win` autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Feb 24, 2024
…r && !noautocmd`

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(`!noautocmd`).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like `:{s}buffer`.

Be wary of autocommands screwing us over! For example, it's possible for
`nvim_win_set_config` to be used in an autocommand to move a window to a
different tabpage (in contrast, things like `wincmd T` actually create a *new*
window, so it may not have been possible before, meaning other parts of Nvim
could assume windows can't do this...).

Also, bail early from `win_set_buf` if setting the temp curwin fails; this
shouldn't be possible, as the callers check that `wp` is valid, but in case
that's ever not true, `win_set_buf` will no longer continue setting a buffer for
the wrong window.

Note that `pum_create_float_preview` also uses `win_set_buf`, but from a glance,
doesn't look like it properly checks for autocmds screwing things up
(`win_enter`, `nvim_create_buf`...). I haven't addressed that here.

Also adds some test coverage for `nvim_open_win` autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Feb 25, 2024
…r && !noautocmd`

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(`!noautocmd`).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like `:{s}buffer`.

Be wary of autocommands screwing us over! For example, it's possible for
`nvim_win_set_config` to be used in an autocommand to move a window to a
different tabpage (in contrast, things like `wincmd T` actually create a *new*
window, so it may not have been possible before, meaning other parts of Nvim
could assume windows can't do this...).

Also, bail early from `win_set_buf` if setting the temp curwin fails; this
shouldn't be possible, as the callers check that `wp` is valid, but in case
that's ever not true, `win_set_buf` will no longer continue setting a buffer for
the wrong window.

Note that `pum_create_float_preview` also uses `win_set_buf`, but from a glance,
doesn't look like it properly checks for autocmds screwing things up
(`win_enter`, `nvim_create_buf`...). I haven't addressed that here.

Also adds some test coverage for `nvim_open_win` autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Feb 26, 2024
…r && !noautocmd`

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(`!noautocmd`).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like `:{s}buffer`.

Be wary of autocommands screwing us over! For example, it's possible for
`nvim_win_set_config` to be used in an autocommand to move a window to a
different tabpage (in contrast, things like `wincmd T` actually create a *new*
window, so it may not have been possible before, meaning other parts of Nvim
could assume windows can't do this...).

Also, bail early from `win_set_buf` if setting the temp curwin fails; this
shouldn't be possible, as the callers check that `wp` is valid, but in case
that's ever not true, `win_set_buf` will no longer continue setting a buffer for
the wrong window.

Note that `pum_create_float_preview` also uses `win_set_buf`, but from a glance,
doesn't look like it properly checks for autocmds screwing things up
(`win_enter`, `nvim_create_buf`...). I haven't addressed that here.

Also adds some test coverage for `nvim_open_win` autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Feb 27, 2024
…r && !noautocmd`

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(`!noautocmd`).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like `:{s}buffer`.

Be wary of autocommands screwing us over! For example, it's possible for
`nvim_win_set_config` to be used in an autocommand to move a window to a
different tabpage (in contrast, things like `wincmd T` actually create a *new*
window, so it may not have been possible before, meaning other parts of Nvim
could assume windows can't do this...).

Also, bail early from `win_set_buf` if setting the temp curwin fails; this
shouldn't be possible, as the callers check that `wp` is valid, but in case
that's ever not true, `win_set_buf` will no longer continue setting a buffer for
the wrong window.

Note that `pum_create_float_preview` also uses `win_set_buf`, but from a glance,
doesn't look like it properly checks for autocmds screwing things up
(`win_enter`, `nvim_create_buf`...). I haven't addressed that here.

Also adds some test coverage for `nvim_open_win` autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Feb 28, 2024
… && !noautocmd

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(!noautocmd).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like :{s}buffer.

Be wary of autocommands! For example, it's possible for nvim_win_set_config to
be used in an autocommand to move a window to a different tabpage (in contrast,
things like wincmd T actually create a *new* window, so it may not have been
possible before, meaning other parts of Nvim could assume windows can't do
this... I'd be especially cautious of logic that restores curwin and curtab
without checking if curwin is still valid in curtab, if any such logic exists).

Also, bail early from win_set_buf if setting the temp curwin fails; this
shouldn't be possible, as the callers check that wp is valid, but in case that's
not true, win_set_buf will no longer continue setting a buffer for the wrong
window.

Note that pum_create_float_preview also uses win_set_buf, but from a glance,
doesn't look like it properly checks for autocmds screwing things up (win_enter,
nvim_create_buf...). I haven't addressed that here.

Also adds some test coverage for nvim_open_win autocommands.

Closes neovim#27121.
seandewar added a commit to seandewar/neovim that referenced this issue Mar 8, 2024
… && !noautocmd

Problem: BufWinEnter is not fired when not entering a new window, even when a
different buffer is specified and buffer-related autocommands are unblocked
(!noautocmd).

Solution: fire it in the context of the new window and buffer. Do not do it if
the buffer is unchanged, like :{s}buffer.

Be wary of autocommands! For example, it's possible for nvim_win_set_config to
be used in an autocommand to move a window to a different tabpage (in contrast,
things like wincmd T actually create a *new* window, so it may not have been
possible before, meaning other parts of Nvim could assume windows can't do
this... I'd be especially cautious of logic that restores curwin and curtab
without checking if curwin is still valid in curtab, if any such logic exists).

Also, bail early from win_set_buf if setting the temp curwin fails; this
shouldn't be possible, as the callers check that wp is valid, but in case that's
not true, win_set_buf will no longer continue setting a buffer for the wrong
window.

Note that pum_create_float_preview also uses win_set_buf, but from a glance,
doesn't look like it properly checks for autocmds screwing things up (win_enter,
nvim_create_buf...). I haven't addressed that here.

Also adds some test coverage for nvim_open_win autocommands.

Closes neovim#27121.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-regression wrong behavior that was introduced in a previous commit (please bisect) events events, autocommands float floating windows
Projects
None yet
Development

No branches or pull requests

5 participants