On Windows with an installation of gvim 8.1, Numpad behavior is different between the GUI and the console.

The GUI (gvim.exe) has a TERM of builtin_gui and the keypad (with Numlock On) works properly. By properly, I mean in insert mode, when you hit Num 0, it inserts a 0.

However, the console version (vim.exe) has a TERM of win32 and the keypad (with Numlock On) inserts extended characters such as:

  1. ╬┌
  2. ╬▐
  3. ╬Γ
  4. ╬µ
  5. ╬Ω
  6. ╬ε
  7. ╬≥
  8. ╬÷
  9. ╬ ·
  10. ╬■

How would I go about changing the behavior of the numpad in the console? I have tried looking at the default vimscripts such as mswin.vim to see if there is any obvious behavior that could affect the function of the numpad, but I didn't see anything. I also searched Google and vi SE, but all answers I seemed to find had to do with the various terminal programs that people were using. This issue is when using vim.exe within the native Windows command prompt.

Edit: Providing Version information below.

VIM - Vi IMproved 8.1 (2018 May 18, compiled May 18 2018 18:26:56)
MS-Windows 32-bit console version
Included patches: 1
Compiled by mool@tororo
Huge version without GUI.  Features included (+) or not (-):
+acl               +eval              -mouseshape        -tag_any_white
+arabic            +ex_extra          +multi_byte        -tcl
+autocmd           +extra_search      +multi_lang        +termguicolors
+autoservername    +farsi             -mzscheme          +terminal
-balloon_eval      +file_in_path      -netbeans_intg     -tgetent
+balloon_eval_term +find_in_path      +num64             -termresponse
-browse            +float             +packages          +textobjects
++builtin_terms    +folding           +path_extra        +timers
+byte_offset       -footer            -perl              +title
+channel           +gettext/dyn       +persistent_undo   -toolbar
+cindent           -hangul_input      -postscript        +user_commands
+clientserver      +iconv/dyn         +printer           +vertsplit
+clipboard         +insert_expand     +profile           +virtualedit
+cmdline_compl     +job               -python            +visual
+cmdline_hist      +jumplist          -python3           +visualextra
+cmdline_info      +keymap            +quickfix          +viminfo
+comments          +lambda            +reltime           +vreplace
+conceal           +langmap           +rightleft         +vtp
+cryptv            +libcall           -ruby              +wildignore
+cscope            +linebreak         +scrollbind        +wildmenu
+cursorbind        +lispindent        +signs             +windows
+cursorshape       +listcmds          +smartindent       +writebackup
+dialog_con        +localmap          +startuptime       -xfontset
+diff              -lua               +statusline        -xim
+digraphs          +menu              -sun_workshop      -xpm_w32
-dnd               +mksession         +syntax            -xterm_save
-ebcdic            +modify_fname      +tag_binary
+emacs_tags        +mouse             +tag_old_static
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$HOME\vimfiles\vimrc"
 3rd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
       defaults file: "$VIMRUNTIME\defaults.vim"
Linking: link  /nologo /subsystem:console,5.01 /opt:ref /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib /machine:i386   libcmt.lib  user32.lib          WSock32.lib  /PDB:vim.pdb -debug
  • 1
    I can't reproduce it. Can you try it with vim -u NONE?
    – Maxim Kim
    Nov 5, 2019 at 6:43
  • 2
    I see the same non-functional keypad with my default Vim 8.1.374. This might depend on the codepage and your encoding option, but for me with a default codepage of 850 and latin1 encoding it doesn't work (the same for unicode codepage and utf-8 encoding). I just tried the latest available version 8.1.2256 and it works correctly there. Could be patch 8.1.457 Nov 5, 2019 at 7:29
  • @MaximKim same thing when executing vim -u NONE.
    – Damian T.
    Nov 5, 2019 at 17:08
  • 2
    @DamianT. Please update your Vim version Nov 5, 2019 at 17:35
  • 2
    @DamianT. Here we go: github.com/vim/vim-win32-installer Nov 5, 2019 at 18:01

1 Answer 1


This seems to be a bug in the original 8.1 version, that has since been fixed (possibly by patch v8.1.0457).

You can always test the latest nightly builds from the vim/vim-win32-installer repository. That one will provide nightly builds (and if I have the time, I'll also have the installer and the binaries signed using signpath.io)

Your Answer

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

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