[vim/vim] F3 does not send the correct keycode on Foot terminal (Issue #18100)
GallaisPoutine
GallaisPoutine created an issue (vim/vim#18100)Steps to reproduce
- Open foot
- Open a vim
- In Insert mode type "^v" then F3
- The litteral character showed is "^[[13~"
(This show the issue, further steps are the 'control samples')
5. Open another terminal (alacritty in this case)
6. Repeat Steps 2 and 3
7. The litteral character showed is "^[OR"
8. Change tty (Ctrl+Alt+F2)
9. Repeat steps 2 and 3
10. The litteral character is "^[[[C"
Expected behaviour
On Vim, using Foot terminal, F3 does not send the right keycode. This causes when binding the F3 special code to invert uppercase of the 3 characters following the cursor (which concur with the "3~" keycode).
My investigation:
I first removed all the plugins to use a lightweight Vim, but the issue remained. Changing tty and logging in another session made the issue disappear, which led my to think Foot was faulty.
After asking in the #foot IRC channel, someone pointed me those links:
https://codeberg.org/dnkl/foot/src/branch/master/CHANGELOG.md#changed-17:~:text=F3%20is%20now%20encoded%20as%20CSI%2013~
https://sw.kovidgoyal.net/kitty/keyboard-protocol/
kovidgoyal/kitty@cd92d50
So for me it looks like vim just hasn't adapted to the change mentioned in the foot changelog yet.
Version of Vim
VIM - Vi IMproved 9.1 (2024 Jan 02, compilĆ© Aug 10 2025 19:46:14) Rustines incluses : 1-1623 CompilĆ© par Arch Linux Ćnorme version avec interface graphique GTK3. FonctionnalitĆ©s incluses (+) ou non (-) : +acl +cscope -hangul_input +mouse_dec +profile -tag_any_white +wayland +arabic +cursorbind +iconv +mouse_gpm -python +tcl/dyn +wayland_clipboard +autocmd +cursorshape +insert_expand -mouse_jsbterm +python3/dyn +termguicolors +wildignore +autochdir +dialog_con_gui +ipv6 +mouse_netterm +quickfix +terminal +wildmenu -autoservername +diff +job +mouse_sgr +reltime +terminfo +windows +balloon_eval +digraphs +jumplist -mouse_sysmouse +rightleft +termresponse +writebackup +balloon_eval_term +dnd +keymap +mouse_urxvt +ruby/dyn +textobjects +X11 +browse -ebcdic +lambda +mouse_xterm +scrollbind +textprop +xattr ++builtin_terms +emacs_tags +langmap +multi_byte +signs +timers -xfontset +byte_offset +eval +libcall +multi_lang +smartindent +title +xim +channel +ex_extra +linebreak -mzscheme -sodium +toolbar -xpm +cindent +extra_search +lispindent +netbeans_intg +sound +user_commands +xsmp_interact +clientserver -farsi +listcmds +num64 +spell +vartabs +xterm_clipboard +clipboard +file_in_path +localmap +packages +startuptime +vertsplit -xterm_save +cmdline_compl +find_in_path +lua/dyn +path_extra +statusline +vim9script +cmdline_hist +float +menu +perl/dyn -sun_workshop +viminfo +cmdline_info +folding +mksession +persistent_undo +syntax +virtualedit +comments -footer +modify_fname +popupwin +tabpanel +visual +conceal +fork() +mouse +postscript +tag_binary +visualextra +cryptv +gettext +mouseshape +printer -tag_old_static +vreplace fichier vimrc systĆØme : "/etc/vimrc" fichier vimrc utilisateur : "$HOME/.vimrc" 2e fichier vimrc utilisateur : "/.vim/vimrc" 3e fichier vimrc utilisateur : "$XDG_CONFIG_HOME/vim/vimrc" fichier exrc utilisateur : "$HOME/.exrc" fichier gvimrc systĆØme : "/etc/gvimrc" fichier gvimrc utilisateur : "$HOME/.gvimrc" 2e fichier gvimrc utilisateur : "/.vim/gvimrc" 3e fichier gvimrc utilisateur : "$XDG_CONFIG_HOME/vim/gvimrc" fichier de valeurs par dĆ©faut : "$VIMRUNTIME/defaults.vim" fichier menu systĆØme : "$VIMRUNTIME/menu.vim" $VIM par dĆ©faut : "/usr/share/vim" Compilation : gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/cloudproviders -I/usr/i nclude/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/atk-1.0 -I/usr/include/dbus-1.0 -I/ usr/lib/dbus-1.0/include -I/usr/include/fribidi -I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/us r/include/gio-unix-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/sysprof-6 -pthr ead -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-f rame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/vim/src=/usr/src/debug/vim -flto=auto -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_ SOURCE=1 Ćdition de liens : gcc -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.42/core_perl/CORE -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,p ack-relative-relocs -flto=auto -L/usr/local/lib -o vim -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lcairo-gobject -lgdk_pixbuf-2.0 -latk-1.0 -lpango-1.0 -lc airo -lharfbuzz -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXt -lX11 -lwayland-client -lm -lXdmcp -lSM -lICE -lm -ltinfo -lcanberra -lacl -lattr - lgpm -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lm
Environment
OS: Linux archlinux 6.15.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 02 Aug 2025 01:20:06 +0000 x86_64 GNU/Linux
Terminal: foot version: 1.23.1 +pgo +ime +graphemes -assertions
$TERM value: foot
$SHELL value: /bin/bash
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#18100)This seems to be the same as this one for kitty: #13328 (comment)
In short, the terminfo database needs to be fixed
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
GallaisPoutine
GallaisPoutine left a comment (vim/vim#18100)@chrisbra so this is not a fix that can be done in Vim ? I was going through the source code
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
GallaisPoutine
GallaisPoutine left a comment (vim/vim#18100)Hi again @chrisbra
I've modified the terminfo database and compiled it. It works like that, however I disagree with the way to fix this issue.
Below that only (after modifications) the foot terminfo are changed.
āā[raphael@archlinux:~] āāā¼ infocmp -L -1 xterm | grep 'key_f[1-9]=' key_f1=\EOP, key_f2=\EOQ, key_f3=\EOR, key_f4=\EOS, key_f5=\E[15~, key_f6=\E[17~, key_f7=\E[18~, key_f8=\E[19~, key_f9=\E[20~, āā[raphael@archlinux:~] āāā¼ infocmp -L -1 kitty | grep 'key_f[1-9]=' key_f1=\EOP, key_f2=\EOQ, key_f3=\EOR, key_f4=\EOS, key_f5=\E[15~, key_f6=\E[17~, key_f7=\E[18~, key_f8=\E[19~, key_f9=\E[20~, āā[raphael@archlinux:~] āāā¼ infocmp -L -1 alacritty | grep 'key_f[1-9]=' key_f1=\EOP, key_f2=\EOQ, key_f3=\EOR, key_f4=\EOS, key_f5=\E[15~, key_f6=\E[17~, key_f7=\E[18~, key_f8=\E[19~, key_f9=\E[20~, āā[raphael@archlinux:~] āāā¼ infocmp -L -1 vt100 | grep 'key_f[1-9]=' key_f1=\EOP, key_f2=\EOQ, key_f3=\EOR, key_f4=\EOS, key_f5=\EOt, key_f6=\EOu, key_f7=\EOv, key_f8=\EOl, key_f9=\EOw, āā[raphael@archlinux:~] āāā¼ infocmp -L -1 foot | grep 'key_f[1-9]=' key_f1=\E[11~, key_f2=\E[12~, key_f3=\E[13~, key_f4=\E[14~, key_f5=\E[15~, key_f6=\E[17~, key_f7=\E[18~, key_f8=\E[19~, key_f9=\E[20~,
Moreover from what I understand from the terminfo is that it provides the default keybindings for the applications to run. By default using foot terminal, the kitty keyboard protocol is enabled :
:verbose map Kitty keyboard protocol: On
So Vim should decode keys according to the protocol, not by using terminfo.
ā
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18100)Well the terminfo database is there for a reason and it should be correct. So the solution is to update the terminfo database.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #18100 as not planned.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Daniel Eklƶf
dnkl left a comment (vim/vim#18100)The terminfo is correct; it reflects the default terminal configuration, where F3 does result in \EOR.
You then choose to opt-in to the kitty keyboard protocol, which uses a different encoding for F3.
But hey, let's assume terminfo is what needs fixing. We can't modify the existing terminfo, since that'd break all applications that don't enable the kitty keyboard protocol. So we'd need a new terminfo, and the user would have to know which applications enable the kitty keyboard protocol, and which terminfo that corresponds to. My guess is very few people would get this right.
And oh, at least kitty, alacritty and ghostty have the same "issue" as foot - the default escape for F3 is \EOR, but once the kitty keyboard protocol is enabled, it's \E[13~. All of them are also doing it wrong?
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)And oh, at least kitty, alacritty and ghostty have the same "issue" as foot - the default escape for F3 is
\EOR, but once the kitty keyboard protocol is enabled, it's\E[13~. All of them are also doing it wrong?
F3 works for me in alacritty and doesn't in foot.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Daniel Eklƶf
dnkl left a comment (vim/vim#18100)Then vim is either not enabling the kitty keyboard protocol in alacritty, or vim is giving alacritty special treatment. I would guess the former.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)accoriding to :h keyprotocol it doesn't enable kitty keyboard protocol for foot as well.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Daniel Eklƶf
dnkl left a comment (vim/vim#18100)How is any of this relevant to the discussion? The default value of keyprotocol (vim 9.1.1623-1, arch default package) is keyprotocol=kitty:kitty,foot:kitty,ghostty:kitty,wezterm:kitty,xterm:mok2. I can enable debug logging in the terminal that shows vim enables the most basic feature of the kitty keyboard protocol - "Disambiguate escape codes".
And that is the problem - vim enables the kitty keyboard protocol, but then doesn't follow the kitty keyboard specification when decoding the key events.
ā
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#18100)So you are basically saying Vim shouldn't trust the terminfo database when using the kitty protocol? That is new to me.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)How is any of this relevant to the discussion? The default value of keyprotocol (vim 9.1.1623-1, arch default package) is keyprotocol=kitty:kitty,foot:kitty,ghostty:kitty,wezterm:kitty,xterm:mok2
Yep, I misread the help topic. I have enabled it for alacritty and F3 doesn't work anymore there.
And that is the problem - vim enables the kitty keyboard protocol, but then doesn't follow the kitty keyboard specification when decoding the key events.
Probably issue needs to be reopen.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)patch 9.0.0985: when using kitty keyboard protocol function keys may not work
Problem: When using kitty keyboard protocol function keys may not work.
(Kovid Goyal)
Solution: Recognize CSI ending in [ABCDEFHPQRS] also when the termcap
entries are not specified. (closes #11648)
And there is a test in that patch that checks maps with F1-F10.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)so, this patch is the one:
~/prj/vim $ git bisect good
afa3f1cc7258d34c32a299a3cc6aece89f67fb47 is the first bad commit
commit afa3f1cc7258d34c32a299a3cc6aece89f67fb47 (tag: v9.0.1080)
Author: Bram Moolenaar <Br...@vim.org>
Date: Mon Dec 19 18:56:48 2022 +0000
patch 9.0.1080: the "kitty" terminfo entry is not widespread
Problem: The "kitty" terminfo entry is not widespread, resulting in the
kitty terminal not working properly.
Solution: Go back to using "xterm-kitty" and avoid the problems it causes in
another way.
runtime/doc/term.txt | 11 ++++++++---
src/os_unix.c | 5 ++++-
src/term.c | 51 +++++++++++++++++++--------------------------------
src/version.c | 2 ++
4 files changed, 33 insertions(+), 36 deletions(-)
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Daniel Eklƶf
dnkl left a comment (vim/vim#18100)So you are basically saying Vim shouldn't trust the terminfo database when using the kitty protocol? That is new to me.
@chrisbra I would say so, yes. Terminfo is static, and cannot be changed run-time. Thus it reflects the terminal's default configuration. Enabling a non-default keyboard protocol like kitty means the terminal is no longer in its default state.
All the terminals mentioned above use \EOR for F3 by default, since that's what non-kitty enabled applications expect. While you could say that applications should be using the terminfo for this use case, and not just assume F3 is \EOR, we all know that's not what the real world looks like, sadly.
Finally, the kitty keyboard protocol originally allowed F1-F4 to be represented by either a letter (the well known P, Q, R, S), or 11/12/13/14~. The optional R representation for F3 was later removed from the kitty specification, since it conflicts with the cursor position report sequence. See kovidgoyal/kitty@cd92d50.
Compiled it and I can see F1-F4 with Ctrl-v
@habamax not sure what that's supposed to show. If foot sends \EOR, then you're either running a very old version of foot (before F3 was changed in the kitty specification - any version of foot before 1.15.0 will encode F3 as \EOR, even when the kitty keyboard protocol has been enabled). Or, that version of vim isn't enabling the kitty keyboard protocol in foot. Any recent version of foot will always encode F3 as \E[13~ when the kitty keyboard protocol has been enabled.
ā
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#18100)Okay I re-open. Not sure when I will come to this, but I don't think it's very critical, there are few ways around it even when not changing the terminfo, like :set t_kf3=<c-v><f3>.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Reopened #18100.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)@habamax not sure what that's supposed to show. If foot sends \EOR, then you're either running a very old version of foot (before F3 was changed in the kitty specification - any version of foot before 1.15.0 will encode F3 as \EOR, even when the kitty keyboard protocol has been enabled). Or, that version of vim isn't enabling the kitty keyboard protocol in foot. Any recent version of foot will always encode F3 as \E[13~ when the kitty keyboard protocol has been enabled.
It wasn't for you, but for Christian.
foot is the one debian 13 has at the moment.
If I press CTRL-V <F3> in the master vim in the same foot, I get
But it is not recognized as F3 in vim as we already know.
ā
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#18100)I am not hundert percent sure, but I believe the following patch should work (famous last words š )
diff --git a/src/term.c b/src/term.c index 2800535f5..81445ecf2 100644 --- a/src/term.c +++ b/src/term.c @@ -5352,7 +5352,8 @@ handle_key_with_modifier( int offset, char_u *buf, int bufsize, - int *buflen) + int *buflen, + int iskitty) { // Only set seenModifyOtherKeys for the "{lead}27;" code to avoid setting // it for terminals using the kitty keyboard protocol. Xterm sends @@ -5365,7 +5366,7 @@ handle_key_with_modifier( // // Do not set seenModifyOtherKeys for kitty, it does send some sequences // like this but does not have the modifyOtherKeys feature. - if (trail != 'u' + if (!iskitty && (kitty_protocol_state == KKPS_INITIAL || kitty_protocol_state == KKPS_OFF || kitty_protocol_state == KKPS_AFTER_T_TE) @@ -5377,7 +5378,7 @@ handle_key_with_modifier( seenModifyOtherKeys = TRUE; } - int key = trail == 'u' ? arg[0] : arg[2]; + int key = iskitty ? arg[0] : arg[2]; int modifiers = decode_modifiers(arg[1]); // Some terminals do not apply the Shift modifier to the key. To make @@ -5390,6 +5391,28 @@ handle_key_with_modifier( if (key == ESC) key = K_ESC; + else if (arg[0] >= 11 && arg[0] <= 24) + { + char_u key_name[2]; + + switch (arg[0]) + { + case 11: key_name[0] = 'k'; key_name[1] = '1'; break; // K_F1 + case 12: key_name[0] = 'k'; key_name[1] = '2'; break; // K_F2 + case 13: key_name[0] = 'k'; key_name[1] = '3'; break; // K_F3 + case 14: key_name[0] = 'k'; key_name[1] = '4'; break; // K_F4 + case 15: key_name[0] = 'k'; key_name[1] = '5'; break; // K_F5 + case 17: key_name[0] = 'k'; key_name[1] = '6'; break; // K_F6 + case 18: key_name[0] = 'k'; key_name[1] = '7'; break; // K_F7 + case 19: key_name[0] = 'k'; key_name[1] = '8'; break; // K_F8 + case 20: key_name[0] = 'k'; key_name[1] = '9'; break; // K_F9 + case 21: key_name[0] = 'F'; key_name[1] = ';'; break; // K_F10 + case 23: key_name[0] = 'F'; key_name[1] = '1'; break; // K_F11 + case 24: key_name[0] = 'F'; key_name[1] = '2'; break; // K_F12 + } + key = TERMCAP2KEY(key_name[0], key_name[1]); + } + return put_key_modifiers_in_typebuf(key, modifiers, csi_len, offset, buf, bufsize, buflen); } @@ -5397,6 +5420,7 @@ handle_key_with_modifier( /* * Handle a sequence with key without a modifier: * {lead}{key}u + * {lead}{key}~ * Returns the difference in length. */ static int @@ -5420,6 +5444,32 @@ handle_key_without_modifier( string[2] = KE_ESC; new_slen = 3; } + else if (arg[0] >= 11 && arg[0] <= 24) + { + char_u key_name[2]; + int key; + + switch (arg[0]) + { + case 11: key_name[0] = 'k'; key_name[1] = '1'; break; // K_F1 + case 12: key_name[0] = 'k'; key_name[1] = '2'; break; // K_F2 + case 13: key_name[0] = 'k'; key_name[1] = '3'; break; // K_F3 + case 14: key_name[0] = 'k'; key_name[1] = '4'; break; // K_F4 + case 15: key_name[0] = 'k'; key_name[1] = '5'; break; // K_F5 + case 17: key_name[0] = 'k'; key_name[1] = '6'; break; // K_F6 + case 18: key_name[0] = 'k'; key_name[1] = '7'; break; // K_F7 + case 19: key_name[0] = 'k'; key_name[1] = '8'; break; // K_F8 + case 20: key_name[0] = 'k'; key_name[1] = '9'; break; // K_F9 + case 21: key_name[0] = 'F'; key_name[1] = ';'; break; // K_F10 + case 23: key_name[0] = 'F'; key_name[1] = '1'; break; // K_F11 + case 24: key_name[0] = 'F'; key_name[1] = '2'; break; // K_F12 + } + key = TERMCAP2KEY(key_name[0], key_name[1]); + string[0] = K_SPECIAL; + string[1] = KEY2TERMCAP0(key); + string[2] = KEY2TERMCAP1(key); + new_slen = 3; + } else new_slen = add_key_to_buf(arg[0], string); @@ -5717,19 +5767,22 @@ handle_csi( // Key with modifier: // {lead}27;{modifier};{key}~ // {lead}{key};{modifier}u + // {lead}{key};{modifier}~ // Even though we only handle four modifiers and the {modifier} value // should be 16 or lower, we accept all modifier values to avoid the raw // sequence to be passed through. else if ((arg[0] == 27 && argc == 3 && trail == '~') - || (argc == 2 && trail == 'u')) + || (argc == 2 && (trail == 'u' || trail == '~'))) { + int iskitty = argc == 2 && (trail == 'u' || trail == '~'); return len + handle_key_with_modifier(arg, trail, - csi_len, offset, buf, bufsize, buflen); + csi_len, offset, buf, bufsize, buflen, iskitty); } // Key without modifier (Kitty sends this for Esc): // {lead}{key}u - else if (argc == 1 && trail == 'u') + // {lead}{key}~ + else if (argc == 1 && (trail == 'u' || trail == '~')) { return len + handle_key_without_modifier(arg, csi_len, offset, buf, bufsize, buflen);
ā
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)@chrisbra could you put it into a PR, it would be easier for me (and maybe others) to test?
ā
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#18100)Here we go: #18126
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
cunlem
cunlem left a comment (vim/vim#18100)there are few ways around it even when not changing the terminfo, like
:set t_kf3=<c-v><f3>.
This gives error. I guess you meant :set t_k3=<c-v><f3>? This gives no error but it doesn't help either.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18100)there are few ways around it even when not changing the terminfo, like
:set t_kf3=<c-v><f3>.This gives error. I guess you meant
:set t_k3=<c-v><f3>? This gives no error but it doesn't help either.
It works for me:
image.png (view on web)Did you literally press CTRL-V<F3> or copy-pasted what @chrisbra suggested?
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
cunlem
cunlem left a comment (vim/vim#18100)Yes I haven't realized that it requires raw input. Thanks for clarifying now I can add it to my vimrc.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #18100 as completed via 58c5a77.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Julien Barnoin
jbarnoin left a comment (vim/vim#18100)Yes I haven't realized that it requires raw input. Thanks for clarifying now I can add it to my vimrc.
Hey @cunlem , I'm looking into this workaround as I don't have the fixed version of vim yet.
Were you able to successfully set this in your .vimrc ? On my end the workaround works when executing the command directly, or when manually sourcing my .vimrc, but not immediately on startup. Running from ~/.vim/after/plugin didn't work either.
It seems like the t_k3 setting is being overridden late during startup after scripts have been executed, returning it to the value defined by the protocol - perhaps due to the protocol detection and key initialization code?
The one workaround I found that worked in .vimrc on startup was to define my mapping directly using:
noremap ^[[13;129~ :somecommand
For some reason the workaround above works, with NumLock modifier set, but if I try with NumLock disabled:
noremap ^[[13~ :somecommand
... that seems not to work. Good enough for my immediate use but I'm not sure why overriding won't work and if there's a way to achieve this on startup.
Note: Overriding a t_k* setting seems to work as expected when running vim from Gnome Terminal, the setting does not get reset after .vimrc and other scripts have run (that was just a test, this fix is not required for Gnome Terminal).
ā
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#18100)I would say compile your own version or change terminfo or use the above workaround are enough ways to make it work for you
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Julien Barnoin
jbarnoin left a comment (vim/vim#18100)Sure, it's good enough for a temporary workaround and will get fixed once I upgrade.
I thought I'd share what I found in case anyone else needed it as the situation might perdure for a bit on Debian 13 versions of kitty and vim, and in case anyone had a better option to share.
ā
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.