Vim Tips Wiki
Register
(added fix for urxvt)
(→‎Comments: Alt, 8-bit, 'termencoding', etc.)
Line 69: Line 69:
   
 
''sebastian''
 
''sebastian''
  +
: "Cryptic characters" for Alt+printable keys are not a bug, it's a known and documented behaviour. Since Vim represents the Alt key as the high bit, it cannot tell the difference between an ASCII key with Alt (let's say Alt-a, where a, lowercase-a-for-alfa, has the ASCII value 0x61) and the high-bit counterpart of that key (in this case the character with value 0xE1, which in Latin1 or UTF-8 is á i.e. small-a-acute). This may mean an easy way to type accented characters in Insert mode even if you only have a en-US QWERTY keyboard with no accents on it, but usually it means that you should refrain from using Alt+printable keys as {{help|{lhs}|prefix=no}} of an Insert- or Command-line-mode mapping if you want to be able to type accented letters (in Normal mode it's usually OK since accented letters have no default bindings in that mode... but read further). OTOH, of course, if your OS's "national settings" ($LC_CTYPE) say that your "character set" is neither Western nor Unicode, Vim will see that and do the appropriate conversion for that $LC_CTYPE (which is the right thing to do for Insert mode) and (if 'encoding' is set internally to UTF-8) the Alt-key mappings will get skewed, which is another reason to stay away from Alt+printable key combinations in Vim.
  +
: As for {{help|prefix=no|'termencoding'}}, by default it is empty, which means "use {{help|prefix=no|'encoding'}} which is set at startup to your OS-defined locale. On Windows 'termencoding' doesn't matter because Vim always asks for the Unicode version of anything you type, but on other OSes it is crucial to save the "old" 'encoding' setting in 'termencoding' before you change 'encoding' — for instance before you set it to UTF-8 if it was initially something else. If you don't, the OS will send you characters in the unchanged locale and Vim will interpret them as UTF-8; conversely, Vim will send UTF-8 for display on the console and the OS will interpret it in your $LC_CTYPE locale — and in both cases, the result will be gibberish. For more details on this kind of stuff, see [[Working with Unicode]]. — [[User:Tonymec|Tonymec]] 17:11, March 6, 2010 (UTC)

Revision as of 17:11, 6 March 2010

Tip 1129 Printable Monobook Previous Next

created February 12, 2006 · complexity basic · author Matt Zyzik · version 5.7


Xterm, by default, sets eightBitInput to true, meaning that the eighth bit is set for meta characters (combinations with the Alt key, for instance). Not all terminals have this feature enabled by default, and therefore work differently (they send an Esc before the character key).

So for the xterm, with enables the eight bit, you can just do something like:

map <m-a> ggVG

However, with a terminal that is in 7 bit mode, you have to do this:

set <m-a> = ^[a
map <m-a> ggVG
" the ^[ is an Esc char that comes before the 'a'

My tip is to just set all terminals to work in 8 bit mode. Here are two examples:

Eterm -8
rxvt --meta8

See also

Comments

Also, these are the settings I use in my /etc/inputrc:

set meta-flag on
set input-meta on
set convert-meta on
set output-meta on

These are so that alt keys like <m-b>, <m-f>, <m-d> will work well in shell.


The only version that works for me (Vim 7.1 on Ubuntu 8.04 x86, connected to by Putty 0.60 on Windows XP 32bit):

Line in .vimrc to map for example "Alt-RightArrowKey" to "switch to next open file":

:map ^[<Right> :hide bn<CR>

Crucial: to get the ^[<Right> press in insert mode Control-V then Alt-x, remove the x, insert the seven Characters "<Right>".

See :help key-notation for more key special names like "<Right>".

klaus thorn


Using urxvt (rxvt-unicode) with --meta8 the alt key combinations gave cryptic characters (mostly with accents, like ì) as output instead of the Alt key mapping. Solution:

set termencoding=latin1

I guess the "set-8-bit" thing originates from the non-unicode version and only works for latin1. Input of special chars works as before.

sebastian

"Cryptic characters" for Alt+printable keys are not a bug, it's a known and documented behaviour. Since Vim represents the Alt key as the high bit, it cannot tell the difference between an ASCII key with Alt (let's say Alt-a, where a, lowercase-a-for-alfa, has the ASCII value 0x61) and the high-bit counterpart of that key (in this case the character with value 0xE1, which in Latin1 or UTF-8 is á i.e. small-a-acute). This may mean an easy way to type accented characters in Insert mode even if you only have a en-US QWERTY keyboard with no accents on it, but usually it means that you should refrain from using Alt+printable keys as {lhs} of an Insert- or Command-line-mode mapping if you want to be able to type accented letters (in Normal mode it's usually OK since accented letters have no default bindings in that mode... but read further). OTOH, of course, if your OS's "national settings" ($LC_CTYPE) say that your "character set" is neither Western nor Unicode, Vim will see that and do the appropriate conversion for that $LC_CTYPE (which is the right thing to do for Insert mode) and (if 'encoding' is set internally to UTF-8) the Alt-key mappings will get skewed, which is another reason to stay away from Alt+printable key combinations in Vim.
As for 'termencoding', by default it is empty, which means "use 'encoding' which is set at startup to your OS-defined locale. On Windows 'termencoding' doesn't matter because Vim always asks for the Unicode version of anything you type, but on other OSes it is crucial to save the "old" 'encoding' setting in 'termencoding' before you change 'encoding' — for instance before you set it to UTF-8 if it was initially something else. If you don't, the OS will send you characters in the unchanged locale and Vim will interpret them as UTF-8; conversely, Vim will send UTF-8 for display on the console and the OS will interpret it in your $LC_CTYPE locale — and in both cases, the result will be gibberish. For more details on this kind of stuff, see Working with Unicode. — Tonymec 17:11, March 6, 2010 (UTC)