I recently had a need to type the letters æ, ø, and å. For context, these are available on my physical keyboard, and work fine in other programs. It's also a Norwegian keyboard (+ layout), if that's relevant.

With Vim, and specifically gVim, only æ and ø work. Other combined letters (such as ö and â) work out of the box, though by using dead keys to actually do so. Attempting to write å results in various behavior I can't understand. With no remapping, pressing it shifts around lines or letters. Typing it in an empty buffer with no remapping pulls code from somewhere, though I don't understand how.

I know I can type the letter with <C-v> (as suggested here), or with <C-k> å å, but this is slow and, in my opinion, unnecessary. Also, <C-v> å results in å, so I'm assuming I'm supposed to use it when attempting to remap.

I tried with imap å <C-v> å, imap å <C-k>å, imap å <C-k> å, imap å <C-k> å å, imap å <C-k> åå, and the basic imap å å, but none of them give me the letter. Remapping it to other output letters doesn't do anything at all (one of the other variants listed here resulted in an e).

How can I make Vim properly type non-ASCII letters?

When I haven't explicitly remapped it myself for science, :verbose map å says the key isn't used.

  • 1
    :verbose map shows the mappings for normal, visual, select, and operator-pending mode. For insert mode mappings you need to use :verbose imap or :verbose map! (see :help map-modes). Aug 26, 2019 at 9:43
  • 1
    @JürgenKrämer Right, I keep mixing those up ^^" å was actually remapped by a plugin (github.com/jiangmiao/auto-pairs). For a quick hackish test, disabling it fixed the letter, so I'll just have to see if I can avoid that specific mapping with some config. Also, does it make sense to keep the question or should I just delete it?
    – Zoe
    Aug 26, 2019 at 9:50
  • 2
    @Zoe You should self-answer, indicate how you found the mapping existed and how you found which plug-in set the mapping. If you find more about how it set it and why, include that in your answer as well...
    – filbranden
    Aug 26, 2019 at 10:04

1 Answer 1


:verbose map does not work for detecting the keybind in insert mode. Since it's while editing, and the relevant mapping is imap or inoremap, :verbose imap/:verbose map! are the two correct options to use for tracking down the conflict.

In this case, the reason I had such weird behavior is because of the function it's mapped to. It calls a function in a parentheses auto-completion/utility plugin, and specifically a fast wrap feature.

However, independently of that plugin, a meta keybind conflicting with a letter does indeed cause unexpected behavior. What that behavior is depends on the mapping used. Whether it's from a plugin or something you set yourself, is something you'll have to figure out.

In general

Some meta keybinds map to non-ascii/European/other letters. In insert mode, this means the corresponding letters become an alternate way to use the meta keybind. This boils down to how input processing in Vim works, and that's a convoluted mess I don't understand myself, so I won't comment too much on it.

Use :verbose imap å (replace å with your affected letter) to determine which keybind is affected.

As an example, å is equivalent to <M-e> on my system. <M-e> may correspond to something else on your system, however, because input processing is weird.

When you determine which keybind is affected with :verbose imap, you'll be able to track down the source. verbose imap includes a path to the affected file, as well as the line it's declared on.

Taking a look at the output I had:

:verbose imap å
i  å           *@<C-R>=AutoPairsFastWrap()<CR>
    Last set from ~\.vim\plugged\auto-pairs\plugin\auto-pairs.vim line 562

The second line is the part that's guaranteed to give you enough information. Reading the relevant information is trivial, and explicitly a part of the output.

If your keybinding is set from a:

  • a .vimrc or other config file you've written, edit the keybind to something else.
  • a plugin, read the documentation and/or plugin code. Some plugins have variables for re-mapping or fully unmapping keys. If no such option exists, find the bug tracker for the plugin and post there. As a hack, you can always edit the file in the meanwhile, but this may cause conflicts if you use a plugin manager with semi-automatic updates.

When you've fixed it, you of course need to reload Vim, and you should be good to go.

Note: I highly recommend avoiding meta-based keybinds in insert mode entirely, particularly in plugins.


In my particular case, jiangmiao/auto-pairs was the source of this problem.

Running :verbose imap å or :verbose map! å gave me this:

i  å           *@<C-R>=AutoPairsFastWrap()<CR>
    Last set from ~\.vim\plugged\auto-pairs\plugin\auto-pairs.vim line 562

The block that set the shortcut looks like this:

if g:AutoPairsShortcutFastWrap != ''
  execute 'inoremap <buffer> <silent> '.g:AutoPairsShortcutFastWrap.' <C-R>=AutoPairsFastWrap()<CR>'

By default, the shortcut is set to <M-e>, but that in itself doesn't necessarily make sense, especially with the mapping. If, however, you type <M-e> when it's not remapped, it outputs å. <C-v> <M-e> also gives å this might be keyboard-dependent - I'm not sure and I can't test it. So the plugin remapping <M-e> resulted in å being remapped to a function that when provided sensible input works fine, but when provided none or invalid input results in the weird behavior I saw.

The reason I couldn't override it is because the original remapping was done with <buffer>, which seems to override the global ones. I think that's the reason imap å å didn't work. With imap <buffer> å å, it outputs å instead of calling the plugin function that originally defined it.

That being said, there's a relatively easy fix to this that doesn't require any remapping of å, but rather remapping the plugin. The code I showed earlier uses g:AutoPairsShortcutFastWrap, which defines which key it'll map to. I just decided on <C-f>, but any unused shortcut will do:

let g:AutoPairsShortcutFastWrap = "<C-f>"

After reloading Vim, å works as a normal letter again.

  • 1
    It sounds like either you have a broken terminal with "bit8meta", i.e. alt+key produces a single byte that's 0x80|key, or vim is configured to expect such a terminal. This is a backwards convention from the 80s that's complely incompatible with non-ascii text and should have been removed from everything that supported it at least 2 decades ago, but of course it wasn't. The correct behavior for the meta (alt) key is to generate Esc followed by the key. Alternatively it could generate the UTF-8 form of C1 control characters, but nobody does that. Aug 26, 2019 at 21:48
  • @R.. I'm using gvim (see the tags - also running 8.1). If that's relevant, I set the charset to utf-8. Not sure if I've somehow configured it to expect bit8meta, but I at least haven't done that intentionally. It could be that gvim somehow interprets it as the letter due to some weird implementation. I actually have some other things Vim does that I can't do elsewhere without some form of markdown/rendering (like Unicode sup numbers). Dunno though. I'll see if I can repro on a Linux install (freshly installed today) using gvim and terminal Vim, and see if my config somehow makes a difference.
    – Zoe
    Aug 26, 2019 at 21:59

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.