[vim/vim] Home/End/PgUp/PgDn keys don't work in :terminal in certain terminals (Issue #17331)
erry
AstroSnail created an issue (vim/vim#17331)Steps to reproduce
This seems to be an artifact of unfinished code in terminal.c. There doesn't seem to be a "more context" box in the issue form so I'm going to dump everything in the "steps to reproduce" box.
- Open a terminal compatible with
xterm-codes(see vim:helpabout it). I've found that XTerm and Termux (the Android app) allow this issue to reproduce. I haven't extensively tested with other terminals or screens. - Open
vim --clean - Open
:terminal - Try pressing some keys on the keyboard editing pad, in particular: Home, End, PgUp, PgDn.
Notice that these keys produce, respectively: 7, 1, 9, 3. Notice that these correspond exactly to the keys on the numpad whose (non-numlock) functions are Home, End, PgUp, PgDn. The numpad keys themselves are not the subject of this issue, they are important context for the issue with the editing pad keys.
When Vim senses that the terminal may be compatible with xterm-codes, and xtermcodes is enabled, it requests a bunch of termcap strings from the terminal directly, overriding whatever it read from terminfo, in particular: kh, @7, kP, kN (respectively, Home, End, PgUp, PgDn on the editing pad), K1, K4, K3, K5 (respectively, Home, End, PgUp, PgDn on the numpad). Related code.
The final requirement is this: the terminal needs to respond, for the corresponding editing pad keys and numpad keys, with the same escape sequence. This can be entirely true, for example XTerm sends the same escape sequence for editing pad Home and numpad Home (when numlock is off). Vim requests these codes after setting the terminal to application mode, so the result is that <xHome> and <kHome> match the same string (ESC O H, using SS3 instead of CSI), likewise for the other keys.
(I expect that, if there exists a terminfo file that satisfies this final reproducing requirement directly, then this issue would reproduce by simply setting $TERM to that string. I haven't explored for such a terminfo, and importantly XTerm's terminfo doesn't do this (unlike what XTerm itself responds, surprisingly!), so terminals which borrow XTerm's terminfo don't automatically cause this issue to reproduce.)
This causes nothing out of the ordinary throughout most of Vim (that i've seen so far...), except :terminal. When inserting into an active :terminal, it seems to prefer interpreting the "xHome or kHome" ambiguity as kHome. This by itself is still not a problem because this can still be reasonably expected to produce the escape sequence for the Home function. But the code that translates the key into terminal input decides that kHome should produce numpad 7 instead, likewise for the other keys.
Thus, the observed behaviour: pressing Home on the editing pad produces 7, and it's impossible to use Home (and End, PgUp, PgDn) inside the :terminal.
There is an extremely easy workaround, courtesy of this Arch Wiki thread: tmap <kHome> <xHome>, likewise for the other keys. This causes :terminal to see xHome instead of kHome, and correctly translate it to a Home keypress. I don't see any reason for kHome to work any differently in :terminal (if numlock is on, the terminal will just send 7, indistinguishable between numpad and number row), so I consider this a bug.
Setting noxtermcodes is also an easy workaround, though it also makes Vim think XTerm can only render 8 colors. (t_Co is set to 8 instead of 256)
Expected behaviour
Pressing Home, End, PgUp, PgDn in :terminal should produce escape sequences that correspond to the function (this appears to be, respectively, ESC [ H, ESC [ F, ESC [ 5 ~, ESC [ 6 ~), and ultimately should allow the program running inside the :terminal to understand the function being used (e.g. readline moves to the left/right edge of the cmdline, or goes up/down in history, of course depending on its configuration)
Version of Vim
9.1.1336
Environment
Operating system:
- system:
"x86_64-linux" - host os:
Linux 6.12.28, NixOS, 25.05 (Warbler), 25.05pre799423.adaa24fbf467 - multi-user?:
yes - sandbox:
yes - version:
nix-env (Nix) 2.28.3 - channels(root):
"nixos" - channels(erry):
"home-manager" - nixpkgs:
/nix/store/3g6wk26mlpsxqmin7fng91nnlkq6nsy1-nixos/nixos
Terminal: XTerm(397)
Value of $TERM: xterm
Shell: GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17331)Thanks, that is quite a detailed bug report. Unfortunately I don't currently know the terminal code well enough to attempt to fix it right now.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
erry
AstroSnail left a comment (vim/vim#17331)I've made a new discovery: if I tell XTerm to use "VT220 Keyboard Mode" (either through the entry in the "Main Options" menu, or the -kt vt220 option, or the XTerm.keyboardType: vt220 resource), it changes the behaviour of the keys involved in this issue. This time, the editing pad keys and numpad keys always produce distinct escape sequences, e.g. editing pad Home produces ESC [ 1 ~, while numpad Home produces ESC O w (after activating application mode, terminfo smkx). This is reflected in the data that Vim receives in response to xterm-codes:
(vim --clean with default keyboard mode)
20250525_12h43m57s_grim.png (view on web)
(vim --clean with vt220 keyboard mode)
20250525_12h44m15s_grim.png (view on web)
So, this could be another workaround! Indeed, using this VT220 Keyboard Mode causes the End, PgUp and PgDn keys to work perfectly in :terminal. But, somehow, not Home, which still produces 7! I cannot yet explain this behaviour. The only clue I have is that it seems Vim by default understands ESC [ 1 ~ as kHome, but the same is true of the End key...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bujiraso
Bujiraso left a comment (vim/vim#17331)I also have this nuisance recently popping up in my awareness on NixOS, and it's feels new to me as of either late 25.05 or recent 25.11 changes.
Things that didn't work
- Reverting to old editions of vim doesn't seem to fix it, even near 2y of reversion for NixOS 24.05's edition (
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jan 01 1980 00:00:00)\n - Included patches: 1-765). - Tweaking TERM, either by ensuring it's unset or set to one of the various incantations whispered with little technical rationale on one of the various web search results/forums.
- Setting =:term= in vim to any some such similar random mystery spells
Things that may lead to a solution
If I run vim -u NONE, the good functionality is restored. If I then run :source ${VIM_INSTALL}/share/vim/vimrc where the ${VIM_INSTALL} here is really just any installed edition of vim. I'm abstracting that here to point out that this is the same on multiple editions of vim (NixOS 24.05, 24.11, 25.05, 25.11 are what I tried). In brief, just source .../share/vim/vimrc to get it to break again.
After such a source, these are then loaded:
:scriptnames
1: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vimrc
2: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/syntax/syntax.vim
3: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/syntax/synload.vim
4: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/syntax/syncolor.vim
5: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/colors/lists/default.vim
6: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/filetype.vim
7: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/scripts.vim
8: /nix/store/2qyb624x1fhd22gwdg94gcnihzysxxzh-vim-full-9.1.0765/share/vim/vim91/autoload/dist/script.vim
This leads to me to believe that the issue is somehow in what's supporting vim. In guake and gnome-console, supported by Gnome3, on Wayland the issue occurs, so maybe something changed for the worse in those and not here.
Things that /at least/ work around the problem
To get back to work, I'm doing this.
tmap <kHome> <Home>
tmap <kEnd> <End>
tmap <kPageUp> <PageUp>
tmap <kPageDown> <PageDown>
Does this have any negative implications? Can we simply install that into a late-load .vim and call it a day?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
erry
AstroSnail left a comment (vim/vim#17331)@Bujiraso Nice find! I looked into it, and it seems that the important difference is the esckeys setting. When running Vim with -u NONE, it starts in compatible mode by default, which sets noesckeys. This turns off several features of Vim; the most noticeable to a beginner is the ability to use the arrow keys to move the cursor while in insert mode, but it also suppresses some terminal identification features, meaning that it has a similar effect to setting noxtermcodes. In my main post I mentioned that setting noxtermcodes is a possible workaround for this issue. You also correctly identified the workaround using tmap that I also mentioned.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.