AstroNvim
AstroNvim copied to clipboard
Delete / x key in normal mode is no longer repeatable by holding key down
Checklist Please confirm you have run the following commands and restarted Neovim and are encountering the issue with the current latest version of AstroNvim
- [x]
:PackerSync - [x]
:AstroUpdate - [x] restarted AstroNvim
- [x] Neovim version >= 0.7.0
Describe the bug
Holding Delete, or x key should delete multiple characters, and the whole screen should not flash.
To Reproduce
- Start new buffer
- Type
ihello<Esc>0(i.e. enterhelloand move the cursor back to the start of the line) - Hold
x
Expected behavior
the word hello should get deleted letter by letter.
Screenshots Screencast from 29-07-22 17:39:44.webm
NVIM v0.7.0
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wsuggest-attribute=pure -Wsuggest-attribute=const -Wsuggest-attribute=malloc -Wsuggest-attribute=cold -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az316-460
Features: +acl +iconv +tui
See ":help feature-compile"
I cannot reproduce this on my side. I tested on MacOS.
NVIM v0.7.2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by [email protected]
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/opt/homebrew/Cellar/neovim/0.7.2_1/share/nvim"
I am new to astrovim and at present my user config is very minimal, so it seems odd. Uploaded my user init.lua file (had to rename it as .md for github rules) my-user-init.md
@artfulrobot what terminal/OS are you using? I also can't reproduce this on Linux with Kitty terminal.
I'm on Gnome terminal 3.44.0 (for GNOME 42 on Ubuntu 22.04) but I get the same behavior with kitty too.
I think it might be because I didn't move the site dir before installing astronvim. 'x' works as normal when running astronvim on a different server over ssh. So it's not the terminal.
On my troubled machine, I tried to reset nvim by various means, including each of:
mv ~/.local/share/nvim/site{,-bak}mv ~/.local/share/nvim{,-bak}
However then astronvim crashed and wouldn't start! How can I make it 'reinstall' afresh?
When I say crash, I mean it gave a page of errors and then loaded vanilla nvim, no astronvim stuff anywhere:
Error detected while processing ~/.config/nvim/init.lua:
Failed to load core.utils
~/.config/nvim/lua/core/utils/init.lua:22: attempt to call field 'notify' (a nil value)
Failed to load core.options
...
And I can't run PackerSync / PackerInstall as Packer is not installed!
Edit
I removed ~/.config/nvim and ~/.local/share/nvim and recloned and put my user/init.lua back and it reinstalled ok (would still like to know how to do this without deleting everything).
So I'm on a fresh install but the problem persists on my Ubuntu laptop!
@artfulrobot do you have any user configuration that could be consuming the key? If so, could you share your user config and see if we can try debugging it? Also you mentioned that it works over ssh to a remote server in the same terminal. Do you have the same config loaded in the other remote server as well? If so, that is very very curious 🤔
yes, same config!
I'll be the first to admit that this is starting to look like a weird local issue...
Yeah I am venturing a guess that this is a weird local issue. A few things that immediately come to mind is checking out your shell configs and see if that could be causing anything. A chance in your remote shell config vs your local shell config and potentially your $TERM variable changing as your SSH could change behavior between your shells as well.
Other than that I can't reproduce in any way and I think that this isn't related to AstroNvim's configuration of Neovim. I also am not sure how much more help I can be on this issue so I'm going to go ahead and close this, but if you gain any more insight like a fix or if you do identify that it is an AstroNvim issue please comment back with an update for future users or for me to reopen the issue. Sorry I'm not much more help on this!
@mehalter sure, thanks for your time. I'll continue to comment here as and when I find anything out, but I don't expect you to do anything about it :-)
- Running
vim -u /dev/null(i.e. without a config file) delete works. conclusion it is a config problem - Running
vim --no-pluginsdelete fails; conclusion: it is not a plugin problem. - Commenting out
core.pluginsthroughconfigs.which-key-registerin~/.config/nvim/init.lua, and commenting out the finalastronvim.conditional_func()and the first two lines re impatient, the problem exists. conclusion: the problem is somewhere incore.utils,core.options,core.bootstrap
Problem persists in bash/zsh, both with TERM=xterm-256color. Yet is not present through ssh where the shell is also zsh and TERM the same.
I am having the same issue. Commenting out clipboard = "unnamedplus" in core.options fixes the problem. It appears that it is an issue with neovim itself, as the issue persists if I have a completely empty config and run the command set clipboard=unnamedplus.
@bezmi thanks for reporting and investigating some more. Just to let you know you will not want to modify any of the AstroNvim core files. You will want to make all of your modifications in your user/init.lua file. Here is an example that disables the clipboard:
return {
options = {
opt = {
clipboard = "", -- Use default clipboard value
},
},
}
Thanks for the heads up, I'm well aware of that. I was just trying to track down this issue. I don't think I can live without the system clipboard unfortunately ("+y and "+p gets old quickly), so time for some bug hunting on the neovim side of things :(.
This issue is reproduceable on both my work and home computers. Both running archlinux, gnome 42.4, neovim 0.7.2.
@bezmi Thank you for reporting the temporary fix back, this has been annoying to me as well. I am running a few day old neovim master build and Gnome 42.4 and see the same issue and fix.
Seems to be a well known issue with wayland, although it seems to have gotten worse than the reports in those threads from the looks of it. It is because using 'x' to delete is actually sending these keys to the system clipboard with unnamed and unnamedplus. I think it's best to do something like this as a work-around.
Ah ha! interesting.
Found a workaround.
{
mappings: {
n = {
x = { "i<delete><right><esc>" }
...