Re: [22076] PATCH: multibyte FAQ

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

Danek Duvall wrote:
> On Wed, Dec 14, 2005 at 06:31:03PM +0000, Peter Stephenson wrote:
> 
> > +    bindkey: warning: `bindkey -m' disables multibyte support
> 
> Noting that I haven't actually tried 4.3 yet, what happens to people who
> use bindkey -m to get all the M- bindings?  I use them all the time, and
> can't imagine not being able to use them.  Do you have to find new bindings
> for those widgets, or does M-whatever still work, but there's a new way of
> binding those keystrokes?

They still work.  We've managed to retain more or less complete
compatibility with the existing system by the following trick: eight bit
characters are bound to self-insert by default, but the code for
self-insert checks to see if there the input character is incomplete.
If it is, it waits for the rest (up to a delay of $KEYTIMEOUT hundredths
of a second).  If you rebind the character it won't act as self-insert,
but it will act exactly the way it always did.

The disadvantage is that you can't input multibyte characters via the
keyboard if they begin with the same meta sequence unless you bind the
more specific sequence starting with that byte (then the simple meta
binding works, but only after a delay of $KEYTIMEOUT).  However, if you
don't have those keys on your keyboard you probably don't care.  The
supplied widgets insert-composed-char and insert-unicode-char only read
ASCII characters, so aren't affected.

You can run
  bindkey -m 2>/dev/null
to silence the warning if you're happy about not having multibyte input.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page still at http://www.pwstephenson.fsnet.co.uk/