Neovim freezing when opening buffers

[atchim]

After this commit, every time I open a new buffer via :edit command or via NERDTree, Neovim freezes. The freeze seems to be forever unless I press ^C, which gives the following error message:

Error detected while processing BufReadPost Autocommands for "*":
E5108: Error executing lua Keyboard interrupt

Using :verbose edit I get the following message after the ^C:

E5108: Error executing lua Keyboard interrupt
not found in 'packpath': "pack/*/start/*/ftplugin/lua.vim ftplugin/lua_*.vim ftplugin/lua/*.vim"
not found in 'packpath': "start/*/ftplugin/lua.vim ftplugin/lua_*.vim ftplugin/lua/*.vim"
not found in 'packpath': "pack/*/start/*/indent/lua.vim"
not found in 'packpath': "start/*/indent/lua.vim"
not found in 'packpath': "pack/*/start/*/syntax/lua.vim syntax/lua/*.vim"
not found in 'packpath': "start/*/syntax/lua.vim syntax/lua/*.vim"
Press ENTER or type command to continue

[rmagatti]

I've seen something similar happen in a few cases too.

A simple reproducible case is to do :normal ciw.
It also seems to make Neovim hang when running a debug session with a breakpoint using nvim-dap for example.

[folke]

I'm not home right now, but will check later today.

One thing that I can think of that would trigger this behavior is when you have something like the below in your config:

autocmd FileType * :norm '"

This is to jump to the last location when opening a buffer, but this will trigger WhichKey for the registers.

If that's the case here, simply change it to norm! instead.

[folke]

I've seen something similar happen in a few cases too.

A simple reproducible case is to do :normal ciw.
It also seems to make Neovim hang when running a debug session with a breakpoint using nvim-dap for example.

That should work as expected. Will check when I'm home.

[folke]

@rmagatti Neovim does something weird when getchar() is being called from a norm command.

getchar(0) checks if there's pending input and will return it if there is. It returns 0 if there;'s no input left.

When doing that inside norm, vim keeps returning <esc> characters forever when there's no input left, instead of a 0, causing an endless loop.

I couldn't find any documentation about this behavior. Really weird.

Anyway, I was able to fix this by returning when we encounter the <esc> character \27, so norm bindings work as expected.

Also know that doing ciw in NORMAL mode inside a buffer did work as it should. It's the norm that does something weird.

[folke]

@atchim this might actually fix your problem too. There's probably an autocmd somewhere that triggered whichkey, which shouldn't be an issue, but because of that weird norm behavior there was an endless loop inside WhichKey*.

Can you try with the latest version to see if it still occurs?

[nghialm269]

@folke I can't use dd to delete current line after commit d66ffdd

[folke]

@nghialm269 sorry about that!! Forgot to remove my debug statements 🤦‍♂️ Fixed

[atchim]

@atchim this might actually fix your problem too. There's probably an autocmd somewhere that triggered whichkey, which shouldn't be an issue, but because of that weird norm behavior there was an endless loop inside WhichKey*.

Can you try with the latest version to see if it still occurs?

Now it's working fine. About the autocmd, probably it's from another plugin. Thanks for the fix! <3

[folke]

@atchim glad it works now. Thanks!

[rmagatti]

Yeah thanks for the quick response and for the awesome plugin @folke !

Cheers