<C-h> (CTRL-H) does not work in the new TUI #2048

Closed
rainerborene opened this Issue Feb 23, 2015 · 169 comments

Projects

None yet
@rainerborene
Contributor

I use the following mappings on my .nvimrc and it does not work using tmux inside urxvt.

nnoremap <C-h> <C-w>h " only C-h does not work.
nnoremap <C-j> <C-w>j
nnoremap <C-k> <C-w>k
nnoremap <C-l> <C-w>l

env output

BROWSER=firefox
COLORFGBG=7;0
COLORTERM=rxvt
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-zNeYXuznrs,guid=844332d151bf76af0ebfba3754e5f937
DESKTOP_SESSION=i3
DESKTOP_STARTUP_ID=i3/i3-sensible-terminal/725-0-arch_TIME89282
DISPLAY=:0
DOCKER_HOST=unix:///var/run/docker.sock
EDITOR=vim
GDMSESSION=i3
GDM_LANG=en_US.utf8
GPG_TTY=/dev/pts/5
GREP_COLOR=97;45
GTK_MODULES=canberra-gtk-module
HG=/usr/bin/hg
LANG=en_US.utf8
LC_MEASUREMENT=pt_BR.utf8
LC_MONETARY=pt_BR.utf8
LC_NUMERIC=pt_BR.utf8
LC_PAPER=pt_BR.utf8
LC_TIME=pt_BR.utf8
LS_COLORS=no=00;37:fi=01;34:di=00;34:ln=00;36:pi=40;33:so=00;35:do=00;35:bd=40;33;01:cd=40;33;01:or=00;05;37;41:mi=00;05;37;41:su=37;41:sg=30;43:tw=30;42:ow=04;34:st=37;44:ex=00;32:*.cmd=00;33:*.exe=00;33:*.com=00;33:*.btm=00;33:*.bat=00;33:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz=01;31:*.bz2=01;31:*.bzip2=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.apk=01;31:*.gem=01;31:*.jpg=00;35:*.JPG=00;35:*.jpeg=00;35:*.gif=00;35:*.bmp=00;35:*.pbm=00;35:*.pgm=00;35:*.ppm=00;35:*.tga=00;35:*.xbm=00;35:*.xpm=00;35:*.tif=00;35:*.tiff=00;35:*.png=00;35:*.svg=00;35:*.svgz=00;35:*.mng=00;35:*.pcx=00;35:*.dl=00;35:*.xcf=00;35:*.xwd=00;35:*.yuv=00;35:*.cgm=00;35:*.emf=00;35:*.eps=00;35:*.CR2=00;35:*.ico=00;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.html=00;32:*.rst=00;32:*.md=00;32:*.patch=00;32:*.diff=00;32:*.tex=00;32:*.doc=00;32:*.xml=00;32:*.xls=00;32:*.xlsx=00;32:*.doc=00;32:*.docx=00;32:*.ppt=00;32:*.pptx=00;32:*.key=00;32:*.pt=01;32:*.tmpl=01;32:*.in=01;32:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.m4a=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:*.mov=01;36:*.mpg=01;36:*.mpeg=01;36:*.m2v=01;36:*.mkv=01;36:*.ogm=01;36:*.mp4=01;36:*.m4v=01;36:*.mp4v=01;36:*.vob=01;36:*.qt=01;36:*.nuv=01;36:*.wmv=01;36:*.asf=01;36:*.rm=01;36:*.rmvb=01;36:*.flc=01;36:*.avi=01;36:*.fli=01;36:*.flv=01;36:*.gl=01;36:*.m2ts=01;36:*.divx=01;36:*.webm=01;36:*.axv=01;36:*.anx=01;36:*.ogv=01;36:*.ogx=01;36:*.conf=00;36:*.cnf=00;36:*.cfg=00;36:*.ini=00;36:*.properties=00;36:*.yaml=00;36:*.vcl=00;36:*.c=00;33:*.cpp=00;33:*.py=00;33:*.coffesscript=00;33:*.js=00;33:*.rb=00;33:*.sh=00;33:*.zsh=00;33:*.env=00;33:*.bash=00;33:*.php=00;33:*.java=00;33:*.zcml=00;33:*.db=00;32:*.sql=00;32:*.json=00;32:*.plist=00;32:*.fs=00;32:*.tex=01;37:*.rdf=01;37:*.owl=01;37:*.n3=01;37:*.ttl=01;37:*.nt=01;37:*.torrent=01;37:*.xml=01;37:*Makefile=01;37:*Rakefile=01;37:*build.xml=01;37:*rc=01;37:*.nfo=01;37:*README=01;37:*README.txt=01;37:*readme.txt=01;37:*README.markdown=01;37:*README.md=01;37:*.ini=01;37:*.yml=01;37:*.cfg=01;37:*.conf=01;37:*.c=01;37:*.cpp=01;37:*.cc=01;37:*.log=01;30:*.bak=01;30:*.aux=01;30:*.lof=01;30:*.lol=01;30:*.lot=01;30:*.out=01;30:*.toc=01;30:*.bbl=01;30:*.blg=01;30:*~=01;30:*#=01;30:*.part=01;30:*.incomplete=01;30:*.swp=01;30:*.tmp=01;30:*.temp=01;30:*.o=01;30:*.obj=01;30:*.pyc=01;30:*.pyo=01;30:*.class=01;30:*.cache=01;30:*.egg-info=01;30:
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
SHELL=/usr/bin/fish
SHLVL=4
SSH_AGENT_PID=746
SSH_AUTH_SOCK=/tmp/ssh-J6jf9XAbiTjD/agent.725
TERM=screen-256color
TERMINFO=/usr/share/terminfo
TMUX=/tmp/tmux-1000/default,1161,11
TMUX_PANE=%27
WINDOWID=23068681
WINDOWPATH=1
WINEARCH=win32
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=i3
XDG_SESSION_ID=c2
XDG_VTNR=1
__fish_bin_dir=/usr/bin
__fish_datadir=/usr/share/fish
__fish_help_dir=/usr/share/doc/fish
__fish_runtime_dir=/run/user/1000
__fish_sysconfdir=/etc/fish
fish_greeting=
@rainerborene rainerborene changed the title from map <C-h> <C-w>h does not work in the new TUI to <C-h> does not work in the new TUI Feb 23, 2015
@jwkvam
jwkvam commented Feb 23, 2015

I experience the same on OSX with iterm2.

@tarruda
Member
tarruda commented Feb 23, 2015

what is displayed if you type <c-v><c-h> in insert mode?

@jwkvam
jwkvam commented Feb 23, 2015

With nvim, Commit: 0df6b91
<BS>
With vim 7.4.488
^H
I'm using the same config for both vim and neovim.

@rainerborene
Contributor

Same here. <BS>

@tarruda
Member
tarruda commented Feb 23, 2015

any chance you compiled against the wrong libtermkey version? Does rm -rf .deps build && make && build/bin/nvim change anything?

@jwkvam
jwkvam commented Feb 23, 2015

Same behavior for me.
- downloading... src='https://github.com/neovim/libtermkey/archive/8c0cb7108cc63218ea19aa898968eede19e19603.tar.gz'

@tarruda
Member
tarruda commented Feb 23, 2015

what is displayed when you press ctrl+h in the cat program?

@jwkvam
jwkvam commented Feb 23, 2015

^H, the same happens with xxd.

@foobacca

I use <C-h> for gT (move to tab left) and just tested and it works as expected. And <c-v><c-h> shows ^H

I'm using the PPA version of nvim - tried 0.0.0+git201502201750+6ubuntu14.04.1 and 0.0.0+git201502221955+6ubuntu14.04.1 - both work fine.

I run in tmux in terminator on Ubuntu.

@jwkvam
jwkvam commented Feb 23, 2015

FWIW, I bisected the merges and it broke at merge #2039

@tarruda tarruda self-assigned this Feb 24, 2015
@tarruda
Member
tarruda commented Feb 24, 2015

@jwkvam that PR didn't change anything related to parsing these keys: https://github.com/neovim/neovim/pull/2039/files

As I said, there was a problem with how libtermkey handled ctrl+h or backspace, but it was fixed in a recent commit: neovim/libtermkey@619c0c1

@geoffharcourt
Contributor

Experiencing the same problem on the latest build (61c98e7). I'm in iTerm, and the problem happens both inside and outside of tmux. <c-v><c-h> prints <BS>.

@geoffharcourt
Contributor

One further detail: this problem happens in nvim with a blank .vimrc.

@acoffman

I'm experiencing exactly this same problem.
It happens on a totally clean install with no plugins:

The entire contents of my .nvimrc are

" navigate splits
nmap <silent> <C-k> :wincmd k<CR>
nmap <silent> <C-j> :wincmd j<CR>
nmap <silent> <C-h> :wincmd h<CR>
nmap <silent> <C-l> :wincmd l<CR>

I'm using OSX 10.10.2 with iTerm2 and NVIM 0.0.0-alpha+201502261923. The problem occurs both inside and outside of tmux and also in Terminal.app. All three other bindings work, but <C-h> does not.

@acoffman

Oh, and <c-v><c-h> in insert mode prints <BS> in the current buffer.

@adambiggs

Same thing here. Default left-navigation key mapping for the vim-tmux-navigator plugin is broken.

iTerm on OSX 10.10.2. With & without Tmux. Also broken in Terminal.app. Works fine in terminal MacVim.

@lambdahands

Experiencing this as well.

iTerm on OSX 10.10.2

@af
af commented Mar 3, 2015

I'm also fighting with trying to bind <C-h>. iTerm2 on OS X 10.10.2, using NVIM-0.0.0-alpha+201503020458.

It's not a good solution, but if you're looking for a workaround, replacing <C-h> with <bs> in my mappings did the trick for me (assuming you don't use the backspace key).

@geoffharcourt
Contributor

I think we have enough reports now no one else needs to confirm there's a problem, so no further need to add on to this thread.

@justinmk justinmk added the bug label Mar 3, 2015
@kopischke

@tarruda as everybody concerned seems to be using OS X, this (somewhat elderly) post might be relevant: it suggests that OS X terminals are defining a different erase character than Linux in the xterm terminfo, thus causing occasional issues with Backspace / Ctrl-h (which is the backspace equivalent when you use Emacs readline keybindings).

@ladislas
ladislas commented Mar 3, 2015

Another alternative is to use <C-w-h> which does the trick for me :)

@ZyX-I
Contributor
ZyX-I commented Mar 4, 2015

@ladislas What is w modifier? Win key?

@ladislas
ladislas commented Mar 4, 2015

@ZyX-I my bad, it's <C-w>h which means you have to presse the Ctrlkey + w letter key + h letter key.

It's just from the remap actually... nnoremap <C-h> <C-w>h

@LuRsT
LuRsT commented Mar 4, 2015

@kopischke, I wasn't going to chime in since there are already a lot of reports for this bug, but I just wanted to add that I'm experiencing the same on Arch linux (Using the AUR package which may be outdated)

Update: I don't have this problem in Ubuntu (using the package from apt-get)

@fishman
fishman commented Mar 4, 2015

i'm in archlinux too. this must be because of one the terminal libraries.

in nvim c-h produces <BS> whereas in vim in produces ^H

EDIT: and i've built it manually too, just in case the versions might cause a problem. i also tried it in xterm to see if the issue is rxvt specific

 if has('nvim')
     nmap <BS> <C-W>h
 endif

works for example. though that's a terrible workaround

@tarruda
Member
tarruda commented Mar 10, 2015

I'd like to dig the cause for this bug but its hard without reproducing locally. Can someone experiencing the problem paste a log of the keys being sent by the TUI? This will help:

diff --git a/src/nvim/os/input.c b/src/nvim/os/input.c
index 00efa28..5542218 100644
--- a/src/nvim/os/input.c
+++ b/src/nvim/os/input.c
@@ -142,6 +142,7 @@ bool os_isatty(int fd)

 size_t input_enqueue(String keys)
 {
+  fprintf(stderr, "pressed: %s", keys.data);
   char *ptr = keys.data, *end = ptr + keys.size;

   while (rbuffer_available(input_buffer) >= 6 && ptr < end) {

After applying the patch and rebuilding, run ./build/bin/nvim 2> keys.log , press ctrl+h and then paste keys.log here

@tarruda
Member
tarruda commented Mar 10, 2015

I've reproduced the problem in my OSX vm. As the link posted by @kopischke explains, OSX includes wrong terminfo information for xterm-256color(used by iterm), it sets the backspace key description to ctrl+h, which results in libvterm/nvim parsing it as backspace.

My guess is that most programs parse ctrl+h correctly because they ignore the kbs description. One way to work around the problem is to fix the terminfo entry for your terminal by replacing kbs=^H by kbs=\177(ascii del). These commands will create a fixed terminfo entry in your HOME directory:

infocmp $TERM | sed 's/kbs=^[hH]/kbs=\\177/' > $TERM.ti
tic $TERM.ti
@kopischke

@tarruda awesome!

OSX includes wrong terminfo information for xterm-256color(used by iterm), it sets the backspace key description to ctrl+h, which results in libvterm/nvim parsing it as backspace

Two notes:

  1. xterm-256-color is also used by recent versions of Terminal.app (Mavericks and above, IIRC)
  2. some Linux distros seem to suffer from the same issue, judging from the comments by @LuRsT and @fishman
@tarruda
Member
tarruda commented Mar 10, 2015

some Linux distros seem to suffer from the same issue, judging from the comments by @LuRsT and @fishman

I imagine thats a good reason to ignore the kbs description. While it may break a terminal that has a working terminfo file and uses a different representation for backspace, I doubt anyone will write such a terminal as it would be incompatible with most programs. cc @leonerd

@adambiggs

Thanks @tarruda! Your workaround fixed the issue for me.

Just wondering, is this something you plan on fixing in NeoVim? Or should I add your workaround as a permanent thing to my dotfiles? (or both?)

@khalidchawtany

Great, it works now.

@tarruda
Member
tarruda commented Mar 10, 2015

Just wondering, is this something you plan on fixing in NeoVim? Or should I add your workaround as a permanent thing to my dotfiles? (or both?)

I'm gonna wait for @leonerd's position on this. If he chooses to not ignore kbs I will modify the TUI module to parse ctrl+h before handling the data to libtermkey, which will fix the problem without requiring any changes to terminfo.

@jwhitley
Contributor

I've been experiencing this bug running nvim under tmux on OS X. I did some investigation, and both the screen-256color (under tmux) and xterm-256color (under iTerm2) terminfo entries reproduce this issue. At least it's consistent!?

@adambiggs

I forgot to test in tmux... @tarruda's workaround fixed it in iTerm, but it's still broken in tmux :(

I'm guessing there's a similar workaround for tmux?

@kopischke

@adambiggs your tmux config probably sets a different $TERM than your vanilla terminal. Try repeating the workaround steps while in tmux.

@fishman
fishman commented Mar 12, 2015

i will continue using the following for now until @leonerd chimes in. modifying my terminfo just for c-h everywhere i ssh into vim is kinda harsh.

 if has('nvim')
     nmap <BS> <C-W>h
 endif
@leonerd
leonerd commented Mar 12, 2015

I'm not entirely sure what people are waiting for from me.

Ctrl-H is "ASCII backspace" but terminals ought to be sending ASCII DEL for the Backspace key instead. This may or maynot agree with what their terminfo file says, however, so it's all a huge mess.

If you want it to work, ensure your terminal sends ASCII DEL on the Backspace key, and that this fact agrees with what your terminfo file says. In practical terms how you arrange for that to be the case, I really can't say.

@tarruda
Member
tarruda commented Mar 12, 2015

@leonerd The problem is that every terminal seems to send ASCII DEL regardless of what terminfo says, and every program(and even the OS line editor) seems ignores the kbs terminfo entry also using DEL as backspace.

I'm not entirely sure what people are waiting for from me.

We want to know if you will patch libtermkey to also follow this convention of treating DEL as backspace regardless of what is read from terminfo. If not, I will modify neovim TUI to preprocess DEL and ctrl+h before delivering these bytes to libtermkey.

@adambiggs adambiggs added a commit to adambiggs/dotfiles that referenced this issue Mar 20, 2015
@adambiggs adambiggs fix(vim): `<C-h>` key mapping no longer working due to weird terminal…
… behaviour

The fix involves importing a custom terminfo file to fix DEL/Backspace key behaviour.
See: neovim/neovim#2048 (comment)
2c1e935
@caifara
caifara commented Mar 27, 2015

@fishman Thanks for that solution, works as a charm (for now)!

@alxndr alxndr added a commit to alxndr/dotfiles that referenced this issue Apr 7, 2015
@alxndr alxndr nvim/terminal: fix control-h 7303a53
@tarruda tarruda added the TUI label Apr 8, 2015
@babygau
babygau commented Apr 14, 2015

@lambdahands, @adambiggs
Just in case you couldn't get it worked with vim-tmux-navigator, try this

if has('nvim')
  nmap <bs> :<c-u>TmuxNavigateLeft<cr>
endif

It works for me

@adambiggs

@babygau I found that vim mappings only fix vim-tmux-navigator in vim Tmux panes. As soon as you navigate to a pane that isn't running vim, you can no longer navigate left.

@tarruda's fix is the only complete solution I've found so far.

@badeip
badeip commented Apr 18, 2015

I am having similar issues with :tnoremap <c-h> on OSX.
This happens in iTerm, Terminal and (both with- and without) tmux, and regardless of what TERM is set to.
pressing <c-h> in one of the above mentioned terminal emulators, prints ^H
pressing <c-h> in a regular nvim buffer prints <BS>
pressing <c-h> in a :terminal buffer prints ^?

TERM is set to xterm-256color
stty erase is set to ^?
infocmp $TERM |grep kbs prints kbs=\177

version: NVIM 0.0.0-alpha+201504172305 (compiled Apr 18 2015 09:26:25)

None of the suggested workarounds in thread seems to have any effect.

@dragn
dragn commented May 1, 2015

There is a workaround: setting up terminals to send appropriate CSI codes for special combinations.

<C-H> : ^[[104;5u
<C-M> : ^[[109;5u
<C-I> : ^[[105;5u

For iTerm2 these settings work like charm: http://gyazo.com/132d1ce1fe0e14e62c1a263dde2d374e.
See also: http://www.leonerd.org.uk/hacks/fixterms/
Unfortunately, these settings also break mappings in Vim, as it does not use libtermkey :-D

@justinmk
Member
justinmk commented May 1, 2015

@dragn That is a good approach. Much of the benefit of libtermkey is in the CSI support, let's start using it and documenting the steps needed for users to take advantage of it.

@badeip
badeip commented May 2, 2015

@dagn Thanks, this fixes the problem for me.
For future reference, this is how to configure iTerm2 to send the correct CSI for ctrl+h

Edit -> Preferences -> Keys
Press +
Press Ctrl+h as Keyboard Shortcut
Choose Send Escape Sequence as Action
Type [104;5u for Esc+

@mudox
mudox commented May 2, 2015

👍 you all are life savers!

@atweiden
atweiden commented May 2, 2015

The Ctrl-h, Ctrl-j, Ctrl-k and Ctrl-l keys are only working in nvim outside of tmux. Inside of tmux, none of them work. I'm on Arch Linux with a fairly recent nvim build. I've tried the fix as per #2048 (comment), but it does not seem to have an effect inside tmux for the Ctrl-h key.

@ghost
ghost commented May 2, 2015

@atweiden besides ctrl-h, everything else works for me in tmux using Arch Linux, so this is presumably related to your terminal. Do you use a custom terminfo entry for your terminal, or perhaps some non-standard thing set via stty?

edit: I'm using st by the way.

@atweiden
atweiden commented May 2, 2015

I tried with screen-256color, screen-256color patched with instructions from #2048 (comment), with my custom screen-it-256color terminfo and with that custom terminfo patched.

@Pyrohh Are you using tmux-navigator by chance? I wonder if it has something to do with that plugin.

edit: I'm using urxvt.

@ghost
ghost commented May 2, 2015

@atweiden I am not. Have you tried just a raw terminal?

@atweiden
atweiden commented May 2, 2015

xterm and linux tty

@badeip
badeip commented May 2, 2015

@atweiden I am using tmux-navigator, and after modifying my terminal according to my previous comment, it works both in nvim and nvim within tmux.
IOW, your problem is most likely due to your terminal not sending the correct CSI.

@justinmk
Member
justinmk commented May 3, 2015

Speaking of tmux, it can be used to map CSI sequences too. This works:

bind-key -n C-h send-keys Escape "[104;5u"

I guess the reason this works is that tmux happens to not have the "bug" reported in this issue, so it is able to distinguish ctrl-h from backspace as Vim did.

Side note: The terminal-overrides feature of tmux looks useful (but it solves the inverse case, e.g., it maps input sequences to terminal capabilities)...

@dragn
dragn commented May 3, 2015

I've posted a request on iTerm2 bug tracker to add libtermkey codes to preset: https://gitlab.com/gnachman/iterm2/issues/3519.

@justinmk
Member
justinmk commented May 3, 2015

@dragn Cool. Note that to distinguish between ctrl-A (i.e., ctrl-shift-a) and ctrl-a, I believe more codes will be needed. Also curious why ctrl-tab and ctrl-shift-tab are missing in your list?

To "edit the plist", you should be able to set up the mappings in iTerm2, then export the plist to xml:

plutil -convert xml1 ~/Library/Preferences/???.plist -o PresetKeyMappings.plist
@dragn
dragn commented May 3, 2015

@justinmk Ctrl-Tab is mapped to switch tabs in iTerm by default (as a global shortcut). Overriding It will disable the global shortcut, which I believe is pretty common in use.
About ctrl-shift- combinations... I'm afraid it's counterproductive to add every possible combinations to Key mappings, the better approach is to add an option to produce correct codes for every possible value. And if I understand correctly, some work has already been done to parse CSI codes correctly in iTerm itself (see option "Use modern parser" here).
EDIT: On the other hand, it might not be any value in adding Ctrl-Shift-H mapping, because you can't use Ctrl-Shift- mappings with every other characters...

Thanks for the tip about plutil, I'll look into it.

@justinmk
Member
justinmk commented May 3, 2015

@dragn Is Neovim actually recognizing <c-i> for you, even after sending the correct CSI code? Neovim seems to be interpreting [105;5u and [73;5u as <tab>.

@dragn
dragn commented May 3, 2015

@justinmk It does interpret it as Tab for me also, but I think it's some default mapping of <C-i>, because mapping it to something else works.

@justinmk
Member
justinmk commented May 3, 2015

@dragn In nvim, if you go to insert-mode and type <c-v><c-i>, what does it insert? Even if I send the raw sequence via tmux, nvim still interprets it as a tab:

send-keys Escape "[105;5u"
send-keys Escape "[73;5u"
@dragn
dragn commented May 3, 2015

@justinmk Try using libtermkey sources to debug. Clone the repo, make it with DEBUG=1 and start demo program, It will output exactly what terminal is sending and how the library (and, hence, nvim itself) will interpret the sequence.

@dragn
dragn commented May 3, 2015

Here is the PR, for the reference (I'm not sure about the preset name, though...): gnachman/iTerm2#213

@justinmk
Member
justinmk commented May 3, 2015

@dragn Thanks for that quickstart. demo shows this:

Key <C-i>
getkey(force=0): buffer 
Driver terminfo yields TERMKEY_RES_NONE
Driver CSI yields TERMKEY_RES_NONE
getkey_simple(force=0) yields TERMKEY_RES_NONE
getkey(force=0): buffer 1b 5b 37 33 3b 35 75 
Driver terminfo yields TERMKEY_RES_NONE
Driver CSI yields TERMKEY_RES_KEY
Unicode codepoint=U+0049 utf8='I' mod=C+00
Key <C-I>
getkey(force=0): buffer 
Driver terminfo yields TERMKEY_RES_NONE
Driver CSI yields TERMKEY_RES_NONE
getkey_simple(force=0) yields TERMKEY_RES_NONE

Key <C-i> and Key <C-I> confirms that demo is able to distinguish the sequences (it cannot distinguish <C-b> and <C-B> unless I configure sequences for them).

Note that I'm using Terminal.app, not iTerm2. I figured out how to force sequences even though they are not available in the GUI preferences dialog (will share this later, it requires a script).

@atweiden
atweiden commented May 3, 2015

Using libtermkey's demo util has revealed that the Ctrl-hjkl key issue is particular to the system screen-256color* terminfo. Using the default screen-256color $TERM does, with @tarruda's fix, solve the Ctrl-hjkl issue inside tmux.

However, that fix comes with other issues for vim tmux users.

For instance, libtermkey doesn't detect Shift-F[9..12] using the screen-256color term, whereas with my terminfo screen-it-256color, libtermkey can detect those keys. Moreover, screen-it-256color is fixed to make Markdown italics render properly in vim on tmux. So for me at least, the Ctrl key bindings are more important, but I also bind Shift-F12 and don't mind italics rendering properly inside tmux.

Could anyone confirm by running libtermkey's demo util in tmux and pressing Shift-F9, Shift-F10, Shift-F11 or Shift-F12?

@dragn dragn referenced this issue in gnachman/iTerm2 May 6, 2015
Open

Add "libtermkey" key bindings preset #213

@gnachman
gnachman commented May 6, 2015

Do I understand correctly that in iTerm2 some people get 0x7f when pressing Control and H? That should only be possible if there's a key mapping overriding ^H. This is not to be confused with the Delete key, which will send either 0x7f or 0x08 depending on how it's configured in prefs>profiles>keys.

@geoffharcourt
Contributor

@gnachmanm, in iTerm2 Build 2.9.20150417-nightly, with no key mappings set in the Keys - Key Mappings section, ^H in insert mode appears to send a backspace. I checked this with no .vimrc loaded.

@gnachman
gnachman commented May 6, 2015

@geoffharcourt Would you please make a debug log of pressing Control-H? Make sure you use the nightly build for this, as it has good logging. Instructions here:
https://gitlab.com/gnachman/iterm2/wikis/DebugLogging
Send me a link to a gist or drop it as an attachment in this issue:
https://gitlab.com/gnachman/iterm2/issues/3519

@geoffharcourt
Contributor

Posted a gist there. Thanks.

@gnachman
gnachman commented May 6, 2015

iTerm2 is sending 0x08 for C-h. I guess the issue that the broken terminfo file interprets this as backspace when 0x7f should be backspace.

@agauniyal

I have same problem regarding backspace key. Also in gnome terminal , which I'm using , there is an option in compatibility which says Backspace key generates ( currently set as ASCII DEL) :

  1. Automatic
  2. Control - H
  3. ASCII DEL
  4. Escape Sequence
  5. TTY Erase

also below that , I have Delete key generates set as escape sequence. What should I change to not break my existing vim behavior and make nvim work properly with backspace key?

@justinmk
Member

@agauniyal Can you try all 5 gnome-terminal settings and let us know which (if any) fixes CTRL-H in nvim?

@agauniyal

@justinmk , this is weird , I tried out all options and none of them actually fixed backspace key , But whenever I pressed del key , the character that was deleted , could again be deleted by backspace key. I know that sounds confusing so here's a recording :

https://asciinema.org/a/19874

see from 1:20 to 1:24-5 I was constantly pressing backspace key but no character was being deleted. At 1:27 I pressed delete on 'e' and it was deleted , then I again entered 'e' and pressed backspace , so I could delete it. But if I had not deleted it with del key , backspace was completely ignoring it.

tldr; backspace key deletes characters which are previously deleted by del key , ignores other.

@justinmk
Member

@agauniyal for 4. Escape Sequence, the following should work:

^[[104;5u

^[ is the literal "escape". Make sure you use whatever gnome terminal wants there to represent "escape". However, it won't work in Vim.

@agauniyal

@justinmk I guess you're asking me to set 4. Escape sequence as ^[[104;5u , but gnome terminal dosen't provides a way to do that. It provides a dropdown :
2015-05-11-135840_1366x768_scrot

Also of I select escape sequence , then backspace key behaves like del key in vim as well as in terminal. But nvim dosent responds to it , completely ignores backspace key till I del a character and press backspace key on it as I have shown above.

@chevex
chevex commented May 15, 2015

Why does this just work in regular vim but not in neovim if the issue is with OS X, iTerm, or tmux?

@agauniyal

@chevex I'm nowhere near OS X , having arch linux with gnome terminal and this dosen't works on my system too.

@davidsteinberger

I know that this is odd. Did u try this in your vimrc?

if has('nvim')
  let $NVIM_TUI_ENABLE_CURSOR_SHAPE=1
  " Hack to get C-h working in neovim
  nmap <BS> <C-W>h
  tnoremap <Esc> <C-\><C-n>
endif
@chevex
chevex commented May 15, 2015

@tarruda's fix worked for me great. I'm just curious why vim works and neovim doesn't. That alone seems to say that neovim is what needs to change. Maybe I'm not fully understanding. I'm new to neovim.

@justinnhli

@chevex I believe the issue is that vim and other programs actually ignore what is specified in terminfo, which many have set incorrectly. Neovim abides by it, and the debate is whether neovim should also ignore it like everyone else. See @tarruda 's longer reply: #2048 (comment)

@chevex
chevex commented May 15, 2015

Ok that makes more sense. As much as I think it sucks that terminfo is set incorrectly, I guess count my vote for doing what everyone else is doing so users don't have to do this workaround of manually fixing terminfo.

@agauniyal

@davidsteinberger yes and it dosen't works. This just changes my cursor from fat guy to slim guy but fails to delete any character. Do you think I should change my terminal?

Edit : Call me mad , but set backspace=2 works 😌 and solves my problem.

Edit 2: set backspace=2 doesn't completely solve the problem. Jumping out and in into insert mode brings back that non-deleting behaviour of backspace key. However I had problems to reproduce this.

I'm really interested in this project and looking forward to use neovim as soon as these bugs are fixed.

@thomasboyt

@badeip Following your advice for iTerm 2's hotkeys, I'm now able to use C-h in Neovim inside or outside of tmux. However, sending C-h to a terminal window in or outside of tmux just outputs 4;5u, preventing me from navigating between tmux panes with C-h. Is there a terminal setting I'm missing that would fix this?

It does seem like the custom terminfo fix works, though, following the lead of alxndr/dotfiles@7303a53

@thomasboyt thomasboyt added a commit to thomasboyt/neodotfiles that referenced this issue May 24, 2015
@thomasboyt thomasboyt Add custom terminfo to workaround neovim/neovim#2048 7f4789b
@badeip
badeip commented May 24, 2015

@thomasboyt it's not really my advice, I just described how to adapt @dragn suggestion to iTerm 2.
That said, it seems libtermkey has taken the pedantic approach to c-h et al.
That is probably "correct", but incompatible with several other programs such as tmux and vim.

IMO having to change terminal settings is not the right solution, as nvim should "just work".

A possible solution is to add a libtermkey run time setting with a "legacy mode" that can be switched off, and exposing this setting in nvim with e.g :set pedanticterm
I have not looked at the code, so I do not know how feasible that is.

@justinmk
Member

Last several comments are incorrect. This is not a matter of libtermkey or neovim being pedantic. In fact, libtermkey will ignore terminfo if a terminal setting is detected, even if terminfo does not specify it.

In the case of ctrl-h specifically, there is a well-known quirk that neovim can possibly assume, to avoid this problem.

I would request that further comments in this thread avoid speculation. This thread is long enough.

@chevex
chevex commented May 24, 2015

Agreed ^

For those coming in, @tarruda's fix way above is the only "complete" workaround as it directly fixes the kbs quirk in terminfo. It's that quirk that most other programs referenced (including classic vim) are choosing to ignore, which is what neovim may ultimately end up doing.

@badeip
badeip commented May 25, 2015

@justinmk thanks for clearing that up, the issue is not very comprehensible for the uninitiated.
This thread contains several suggestions of how to work around this issue, but AFAIK no solution (including @tarruda's fix) that works for all and doesn't break e.g compatibility with vim

If you do not want more comments in this thread, I suggest either documenting the issue and workaround on the wiki and/or :help c-h

@originalsouth

@justinmk now I'm really curious what @tarruda's ambitious project is :)

@leonerd
leonerd commented Nov 6, 2015

@sondr3 - if you're using latest neovim and your terminal is correct and your terminfo file correctly describes its behaviour, then it should work.

If it still does not, then at least one of these three facts must be false. So go fix those.

@leonerd
leonerd commented Nov 6, 2015

@justinmk I do hope @tarruda's idea isn't just a reinvention of my fix-my-terminfo script. That already works to solve all this for all programs ever.

@justinmk
Member
justinmk commented Nov 6, 2015

@leonerd we need a way to override terminfo codes. Even if distros fix their terminfo, this doesn't help users of older distros.

@leonerd
leonerd commented Nov 6, 2015

@justinmk Exactly. A USER runs my program, presses the backspace key when the program asks them to, and then that program writes a customised terminfo file in the user's $HOME directory. That's it. That's all they need to do and now it's fixed for every program they'll ever run.

They run fix-my-terminfo, and they press backspace when asked to.

$ ./fix-my-terminfo 
Running with /home/leo/.terminfo/x/xterm in place
Press <Backspace>: 7F
Terminfo says: OK

TI has erase_chars

TI has parm_dch

No TI fixes required

$ 

What more could be simpler?

@tarruda
Member
tarruda commented Nov 6, 2015

@justinmk I do hope @tarruda's idea isn't just a reinvention of my fix-my-terminfo script. That already works to solve all this for all programs ever.

@leonerd I have great respect for your work. As I said before, I think libtickit and libtermkey are amazing projects with great code quality, but this "ambitious project" they are talking about is basically a rework of the TUI that parses input without libtermkey, using unibilium for obtaining initial terminfo data but allowing users have full control over the strings.

I wanted to avoid implementing this, especially since libtermkey already does the hard work, but decided to do it anyway for the following reasons:

  • As stated above, we want to let users override terminfo information about keys. As we all know, terminfo is broken on some distros, and requiring users to run an interactive script on every machine they log into is cumbersome compared to setting some options in the vimrc(which are more easily propagated when kept in a dot files repo).
  • You already stated on #tickit that you have no plans add override mechanisms to libtermkey
  • libtermkey will be merged into libtickit, and ATM we don't need any libtickit widget functionality(Neovim already contains logic to draw on each cell)
  • The new TUI version will be mostly written in lua(some parts will still be C, especially the screen state manipulations and unibilium bindings). Lua is very high level, and with its builtin pattern matching library, parsing terminal codes will be trivial.
@rdlugosz
rdlugosz commented Nov 6, 2015

What more could be simpler?

While I agree that the correct thing to do is to have users fix their terminfo files, the simpler thing is to have neovim do what vim and other programs do & fix this internally. There may be a technical reason why neovim cannot do this, but if not I think following the lead of other applications is completely reasonable.

Is there a reason why doing what classic vim does is not an option? I re-read the thread before typing this question, but please excuse me if I missed it.

@bgourlie
bgourlie commented Nov 6, 2015

What more could be simpler?

I also want to point out this is only simple once the user:

  • Realizes something isn't behaving as expected
  • Googles for a solution to the problem
  • Happens to discover this script and presumably determines it's the best solution to fixing the problem, among the various other suggested fixes
@tarruda
Member
tarruda commented Nov 6, 2015

Is there a reason why doing what classic vim does is not an option? I re-read the thread before typing this question, but please excuse me if I missed it.

The reason those options were dropped in the first TUI refactor is because a major goal of Neovim is to decouple the UI from the core, which had those options tightly coupled.

My next PR will give back the user full control over how nvim interacts with the terminal, but it will be done with plain g: variables, which after #3603 will have the same power as the builtin options(plugins will be able to attach logic to change events). This will make even more sense because the TUI will be just another plugin from Neovim POV.

@tarruda
Member
tarruda commented Nov 6, 2015

BTW, even though libtermkey will no longer be used, Neovim will still support its key encoding scheme.

@rdlugosz
rdlugosz commented Nov 6, 2015

Thx. I figured there was a reason for the change. So once libtermkey is no longer being used will this issue simply go away? If so, great! If not, I'd suggest that it's reasonable—desirable, even—to have internal handling of this issue at a layer that federates between the UI, the core & the terminal. (excuse my lack of knowledge of the Neovim architecture... speaking generally here & assuming you'll understand what I mean.)

@leonerd
leonerd commented Nov 6, 2015

@rdlugosz (neo)vim can't really do what "most other programs do", because most other programs don't care to distinguish Backspace from Ctrl-H. I went off and researched a great many of them and all of the likely candidates (mutt, irssi, screen, tmux,...) conflate the two. vim is almost unique in all the world in offering any consideration of the fact that Backspace and Ctrl-H might actually be different.

What legacy vim does is to ask termios what its opinion is of the Backspace key. In my opinion that's only trading one possibly-wrong database (terminfo) for another (termios). I took the view that the only 100% correct foolproof way to know what byte the Backspace key sends is to ask the user to actually press the Backspace key and record what byte it actually sent. I then record the actual answer in the per-user terminfo override, so that every application that queries it from terminfo can rely on it being correct.

Ultimately - do we want to trust terminfo or not? If not, then what's the point of using it at all? Why don't we just hardcode ECMA-48 terminal control sequences everywhere, and abandon all hope of terminfo being correct? Let it die the death it should have had in the 1980s.

@leonerd
leonerd commented Nov 6, 2015

@bgourlie Do you have a different suggestion then? I'm very keen to hear it - I only came up with the current terminfo-fixing script because of a total lack of any better ideas after months of milling it around here. It's possible I haven't heard your suggestion though.

@rdlugosz
rdlugosz commented Nov 6, 2015

Makes sense. Perhaps this is something neovim can do on startup and tag in viminfo?

Want to be clear that I appreciate that you've done a lot of research & work on this! My $0.02 is being kicked in to make sure we're keeping things as simple as possible for the user. I & others have found this thread went through the process described above, which isn't a great user experience.

Totally understand that the idea of Neovim is to shed much of the old baggage & improve the architecture, but I think for the foreseeable future people will be looking for things that don't quite work right. When they stumble across something like their C-h mapping not working they're either going to research & find this solution or (most likely) they'll decide "meh, neovim is still a little buggy; needs more time" and go back to vim. Best to minimize the chances of that sort of thing happening.

@leonerd
leonerd commented Nov 6, 2015

@rdlugosz How about a "first run" setup wizard? The first time a user runs neovim on a new $TERM value, it says:

Hey, so this is the first time you've run neovim on this kind of terminal.
Before we start, lets just check everything is working.
Please press the <Backspace> key now, so I can check it's all fine
@badeip
badeip commented Nov 6, 2015

What about adding a new argument to nvim, such as nvim --configure?
It's not very vim-ish, but at least we don't have to bother all new users with a setting they might not care about.

@bgourlie
bgourlie commented Nov 6, 2015

@leonerd I'm not saying there's a better solution, I'm just pointing out it's only simple once the user realizes it's the proper solution. I do like the idea of a first-run wizard.

@leonerd
leonerd commented Nov 6, 2015

@bgourlie But that's how I phrased my question. ;) I know it's not absolutely simple - but it's the simplest thing I could practically create that actually works. I'm not aware of a simpler solution.

@bgourlie
bgourlie commented Nov 6, 2015

@leonerd There are really two issues -- The technical solution, which you've solved. The other issue is the usability issue, and I think that's what most of this discussion revolves around. What is best for the users? Should we expect them to run a script so that they have the ideal technical solution, or a more pragmatic solution that will "just work" for most people but may not be technically ideal.

@rdlugosz
rdlugosz commented Nov 6, 2015

I think a first run (or new terminal) wizard is a very reasonable idea.

@SchDen SchDen added a commit to SchDen/nvim-config that referenced this issue Nov 6, 2015
@SchDen SchDen Fix bug neovim/neovim#2048 (comment) a13dbd6
@leonerd
leonerd commented Nov 16, 2015

@tarruda:

As stated above, we want to let users override terminfo information about keys. As we all know, terminfo is broken on some distros, and requiring users to run an interactive script on every machine they log into is cumbersome compared to setting some options in the vimrc(which are more easily propagated when kept in a dot files repo).
You already stated on #tickit that you have no plans add override mechanisms to libtermkey
libtermkey will be merged into libtickit, and ATM we don't need any libtickit widget functionality(Neovim already contains logic to draw on each cell)

I said I have no immediate plans to do that right now because I am busy doing other things and I don't personally need it. However, there's already an LP blueprint for considering this:

https://blueprints.launchpad.net/libtickit/+spec/override-terminfo

You're welcome to comment on that, or take it and implement it yourself, or whatever. I said this isn't a priority for me, not that I'll block anyone else doing it.

I would hate to see neovim get annoyed and drop using this simply because of some small upset about Ctrl-H or whatever related reason it was.

The new TUI version will be mostly written in lua(some parts will still be C, especially the screen state manipulations and unibilium bindings). Lua is very high level, and with its builtin pattern matching library, parsing terminal codes will be trivial.

Well, of course my reply to that would be that it is (surely) fairly easy to call into a C library from Lua.

Having implemented all of this once, I'm aware how nontrivial parts of it can be. I really would like us to end up in a situation where neovim was using libtickit - not least because that reduces the total amount of work. But moreover, that leaves neovim able to much easier make use of more things that get added into libtickit as time goes on.

It's no great secret that I would like more terminals using libvterm and more application using libtickit. The more that do, the more will interoperate nicely and make use of yet newer abilities I start adding in.

@tarruda
Member
tarruda commented Nov 17, 2015

I would hate to see neovim get annoyed and drop using this simply because of some small upset about Ctrl-H or whatever related reason it was.

@leonerd I did not mean to put any pressure for you to implement these features just for the sake of neovim. In the future libtickit widgets may be useful, but ATM the terminal UI does not know anything about widgets, it simply receives direct cell by cell drawing instructions. This means there's basically no difference from using libtickit to using unibilium directly, we would just be adding a unnecessary layer.

The only part of libtickit that is currently useful for neovim is the input layer which used to be implemented in libtermkey(and now you moved or will move into libtickit), but even so I'm forced to add hacks in order to work around some of its limitations.

One example of this(beyond not allowing terminfo override) is the fact that the only way it will stop trying to recognize \x1b as the alt modifier is to enable 8-bit mode(which is not an option for many terminal emulators). This has caused some users trouble with tmux mappings that send \x1b expecting to leave insert mode(they began seeings strange characters printed to the screen since tmux sends keys with almost no delay). So I added workaround code that handles \x1b specially before calling libtermkey for:

  • Allowing \x1b followed by \x00 to be interpreted as the esc key(this allowed tmux users to adapt their mappings for neovim)
  • Parsing bracketed paste sequences which AFAIK is also not supported by libtermkey.

Implementing key parsing in lua will greatly clean up the current code.

You're welcome to comment on that, or take it and implement it yourself, or whatever. I said this isn't a priority for me, not that I'll block anyone else doing it.

I also prefer to call C code from lua, but implementing the changes I require into libtickit would require a lot more than what I have planned. Here's what comes to mind(besides adding/debugging new C code, which is slower than doing in lua):

  • Get familiar with libtickit architecture and code patterns. I doubt you will want quick and dirty patches that simply implement the feature, it needs to follow your standards(BTW this is not a criticism)
  • Maintain a fork of libtickit until the changes are reviewed and merged upstream. This will require package maintainers to target the fork.
  • Once it is merged, switch back to using upstream, which is also more work for package maintainers.

As I said before, this doesn't mean we won't ever use libtickit again, it just means ATM it is not the best choice. If eventually it ends up meeting our requirements while providing a maintenance improvement, I don't see why we couldn't switch to using it.

@mcmire
mcmire commented Nov 19, 2015

+1 for this comment as a workaround for this issue.

@lpil lpil added a commit to lpil/dotfiles that referenced this issue Nov 21, 2015
@lpil lpil Enable <C-h> for neovim on OSX d070101
@selurvedu

I confirm the following workaround:

  1. libtermkey 0.18 (doesn't work with 0.17).
  2. Patched ~/.terminfo/ entry.

@tarruda, @leonerd – thank you, guys!

@sublimecoder

The issue still exists for me, currently using iterm2 escape sequence key mapping as a workaround.

Build information
NVIM v0.1.0-157-g0ee3398 (compiled Dec 3 2015 16:14:20)
Commit: 0ee3398

@leonerd
leonerd commented Dec 4, 2015

@sublimecoder can you explain "iterm2 escape sequence key mapping"?

@sublimecoder

@leonerd Here are the steps to add the key mapping.

Edit -> Preferences -> Keys
Press +
Press Ctrl+h as Keyboard Shortcut
Choose Send Escape Sequence as Action
Type [104;5u for Esc+

referenced from @badeip's comment

@nabn nabn added a commit to nabn/nvim-config that referenced this issue Jan 22, 2016
@nabn nabn remove <BS> mapping
set up a workaround in iterm:
  send [104;5u for ^h in iterm config
  as described in this issue: neovim/neovim#2048 (comment)
  so that we don't have to map <BS> to :TmuxNavigateLeft anymore
5542447
@vort3x
vort3x commented Jan 22, 2016

@sublimecoder thanks a lot! Fixed my problem

@nabn
nabn commented Jan 26, 2016

When I follow the steps mentioned by @sublimecoder, the mapping works fine for most cases. But if I have a server running (webpack-dev-server, in this case), when I hit C-h, it prints out the mapped characters to the console, instead of navigating to another split in tmux.

@mhinz mhinz referenced this issue Jan 28, 2016
Closed

Cannot bind C-h #4123

@roychoo
roychoo commented Feb 5, 2016

yeah i have the problem as @nabn , anyone found any workaround on this?

@vilhalmer vilhalmer added a commit to vilhalmer/System that referenced this issue Feb 8, 2016
@vilhalmer vilhalmer [nvim] Work around neovim/neovim#2048. a40ff26
@acgtyrant acgtyrant added a commit to acgtyrant/dotfiles that referenced this issue Feb 19, 2016
@acgtyrant acgtyrant fix wrong terminfo 2e187b2
@claytron claytron added a commit to claytron/dotfiles that referenced this issue Feb 19, 2016
@claytron claytron temporary workaround for nvim and <C-h>
The long sordid details of the issue here: neovim/neovim#2048

Thanks to @vilhalmer for the idea!
49d1cc2
@jedahan
jedahan commented Feb 22, 2016

export TERMINFO="$HOME/.terminfo" fixed it for me

@ahan
ahan commented Feb 27, 2016

@badeip thanks, fixed my problem at iTerm2 for ctrl+h, and need to mention that to reboot the iTerm2 to make it work.

@meribold meribold added a commit to meribold/dotfiles that referenced this issue Mar 2, 2016
@meribold meribold xterm: send ^? for backspace and adjust terminfo
Transmit ASCII DEL for the backspace key and add accordingly modified
terminfo files.  Those were created with

    infocmp | sed 's/kbs=^[hH]/kbs=^?/' | tic -o ~/dotfiles/terminfo/ -

from a normal xterm and while attached to a screen session (I'm linking
~/.terminfo to ~/dotfiles/terminfo).

This fixes neovim/neovim#2048; i.e., the <C-H>
mapping added by 9dec268 (just the
terminfo files actually fix that issue already).

It also fixes the backspace key erasing all characters before the cursor
in some xterms attached to a screen session that was created in detached
mode (with `screen -d -m`).  This fix works without the terminfo files
and only the change to Xresources.  ^H still does the same, though.  See
03a7049.
62324d2
@zhimsel zhimsel added a commit to zhimsel/dotfiles that referenced this issue Mar 21, 2016
@zhimsel zhimsel switch back to neovim with ^h workaround a01a68e
@0x434d53 0x434d53 added a commit to 0x434d53/dotfiles that referenced this issue Mar 23, 2016
@0x434d53 0x434d53 fix workaroung for neovim/neovim#2048 9253b4f
@nathanaelkane nathanaelkane added a commit to nathanaelkane/dotfiles that referenced this issue Mar 24, 2016
@nathanaelkane nathanaelkane Add hack to get C-h working in NeoVim
Related to neovim/neovim#2048.
691fae3
@alesandar

For anyone who uses st (by suckless), it seems like it has the proper terminfo already.
Appending set -g default-terminal "st-256color" to my configuration fixed everything.

@wsdjeg
wsdjeg commented Mar 24, 2016

@alesandar I use st last week,but many hot key not works as expected.ctrl + home or ctrl + end do not works .so I have change to termite.everything works well

@aemb
aemb commented Mar 28, 2016

This is what I added to my .vimrc and it still doesn't work:

if has('nvim')
  " Hack to get C-h working in NeoVim
  nmap <BS> <C-W>h
endif

and verbose imap <BS> gives me this result

i  <BS>        * lexima#expand('<BS>', 'i')
        Last set from ~/.vim/plugged/lexima.vim/autoload/lexima/insmode.vim

Any idea on how to get around this ? I'm not sure of what's happening there.

@fmoralesc
Contributor

@aemb You are mapping <BS> in normal mode, not insert mode, so the plugin takes over. It might override it even if you do map it in insert mode, but that will depend on how well behaved it is.

@aemb aemb referenced this issue in cohama/lexima.vim Mar 28, 2016
Closed

Neovim : <C-h> needs to be overridden #55

@delianides delianides added a commit to delianides/dotfiles that referenced this issue Mar 28, 2016
@delianides delianides workaround per neovim/neovim#2048 734ab3b
@zackhsi zackhsi added a commit to zackhsi/dotfiles that referenced this issue Apr 4, 2016
@zackhsi zackhsi Fix neovim ctrl-h 5682525
@zackhsi zackhsi added a commit to zackhsi/dotfiles that referenced this issue Apr 4, 2016
@zackhsi zackhsi Fix ctrl-h 8d13213
@zackhsi zackhsi added a commit to zackhsi/dotfiles that referenced this issue Apr 6, 2016
@zackhsi zackhsi Fix tmux navigator 6893501
@blueyed
Contributor
blueyed commented Apr 19, 2016 edited

For me this is only a problem with sudo nvim?!
With Neovim in tmux :send-keys c-h works as expected, but with sudo nvim the :send-keys c-h from tmux will become <BS> in Neovim.

sudo env TERMINFO="$HOME/.terminfo" nvim works though.
~/.terminfo/t/tmux-256color differs from /usr/share/terminfo/t/tmux-256color.
The former is based on Add terminfo files for tmux as per FAQ for italics with 2.1: https://github.com/ThomasAdam/tmux/blob/master/FAQ#L363.

% infocmp -d -A ~/.terminfo -B /usr/share/terminfo tmux-256color
comparing tmux-256color to tmux-256color.
    comparing booleans.
        hs: F:T.
    comparing numbers.
    comparing strings.
        dsl: NULL, '\E]0;\007'.
        fsl: NULL, '^G'.
        kbs: '\177', '^H'.
        tsl: NULL, '\E]0;'.

The kbs for /usr/share/terminfo/t/tmux-256-color probably causes the C-h to be mapped to <BS>?!

Note that Vim (7.4.1689) behaves differently: the mapping is not a problem, but <c-v><bs> will result in ^? (and not <bs> as with Neovim).

I am on Arch Linux, and it appears to use the upstream ncurses 6.0 package verbatim for this.
So every distribution, which does not patch ncurses / the terminfo files seems to be affected?!

@aemb
aemb commented Apr 20, 2016 edited

@fmoralesc I used imap and it doesn't work.

if has('nvim')
  " Hack to get C-h working in NeoVim
  imap <BS> <C-W>h
endif

The result of verbose imap <BS> is the one expected this time but it still behaves bad.
<C-h> still does <BS>.

i  <BS>          <C-W>h
        Last set from ~/.vim/init.vim

I am also on Arch Linux like @blueyed and I don't use tmux.

@justinmk
Member

@aemb You must also inoremap <C-W>h <something>.

Please open troubleshooting questions in new issues or in other forums. This issue does not need more discussion about individual configs.

@trusktr
trusktr commented Apr 21, 2016

@aemb See :help map, then learn which mode you want to map for (n = normal, i = insert, etc) and what command you want to map <bs> to in that mode.

@siphiuel
siphiuel commented Apr 25, 2016 edited

I've started having this issue in Tmux+Neovim after i've modified

set -g default-terminal "xterm-256color"

to

set -g default-terminal "screen-256color"

in .tmux.conf. I am using OS X Terminal.app.

Kudos to @jedahan - export TERMINFO="$HOME/.terminfo" fixed it for me as well.

@jcmorrow jcmorrow added a commit to jcmorrow/dotfiles that referenced this issue May 3, 2016
@jcmorrow jcmorrow Make neovim default editor
Because now <c-h> works again thanks to
neovim/neovim#2048 (comment)
cd1b9c9
@expipiplus1 expipiplus1 added a commit to expipiplus1/dotfiles that referenced this issue May 6, 2016
@expipiplus1 expipiplus1 Remove neovim/neovim#2048 workaround 64fcdfb
@bibek22 bibek22 referenced this issue in christoomey/vim-tmux-navigator May 8, 2016
Closed

<C-h> doesn't work in neovim #125

@blueyed
Contributor
blueyed commented May 9, 2016

FWIW, I've found this in tmux source:

/*
 * Check for backspace key using termios VERASE - the terminfo
 * kbs entry is extremely unreliable, so cannot be safely
 * used. termios should have a better idea.
 */
bspace = tty->tio.c_cc[VERASE];
if (bspace != _POSIX_VDISABLE && (key & KEYC_MASK_KEY) == bspace)
    key = (key & KEYC_MASK_MOD) | KEYC_BSPACE;

https://github.com/tmux/tmux/blob/fe4e9470bb504357d073320f5d305b22663ee3fd/tty-keys.c#L625-L632

And it gets set for panes initially: tio2.c_cc[VERASE] = '\177'; (https://github.com/tmux/tmux/blob/fe4e9470bb504357d073320f5d305b22663ee3fd/window.c#L866).

Not sure if it's really helpful, but might give some idea to fix this.

@justinmk
Member
justinmk commented May 9, 2016

@blueyed Yes, that's the traditional way to avoid this issue (Vim uses the same approach): fall back to termios. We would like to do that, but it requires forking libtermkey (or more ideally, getting a hook in libtickit when libtermkey is merged into libtickit).

@kthibodeaux kthibodeaux added a commit to kthibodeaux/.dotfiles that referenced this issue Jun 3, 2016
@kthibodeaux kthibodeaux Make C-H work in Neovim 14a9108
@kthibodeaux kthibodeaux pushed a commit to kthibodeaux/.dotfiles that referenced this issue Jun 3, 2016
Keith Thibodeaux Fix C-H again cdd1b43
@kthibodeaux kthibodeaux added a commit to kthibodeaux/.dotfiles that referenced this issue Jun 4, 2016
@kthibodeaux kthibodeaux Live in tmux
When opening a new shell when tmux is not running then run tmux new

If tmux is already running, give a choice to connect to an existing
session or create a new one (or qQ to not).

With these dotfiles it is not recommended to work outside of tmux due to
neovim/neovim#2048.  While there are many
solutions in the issue thread the one that works best for me is to
rebind c-h in tmux to send the proper command to neovim.  YMMV.
184eea7
@kthibodeaux kthibodeaux added a commit to kthibodeaux/.dotfiles that referenced this issue Jun 5, 2016
@kthibodeaux kthibodeaux Fix C-H again
Previous fix for C-H did not allow for navigating left to a different
tmux pane.

By putting the fix here we can be sure that the C-H binding is only
changed when inside of n/vim.

As always, see here for more information:
neovim/neovim#2048 (comment)
e03c408
@razor-x razor-x added a commit to rxrc/nvimrc that referenced this issue Jun 16, 2016
@razor-x razor-x Map backspace to ctrl-h
Workaround for neovim/neovim#2048.
88c6bb8
@miniukof miniukof added a commit to miniukof/configfiles that referenced this issue Jun 16, 2016
@miniukof miniukof Magic command for fixing ctrl+h in terminals d89e173
@ifyouseewendy ifyouseewendy added a commit to ifyouseewendy/dotfiles that referenced this issue Jun 21, 2016
@ifyouseewendy ifyouseewendy vimrc: Fix c-h issue* e805ce8
@larrylv larrylv added a commit to larrylv/dotfiles that referenced this issue Jun 23, 2016
@larrylv larrylv No more C-w C-h 139e38b
@jackfranklin jackfranklin added a commit to jackfranklin/dotfiles that referenced this issue Jun 24, 2016
@jackfranklin jackfranklin Fix problem with Ctrl-H and Mac and Neovim 984fbda
@vilhalmer vilhalmer added a commit to vilhalmer/System that referenced this issue Jul 1, 2016
@vilhalmer vilhalmer [profile] Set TERMINFO if appropriate file exists
This adds the ability to include custom terminfo files in this repo,
which will be used when available. I've used it to fix the bug in OS X's
default terminfos which prevents C-h from working correctly in neovim.
As a result, this commit also removes that workaround from init.vim.

The included ti files were generated using the technique in
neovim/neovim#2048 (comment):

infocmp $TERM | sed 's/kbs=^[hH]/kbs=\\177/' > $TERM.ti && tic $TERM.ti
85bce8a
@salcode salcode referenced this issue in salcode/ironcode-vim Jul 5, 2016
Open

Notes on neovim #42

@justjake justjake added a commit to justjake/Dotfiles that referenced this issue Jul 22, 2016
@justjake justjake Script to fix nvim Ctrl-H bindings on some systems
This issue crops up because almost all programs special-case backspace
to be ctrl-h.
See neovim/neovim#2048 (comment)
bf38d60
@smcabrera smcabrera added a commit to smcabrera/castillo-cabrera that referenced this issue Jul 30, 2016
@smcabrera smcabrera Fix the Ctrl-H issue in neovim: neovim/neovim#2048 (comment) f42f37f
@akshayjshah akshayjshah added a commit to akshayjshah/dotfiles that referenced this issue Aug 4, 2016
@akshayjshah akshayjshah Add a terminfo file to fix C-h in nvim e47a94c
@dojoteef
dojoteef commented Aug 9, 2016

I know I'm late to the party, but if anyone is looking for a solution with a more limited scope the approach I used will gracefully fallback to termios settings if needed for your terminal without requiring a global setting.

https://github.com/dojoteef/dotfiles/blob/master/init/50_nvim.sh#L39
https://github.com/dojoteef/dotfiles/blob/master/source/50_editor.sh#L4

@tdy tdy added a commit to tdy/dots that referenced this issue Aug 11, 2016
@tdy tdy replace `kbs=^h` in terminfo neovim/neovim#2048 (comment) fa26dbe
@tdy tdy added a commit to tdy/dots that referenced this issue Aug 11, 2016
@tdy tdy replace `kbs=^h` in terminfo neovim/neovim#2048 (comment)
Former-commit-id: fa26dbe
cc05978
@justinmk
Member
justinmk commented Aug 22, 2016 edited

For those finding this issue, :CheckHealth now detects this problem and suggests a workaround. The same workaround is mentioned in the FAQ.


Update: @blueyed post to ncurses mailing list: https://lists.gnu.org/archive/html/bug-ncurses/2016-11/msg00022.html


Update: #5758 is an attempt to fix this issue.

@justinmk justinmk locked and limited conversation to collaborators Aug 22, 2016
@justinmk justinmk modified the milestone: 0.2, 0.3 Dec 12, 2016
@justinmk justinmk closed this in #5758 Dec 23, 2016
@justinmk
Member

This is fixed on master (not released yet). To build from source, you probably need to:

rm -rf .deps build

However master is unstable currently, so most users should wait until the next release.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.