<C-h> (CTRL-H) does not work in the new TUI
rainerborene opened this issue · comments
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>lenv 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=
I experience the same on OSX with iterm2.
what is displayed if you type <c-v><c-h> in insert mode?
With nvim, Commit: 0df6b91
<BS>
With vim 7.4.488
^H
I'm using the same config for both vim and neovim.
Same here. <BS>
any chance you compiled against the wrong libtermkey version? Does rm -rf .deps build && make && build/bin/nvim change anything?
Same behavior for me.
- downloading... src='https://github.com/neovim/libtermkey/archive/8c0cb7108cc63218ea19aa898968eede19e19603.tar.gz'
what is displayed when you press ctrl+h in the cat program?
^H, the same happens with xxd.
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.
FWIW, I bisected the merges and it broke at merge #2039
@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
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>.
One further detail: this problem happens in nvim with a blank .vimrc.
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.
Oh, and <c-v><c-h> in insert mode prints <BS> in the current buffer.
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.
Experiencing this as well.
iTerm on OSX 10.10.2
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).
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.
@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).
Another alternative is to use <C-w-h> which does the trick for me :)
@ladislas What is w modifier? Win key?
@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
@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)
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
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
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@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:
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
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?)
Great, it works now.
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.
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!?
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?
@adambiggs your tmux config probably sets a different $TERM than your vanilla terminal. Try repeating the workaround steps while in tmux.
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
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.
@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.
@fishman Thanks for that solution, works as a charm (for now)!
@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>
endifIt works for me
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.
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
@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.
@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+
👍 you all are life savers!
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.
@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.
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.
@atweiden I am not. Have you tried just a raw terminal?
xterm and linux tty
@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.
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)...
I've posted a request on iTerm2 bug tracker to add libtermkey codes to preset: https://gitlab.com/gnachman/iterm2/issues/3519.
@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
@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.
@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>.
@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.
@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"
@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.
Here is the PR, for the reference (I'm not sure about the preset name, though...): gnachman/iTerm2#213
@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).
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?
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.
@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.
@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
Posted a gist there. Thanks.
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.
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) :
- Automatic
- Control - H
- ASCII DEL
- Escape Sequence
- 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?
@agauniyal Can you try all 5 gnome-terminal settings and let us know which (if any) fixes CTRL-H in nvim?
@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 :
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.
@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.
@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 :
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.
Why does this just work in regular vim but not in neovim if the issue is with OS X, iTerm, or tmux?
@chevex I'm nowhere near OS X , having arch linux with gnome terminal and this dosen't works on my system too.
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
@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.
@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)
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.
@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.
@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 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.
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.
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.
@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
I will modify neovim TUI to preprocess DEL and ctrl+h before delivering these bytes to libtermkey.
@tarruda Can you do this for 0.1? I don't think libtermkey/libtickit is going to get the hooks we need any time soon.
libtermkey isn't going to fix this one, as it's dead, EOL.
Some initial thoughts on a blueprint for what tickit might do in that direction can be found
https://blueprints.launchpad.net/libtickit/+spec/ctrl-h-as-backspace
Comments welcome.
@leonerd libtickit looks interesting. But it says it'll use libtermkey, so I'm confused about how dead libtermkey really is?
@gnachman libtermkey can't continue being a standalone library. My plan is to copypaste the code across into tickit, so it can be expanded and given new abilities it currently can't have.
I remember seeing something very similar when I was reading about suckless.org's st program. If anyone is interested in some of the backstory for why backspace sends ^H in terminfo I would encourage you to read this:
@smasher816 interesting read, thanks for the link
For reference, stty doesn't work because we removed this logic:
https://github.com/vim/vim/blob/master/src/os_unix.c#L3493-L3504
Pushed back to 0.3, blocked by libtermkey/libtickit
For my reference, can you clarify what exactly you're blocked waiting for? What feature(s) would unblock you, were they to exist?
@leonerd Here are the tickets:
- https://blueprints.launchpad.net/libtickit/+spec/override-terminfo
- https://blueprints.launchpad.net/libtickit/+spec/ctrl-h-as-backspace
- https://blueprints.launchpad.net/libtickit/+spec/termkey-merge
"override-terminfo" is the most important one, and it would unblock us.
I have a new approach. A program to guide users through interactively fixing their terminfo entry for their terminal.
A quick hack of a perl script currently here => http://fpaste.scsys.co.uk/499049
If this principle seems to be one that works, I'll have a go at writing it out as a standalone C program instead. Then we can refer users here to help them fix the 'backspace' entry, along with any other ones we find need fixing. This all seems much more the right solution, than trying to apply code in neovim (or any other program) to try to second-guess the values in terminfo. Far better to help the user set the known-correct ones.
@leonerd I understand and sympathize with the impetus behind your approach, but this still seems like something that needs a fully programmatic solution. Guided hoop-jumping is still hoop-jumping.
My terminfo entry has kbs=\177 and neovim still sees <C-h> as <BS>. This stuff is all way beyond my paygrade but it would appear that having a correct terminfo entry is not the solution here after all. @tarruda seems to have alluded to this earlier as well:
The problem is that every terminal seems to send ASCII DEL regardless of what terminfo says
So @leonerd's new approach isn't going to cut it, unfortunately. I guess someone's just going to have to bite the bullet and create some kind of override for the ASCII codes all these terminals are sending?
@mayhewluke That sounds an interesting cornercase; one I wasn't expecting to observe.
Can you dig a little deeper on that? What does the libtermkey demo program report for that key?
@mayhewluke - Hang on - before we continue, lets just clarify: Do you mean you are pressing the combination of keys "Ctrl" and "H", and neovim reports <BS>, or that you're pressing the key "Backspace" and it reports <C-h>? Your wording was a little ambiguous there.