Hey guys,
I have encountered quite strange bug while using neovim under st terminal
emulator. I press the delete key while being in insert mode and the help window
is opening. No character is removed. In normal mode it is the same. In neovim
under urxvt it doesn't happen nor in vanilla vim under st it doesn't happen.
Backspace works as usual. I know that st has a particular interpretation of
backspace and del, so I played with commands stty erase ^H and stty erasy
^? with no result. Outside of neovim delete works the same in st and urxvt, so
I think it is neovim issue (or libuv?).
In status line I caught quick keycode ~@%. It seems that it is F1, because
whenever I remap F1 to NOP the help window doesn't open. As a workaround I
remapped F1 to Del now.
I tested it with nvim -u NONE. My OS is ArchLinux, neovim version is from AUR.
NVIM 0.0.0-alpha+201506271522 (compiled Jun 28 2015 00:02:32)
Commit: 3ec0ede3a805df1a107a0d68220cde1beeeba386
I've encountered this for a while as well; have you sent a message to one of the suckless mailing lists?
Read the st FAQ. http://git.suckless.org/st/tree/FAQ
It's under "Why doesn't the Del key work in some programs?"
@Pyrohh Not yet. I think it is related to neovim as in vanilla vim under st del works perfectly fine.
@DarkDefender Well, thanks for suggestion, but none of their recommendations solves the problem in neovim. However, it solves this problem in bash and zsh (actually, in prezto these lines were already included).
I read some discussions from st mailing list. It seems that many applications doesn't respect terminfo rules. St devs don't want to add workarounds and suggest fixing those applications. Can anyone who understands libuv comment how it follows terminfo?
Thanks @DarkDefender, tput smkx fixes the issue for me.
Hi, it seems that fish is not the only one who has this issue, st will not changed the current setting, I think nvim should add a fix for the delete key too.
https://github.com/fish-shell/fish-shell/issues/2139
http://lists.suckless.org/dev/1509/27294.html
From that suckless thread the devs said that applications should be using setupterm. However libtermkey and neovim are using unibilium which is an alternative to ncurses for obtaining terminfo. unibilium uses its own implementation to read terminfo which results in this issue. You can test this by compiling libtermkey without unibilium support and then run the demo application without using tput. When you press DEL it will now say Key < Delete > since libtermkey now uses ncurses for the terminfo
TL;DR unibilium needs to be fixed to detect which mode its in or unibilium should be removed in favour for ncurses
Should this be fixed for the first release?
Ok I have found a "solution"
To make this work you need to change the unibi_pkey_* variables in termkey.c from libtermkey to unibi_keypad_*
Then in input.c from neovim change termkey_new_abstract(term, enc_flag); to termkey_new(0, enc_flag);
This "works" because calling termkey_new with 0 sets up termios however I am unsure of the exact mechanisms. I am also unsure if this breaks anything else.
@crondog Have you been testing your change since November?
@justinmk Unfortunately I haven't. I have updated neovim multiple times since then but without the patches. I'll make the changes now and let you know
@justinmk Yes my changes fix the issue. Also it is actually driver-ti.c in libtermkey you need to modify not termkey.c
Also it is actually driver-ti.c in libtermkey you need to modify not termkey.c
D'oh. That's what we've been trying to avoid :/ Still it's valuable to know, thanks.
Why do you want to avoid it? I have very minimal knowledge of terminfo but from what I can see here https://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.files/doc/aixfiles/terminfo.htm%23a72p01a driver-ti.c should be changed since pkey is for "Strings that program function keys " and keypad is for keypad keys which includes del
I mean we don't want to fork libtermkey. But looking at driver-ti.c, it does seem superficially odd.
@leonerd, can you explain why this line uses unibi_pkey_xmit instead of unibi_keypad_xmit? Similar question for unibi_pkey_local.
const char *keypad_xmit = unibi_get_str(unibi, unibi_pkey_xmit);
#endif
if(keypad_xmit)
ti->start_string = strdup(keypad_xmit);
else
ti->start_string = NULL;
#ifdef HAVE_UNIBILIUM
const char *keypad_local = unibi_get_str(unibi, unibi_pkey_local);
Ah oops. I did the migration to unibilium while its author was still creating it; there's a chance I managed to miss the keypad versions of those strings, or something. In any case, yes I suspect it ought to be using keypad, not pkey.
@leonerd Hopefully :) Let me know if you want me to test anything
Hi,
Sorry to bump this, but has anyone been able to fix this yet from within neovim (as in remap a keybinding or something)?
Well, I just remapped F1 to NOP. It doesn't make Del working, but at least remove the annoying help window.
st fails now
I mapped F1 to del which is a very dirty fix but works if you never use F1 to open the help window. Put these two lines in your $XDG_CONFIG_HOME/nvim/init.vim:
map <F1> <del>
map! <F1> <del>
The issue itself is not fixed in my installation of neovim on Arch (i.e. pressing del is still parsed as pressing F1 by neovim).
~ % nvim --version
NVIM 0.1.4
Build type: RelWithDebInfo
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -Wconversion -O2 -g -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -DHAVE_CONFIG_H -D_GNU_SOURCE -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.1.4/src -I/usr/include -I/usr/include -I/usr/include/luajit-2.0 -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser
Optional features included (+) or not (-): +acl +iconv +jemalloc
For differences from Vim, see :help vim-differences
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
I have also found out that Insert key has also failed in nvim when using st while vim works, I think these might be the bugs of libuv.
In insert mode, it doesn't switch to replace mode when I press Insert. The terminfo (I think so) for Insert and Delete can be seen here:
{ XK_KP_Insert, XK_ANY_MOD, "\033[4h", -1, 0, 0},
{ XK_KP_Insert, XK_ANY_MOD, "\033[2~", +1, 0, 0},
...
{ XK_KP_Delete, XK_ANY_MOD, "\033[P", -1, 0, 0},
{ XK_KP_Delete, XK_ANY_MOD, "\033[3~", +1, 0, 0},
libuv is not related to this.
@justinmk libtermkey (which is deprecated, now libticket)? Since vim doesn't have any of these problems.
Remapping F1 to Del for now. Even though, Del should mean Del.
@kevinkjt2000 Are you using master, or a stable release?
This should be fixed on master, _assuming_ your build is linked against libtermkey 0.19 (which is what master pulls down automatically and what we recommend going forward).
https://github.com/neovim/libtermkey/commit/e044a1603ec1d30e7b8cc765598c3160c857c367
I played with commands stty erase ^H and stty erasy ^? with no result.
@kshmelkov stty is respected since https://github.com/neovim/neovim/pull/5758
@justinmk Using nvim 0.1.7 from the arch linux community repo. I'll try out the aur neovim-git package... A few minutes later, now I am running 0.2.0-354-g947101987a, and the DEL key still behaves as F1 :(
I got lucky with "tput smkx". When run beforehand, this command makes the DEL key behave correctly in bash and also in neovims launched from that bash. So I'll put this in my bashrc for now, and remove the mapping of F1 to DEL.
But you didn't say what version of libtermkey was installed.
Update: At least one user confirmed the problem is fixed with nvim master + libtermkey 0.19.
@justinmk Same issue here. I just compiled latest neovim master (and as I am on CentOS 6 there is no libtermkey from the repos so it downloaded libtermkey 0.19). I still have the issue with DEL sending F1. But also as with @kevinkjt2000 the issue is fixed when I use tput smkx before starting nvim (by the way also with latest 0.1.7 release, but I have no idea what version of libtermkey that one pulled when I compiled it).
As to my understanding tput smkx should be used by e.g. the shell when it provides the prompt for user input and right after that should use tput rmkx before executing the given command. That's how I configured my fish shell. So what I guess here is that neovim is supposed to use tput smkx (because it expects user input) on its own, isn't it?
For the record: F1 and DEL work for me as expected with libtermkey 0.19 and current master without any special settings regarding smkx.
Just to be sure, I removed all my hacks regarding tput smkx from my .bashrc as well as my config.fish and rebooted.
I used the following software:
CentOS release 6.8 (Final)st 0.7 with st-256color set as $TERMbash 4.1.2fish 2.4.0tmux 2.3 with screen-256color set as default-terminalnvim masterlibtermkey 0.19 (as pulled by current nvim master)to try the following combinations:
DEL sends F1DEL sends F1DEL sends F1DEL sends F1And for comparison:
tput smkx -> DEL workstput smkx + tmux -> DEL workstput smkx -> DEL workstput smkx + tmux -> DEL works@justinmk libtermkey 0.19-1 is installed.
I am experiencing the same results as @wilriker
ArchLinux latest
st 0.7
bash 4.4.5
nvim 0.2.0-354-g94101987a
tmux 2.3
libtermkey 0.19-1
Might be worth trying this out in libtermkey's own demo program, entirely outside of anything in neovim.
leo@shy:~/src/libtermkey [bzr]
$ ./demo
Termkey in UTF-8 mode
Key <F1>
Key <Delete>
Key <C-c>
is what I get anyway on a plain pangoterm.
@leonerd I tried this and I get the exact same results as you using st + fish regardless wether I emit tput smkx or not. So libtermkey _seems_ to do the right thing.
$ ./demo
Termkey in UTF-8 mode
Key <F1>
Key <Delete>
Key <C-c>
and
$ begin
tput smkx
./demo
end
Termkey in UTF-8 mode
Key <F1>
Key <Delete>
Key <C-c>
I see. So it seems the F1/Del conflation is related to nvim?
Not sure if it helps, but there are different key codes for delete depending on what terminal you use. My shell is fish by the way. With st:
~> fish_key_reader
Press a key
hex: 1B char: \c[ (or \e)
( 0.161 ms) hex: 5B char: [
( 0.154 ms) hex: 50 char: P
bind \e\[P 'do something'
With urxvt:
~> fish_key_reader
Press a key
hex: 1B char: \c[ (or \e)
( 0.138 ms) hex: 5B char: [
( 0.119 ms) hex: 33 char: 3
( 0.115 ms) hex: 7E char: ~
bind -k dc 'do something'
bind \e\[3~ 'do something'
With st del is opening the help menu but not with urxvt.
@tomkel Yeah, this is due to the fact that fish_key_reader is not run in keyboard interactive mode. If you run the following in st
begin
tput smkx
fish_key_reader
end
and then press DEL it yields the exact same result as what you've posted for urxvt. This is basically what this thread is all about: neovim is supposed to set the terminal to keyboard interactive mode but somehow fails to do so. That's why DEL is interpreted as F1 (and thus opening help) instead of DEL.
BTW: As a workaround until this is finally solved I created a fish function:
function nvim
tput smkx
command nvim $argv
end
Glad I eventually came across this issue. Inspired by @wilriker, the following works for zsh
# fix delete key in neovim for the time being
nvim(){
tput smkx
command nvim $@
}
@felixsanz I haven't noticed this in the versions of st-0.7, tmux 2.4.r66.g9d041d8e, bash 4.4.12, libtermkey 0.20-1, and NVIM v0.2.0-1442-g1fe894574 that I am running. I took out tput smkx from my bashrc almost a month ago https://github.com/kevinkjt2000/dot-bash/commit/b21a408801886c2998aca85ebeb2f6ad521800bb
Yeah, tput smkx fix it, but it's a workaround
@kevinkjt2000 This is not really fixed but tmux introduced a change in 2.4 that always sends tput smkx to the outside terminal.
If you test it without tmux in between you will see that the issue still exists.
I'm affected by this issue, too. It makes it very inconvenient to use nvim in st.
Please report the exact output of nvim --version and $TERM. Otherwise "me too" comments don't help.
If you haven't already, please try nvim master (pre-release), there were many TUI changes that aren't in 0.2.0.
$ nvim --version
NVIM v0.2.0
Build type: RelWithDebInfo
Compilation: /usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/config -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/src/nvim/auto -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/include
Compiled by root@gentoo
Optional features included (+) or not (-): +acl +iconv +jemalloc +tui
For differences from Vim, see :help vim-differences
system vimrc file: "/etc/vim/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
$ echo $TERM
st-256color
I think I'll try the latest master commit.
I just compiled and tried the latest commit from the master branch. The issue doesn't exist on the latest commit.
For the record (I also experienced the bug) the commit that fixed was this one 5701165f06104c341dce9f19ba8437676139892b.
Great! Thanks for confirming.
For people like me who neither want to run a git version nor want to wait for the release, you can just apply the patch @kazuoteramoto mentioned by downloading it from this url: https://github.com/neovim/neovim/commit/5701165f06104c341dce9f19ba8437676139892b.diff
Applying this patch on top of tag v0.2.0 fixed this particular issue for me.
Wow. It surprises me that that is necessary. libtermkey ought to be doing that on setup/teardown itself. If it's not, I'd suggest something else is wrong somewhere
Idk if it helps but here's the output of nvim --version
NVIM v0.2.0
Build type: RelWithDebInfo
Compilation: /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/config -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/src/nvim/auto -I/var/tmp/portage/app-editors/neovim-0.2.0/work/neovim-0.2.0_build/include
Compiled by portage@christoph-lap
Optional features included (+) or not (-): +acl +iconv +jemalloc +tui
For differences from Vim, see :help vim-differences
system vimrc file: "/etc/vim/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
libtermkey version is 0.19
I'm on Gentoo with a 4.13.0+ x86_64 mainline kernel
Using st version 0.7 and zsh 5.3.1
Most helpful comment
@kevinkjt2000 This is not really fixed but
tmuxintroduced a change in 2.4 that always sendstput smkxto the outside terminal.If you test it without
tmuxin between you will see that the issue still exists.