From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24166 invoked from network); 14 Dec 2005 21:09:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Dec 2005 21:09:58 -0000 Received: (qmail 66553 invoked from network); 14 Dec 2005 21:09:50 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Dec 2005 21:09:49 -0000 Received: (qmail 7285 invoked by alias); 14 Dec 2005 21:09:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22080 Received: (qmail 7275 invoked from network); 14 Dec 2005 21:09:46 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 14 Dec 2005 21:09:46 -0000 Received: (qmail 66283 invoked from network); 14 Dec 2005 21:09:46 -0000 Received: from mta09-winn.ispmail.ntl.com (81.103.221.49) by a.mx.sunsite.dk with SMTP; 14 Dec 2005 21:09:45 -0000 Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20051214210944.FYJK8609.mta09-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com> for ; Wed, 14 Dec 2005 21:09:44 +0000 Received: from pwslaptop.csr.com ([81.105.238.64]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20051214210944.IOSQ1233.aamta09-winn.ispmail.ntl.com@pwslaptop.csr.com> for ; Wed, 14 Dec 2005 21:09:44 +0000 Received: from pwslaptop.csr.com (pwslaptop.csr.com [127.0.0.1]) by pwslaptop.csr.com (8.13.4/8.13.4) with ESMTP id jBEL9Udv003598 for ; Wed, 14 Dec 2005 21:09:30 GMT Received: from pwslaptop.csr.com (pws@localhost) by pwslaptop.csr.com (8.13.4/8.13.4/Submit) with ESMTP id jBEL9S5v003595 for ; Wed, 14 Dec 2005 21:09:30 GMT Message-Id: <200512142109.jBEL9S5v003595@pwslaptop.csr.com> X-Authentication-Warning: pwslaptop.csr.com: pws owned process doing -bs From: Peter Stephenson To: Zsh hackers list Subject: Re: [22076] PATCH: multibyte FAQ In-Reply-To: Message from Danek Duvall of "Wed, 14 Dec 2005 11:25:39 PST." <20051214192539.GE3640@lorien.comfychair.org> Date: Wed, 14 Dec 2005 21:09:28 +0000 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 Web page still at http://www.pwstephenson.fsnet.co.uk/