After a near-crash, the assistance has installed LINUX 20.4 instead of 16.04. When in vi, I try to insert a ^C using ^V^C I insert <ESC>[27;5;99~

Can someone tell me which initialization file controls this behavior and what I must insert in it?

A long time ago, ^C could be inserted by ALT 003. Is this procedure (or a similar one) lost forever?

First of all, thanks to both.

xterm -v says


vi --version says

 "VIM - Vi IMproved 8.1 (2018 May 18, compiled Apr 15 2020 06:40:31)"

Plus, two pages of info that I will report below

$TERM is xterm

The two pages of extra info from vi --version are

Included patches: 1-2269
Modified by [email protected]
Compiled by [email protected]
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_any_white
+arabic            +file_in_path      +mouse_urxvt       -tcl
+autocmd           +find_in_path      +mouse_xterm       +termguicolors
+autochdir         +float             +multi_byte        +terminal
-autoservername    +folding           +multi_lang        +terminfo
-balloon_eval      -footer            -mzscheme          +termresponse
+balloon_eval_term +fork()            +netbeans_intg     +textobjects
-browse            +gettext           +num64             +textprop
++builtin_terms    -hangul_input      +packages          +timers
+byte_offset       +iconv             +path_extra        +title
+channel           +insert_expand     -perl              -toolbar
+cindent           +job               +persistent_undo   +user_commands
-clientserver      +jumplist          +postscript        +vartabs
-clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           -python            +visual
+cmdline_info      +libcall           +python3           +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          -ruby              +wildmenu
+cursorbind        -lua               +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con        +mksession         +smartindent       -X11
+diff              +modify_fname      +sound             -xfontset
+digraphs          +mouse             +spell             -xim
-dnd               -mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        -xsmp
+emacs_tags        +mouse_gpm         -sun_workshop      -xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary        
+extra_search      +mouse_sgr         -tag_old_static    
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -Wdate-time  -g -O2 -fdebug-prefix-map=/build/vim-iU6mZD/vim-8.1.2269=. -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux  -lcanberra -lacl -lattr -lgpm -ldl     -L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -lpython3.8 -lcrypt -lpthread -ldl -lutil -lm -lm      
  • 2
    This is modifyOtherKeys feature, from xterm. There was a bug in Vim which was fixed regarding this function, so what version is that? Also see :h modifyOtherKeys on how to disable this. Sep 8, 2021 at 11:41
  • 2
    Welcome to Vi and Vim! Can you share some more details about your terminal, TERM environment variable, and what version of vi you are using? You can include them in your post via an edit.
    – D. Ben Knoble
    Sep 8, 2021 at 14:59
  • Thanks Christian, your fix works. The problem was a destructive interaction of configuration files and env variables. For what regards :compatible, this brings the vim too back in time, with the loss of the multi-level undo, that is a necessary tool. thanks to all. Sep 14, 2021 at 23:57
  • @pietrospizzo if you want to add an answer, please add exact details about how to solve the problem. Referring to comments and help is of course acceptable, but your fix works. The problem was a destructive interaction of configuration files and env variables. is a bit too vague
    – D. Ben Knoble
    Sep 15, 2021 at 19:16

2 Answers 2


The "equivalent" to dos's alt-numpad in vim is ^VuHHHH where you can enter four hex digits, or ^VUHHHHHHHH for 8 digits. The hex number is the unicode code point, so if ^V^C does not work, you can enter it using ^Vu0003

  • that is not hunder percent correct. You can insert literal keys using CTRL-V in insert mode, see :h i_CTRL-V and :h i_CTRL-SHIFT-V (for modifyOtherKeys that are active here and is therefore more appropriate in this case) Jul 8 at 17:06

The simplest fix to bring the vi back in time to what I was used to is to give the flags -i NONE -u NONE. You should also know about :set compatible.

For myself, this is preferable; for someone newer to vi/vim, I would recommend learning the new features.

  • What's wrong with :h modifyOtherKeys and disabling it if you do not like that? Sep 14, 2021 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.