* Michael Schroeder <[EMAIL PROTECTED]> [2005-08-01 14:41 +0200]: > On Sun, Jul 31, 2005 at 10:26:18PM -0400, Raymond Page wrote: > > [xterm sets high bit for M-<char>, "extra characters are deposited on > > the command line"] > > Hmm, can anybody else reproduce this?
Yes. It looks like this a a bug (or something) in xterm. When xterm is not in UTF-8 mode, 'eightBitInput: true' and 'metaSendsEscape: false' cause M-<char> to generate <char> with the eighth bit set. When xterm is in UTF-8 mode with the same settings, it appears to treat those characters as Unicode and the program in the xterm gets UTF-8, so M-, generates 0xc2 0xac. screen then catches the 0xac from the bindkey but passes through the 0xc2. One workaround is to bind to the UTF-8 character sequence: bindkey \194\172 prev bindkey \194\174 next Note that you must not have the individual characters 0xac and 0xae bound. In my testing, if I had both '\194\172' and '\172' bound, the '\172' seemed to take precedence, and would pass the 0xc2 through. -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Pern What you get when you do Perl++ twice. Increment it only once, and your hair curls. Increment it three times, and you get a tasty beverage that isn't Java. -- _Programming Perl_, Glossary ---- --- -- _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
