Why does Vim interpret â as Alt-b in a mapping?

Question

I have the following code in my vimrc:

function! s:WordPos(dir) abort
    return a:dir ==# 'right'
    \ ? searchpos('\<', 'nz', line('.'))[1]
    \ : searchpos('\<', 'bn', line('.'))[1]
endfunction

silent! execute "set <M-b>=\eb"
silent! execute "set <M-f>=\ef"

inoremap <expr> <M-b> <SID>WordPos('left') == 0
\ ? '<S-Left>'
\ : repeat('<C-G>U<Left>', col('.') - <SID>WordPos('left'))

inoremap <expr> <M-f> <SID>WordPos('right') == 0
\ ? '<S-Right>'
\ : repeat('<C-G>U<Right>', <SID>WordPos('right') - col('.'))

The goal is to move by words in insert mode with Alt-b, Alt-f without breaking the undo sequence.

It works more or less but if I try to type the character â, instead of inserting it, Vim triggers the mapping for Alt-b, which makes the cursor move one word backward.

As soon as I comment the mapping for Alt-b, the problem disappears. It happens in Vim as well as in gVim.

The output of the shell command xxd -p when I hit Alt-b is 1b62, and for â it's c3a2.

Why does Vim interpret â as Alt-b even though the keycodes seem different?

Answer 1

I think, traditionally (in the old times), pressing the Alt key meant setting the high-bit of the corresponding ascii char.

Therefore, <A-b> is the same as â in the terminal at least.

Terminal input handling is rather complicated and there exist many little knobs one can set, but IIRC until recently, there was no reliable way, to distinguish the Alt key presses from the highbit ascii chars. That might be different on Windows or in the Gui, I don't really know.

The Neovim project did change it and used the libtermkey library which can detect those difference and therefore fixed this annoyance. For Vim, however, as far as I know, there is no way around it and therefore, it is advised to not use the key for mapping, since this is not portable.

So in general, I tend to avoid using the Alt key in mappings.