From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11084 invoked from network); 10 Dec 2006 21:37:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.7 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 10 Dec 2006 21:37:24 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 15345 invoked from network); 10 Dec 2006 21:37:18 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 10 Dec 2006 21:37:18 -0000 Received: (qmail 11797 invoked by alias); 10 Dec 2006 21:37:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23043 Received: (qmail 11787 invoked from network); 10 Dec 2006 21:37:14 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 10 Dec 2006 21:37:14 -0000 Received: (qmail 15030 invoked from network); 10 Dec 2006 21:37:13 -0000 Received: from vms040pub.verizon.net (206.46.252.40) by a.mx.sunsite.dk with SMTP; 10 Dec 2006 21:37:10 -0000 Received: from torch.brasslantern.com ([71.116.86.88]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JA200HLZUPOEJBB@vms040.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 10 Dec 2006 15:37:01 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id kBALaxZn016591; Sun, 10 Dec 2006 13:37:00 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id kBALax67016590; Sun, 10 Dec 2006 13:36:59 -0800 Date: Sun, 10 Dec 2006 13:36:59 -0800 From: Bart Schaefer Subject: Re: Multibyte input and Mac OS X In-reply-to: <158B7B75-EE3A-4986-AB99-FD374043ECD9@mac.com> To: Jordan Breeding , zsh-workers@sunsite.dk Message-id: <061210133659.ZM16587@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable References: <158B7B75-EE3A-4986-AB99-FD374043ECD9@mac.com> Comments: In reply to Jordan Breeding "Multibyte input and Mac OS X" (Dec 10, 1:27am) On Dec 10, 1:27am, Jordan Breeding wrote: } } If I use "--enable-multibyte" then everything works great for editing } but zsh seems to be grabbing characters at such a low level that my OS } native keyboard entry method doesn't work. There's nothing different about the "level" at which zsh "grabs" characters that is dependent on compiling with multibyte or not. The only difference is that, with --enable-multibyte, if zsh sees a character that is the beginning of a valid multibyte sequence, it continues reading characters until it has consumed up to the end of the valid multibyte sequence, then treats the whole result as one character. With --disable-multibyte, it reads one byte at a time and each byte is treated as one character. As far as I can tell, this is exactly what readline-5.1 (the editing library used by bash) does as well. There's a non-zero probability that Apple has modified readline to behave differently under MacOS X, which would be an advantage that zsh does not have. } Is there a way to get just the multibyte display and editing=20=20 } (arrowing, deleting, etc.) of multibyte characters, but to bypass the=20= =20 } new zsh entry method and just let me use my OS entry method? There is no new zsh entry method. It's the same old entry method that it always has been; all that has changed is how it handles the bytes after they've already been entered. So no, there isn't. I haven't had a chance yet to check on MacOS, but the only difference=20 on linux between the tty input settings for bash and zsh is that bash turns off both input and output conversions of newline/carriage-return, whereas zsh leaves both conversions on. } Oh yeah, I tried what several people suggested before about zle and=20=20 } mapping keys, unfortunately the OS isn't sending the raw keys for the=20= =20 } keys I am trying to send I think you may have misunderstood. I wasn't suggesting that you bind the raw keys -- I was suggesting that you bind whatever it is that the OS really sends. } Using the real input method for my keyboard layout (option-6 then e } for =EA) would be the best solution in my opinion. Try this: Start zsh -f. Type control-v to begin a literal input. Type option-6. If you see anything appear, make a note of it. Type e. What do you see displayed at this point? If something was displayed when you typed option-6, then the "real input method" sends a byte when option-6 is pressed and expects the program underneath to know to behave the way zsh does on insert-composed-char. If nothing was displayed until you typed "e", then whatever *was* displayed is a clue to what you need to bind. Try the experiment again except run "bindkey -m" immediately after starting zsh -f, so that the multibyte translation is disabled. Both with and without bindkey -m, let us know what you find.