[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Few feature requests

From: Phil!Gregory
Subject: Re: Few feature requests
Date: Mon, 1 Aug 2005 17:45:38 -0400
User-agent: Mutt/1.5.9i

* Michael Schroeder <address@hidden> [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?


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.

-- contrarian of the first order... /
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
  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
---- --- --

reply via email to

[Prev in Thread] Current Thread [Next in Thread]