From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6317 invoked from network); 11 May 2007 17:26:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, MSGID_FROM_MTA_HEADER,UNPARSEABLE_RELAY autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 11 May 2007 17:26:22 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 39958 invoked from network); 11 May 2007 17:26:16 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 May 2007 17:26:16 -0000 Received: (qmail 23164 invoked by alias); 11 May 2007 17:26:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23430 Received: (qmail 23154 invoked from network); 11 May 2007 17:26:13 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 11 May 2007 17:26:13 -0000 Received: (qmail 39639 invoked from network); 11 May 2007 17:26:13 -0000 Received: from smtpout.mac.com (17.250.248.181) by a.mx.sunsite.dk with SMTP; 11 May 2007 17:26:09 -0000 Received: from webmail011 (webmail011-s [10.13.128.11]) by smtpout.mac.com (Xserve/smtpout11/MantshX 4.0) with ESMTP id l4BHPrVn000129; Fri, 11 May 2007 10:25:54 -0700 (PDT) Date: Fri, 11 May 2007 10:25:53 -0700 From: Jordan Breeding To: Peter Stephenson Cc: zsh-workers@sunsite.dk Message-ID: <2DF07A7A-0112-1000-87C3-08869130C191-Webmail-10013@mac.com> in-reply-to: <2DF07A7A-0112-1000-86BB-08869130C191-Webmail-10013@mac.com> references: <20070510175541.GA67479@redoubt.spodhuis.org> <20070510222647.GA45037@redoubt.spodhuis.org> <200705110928.l4B9Sobe019086@news01.csr.com> <2DF07A7A-0112-1000-86BB-08869130C191-Webmail-10013@mac.com> Subject: Re: problems with 4.3.4 and Tru64 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: 199.171.212.100 Received: from [199.171.212.100] from webmail.mac.com with HTTP; Fri, 11 May 2007 10:25:53 -0700 X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes On Friday, May 11, 2007, at 11:24AM, "Jordan Breeding" wrote: >On Friday, May 11, 2007, at 04:29AM, "Peter Stephenson" wrote: >>Phil Pennock wrote: >>> > > If these display fine, then multibyte is working and parts of zle are >>> > > working; the problem will be in input processing. If these don't >>> > > display, then the problem's not in the input processing. >>> > >>> > Touche, that works! >>> > >>> > Now, how to fix input processing?-) >> >>The fact they display doesn't tell you very much. You also need to >>check that once you've got them on the command line they behave like a >>single character. The easiest way is just to move the cursor and check >>it doesn't go to far (which it will if doesn't recognise the two bytes >>as a single character). >> >>If that's really working, input processing is quite involved to check. >>The key function for this is getrestchar() in Src/Zle/zle_main.c. This >>should recognise the first byte is an incomplete character and the >>second byte completes it. I don't think this an easy way to avoid >>debugging the insides. >> > > > >Hello, > >I have been following this thread as it interests me since I have had trouble getting multibyte to work the way I would expect on OS X. This thread inspired me to dig a little deeper since I can always see the characters, but with multibyte on echo/printf didn't seem to like the combined characters, and with multibyte off the line editor can't keep straight that it is one character. I will file a bug report with Apple to turn on multibyte in zsh now since in zsh 4.3.4 it seems to work fine. The other problems I was having were caused by preexec(). I had some print() statments in precmd() and preexec(). precmd() and chpwd() seem to have no effect on whether multibyte works or not, but this preexec(): > >preexec() { > print -Pn "\e]2;%n@%m %0~ (%30>...>${1}%>>%)\a" >} > >causes echo/print to misbehave. > >My test case was to do `echo hlp` where the combined character is either e or e: > >with the preexec enabled I get: >hlp > >as the output, without it it just echoes exactly what it should. So I think for the most part my problems are solved now. It would be nice to still be able to use preexec, but I assume that hopefully that bug can be fixed in the future. > >Jordan > > Sorry to reply to myself, but I just paid a little bit more attention and I figured out something else interesting. The extra characters that appear in the Terminal itself just before the output from echo are the multibyte characters only, which are missing from the ${1} being inserted into the Terminal title. This part seems to be OS X (Terminal.app) specific, as if I use zsh through a remote Terminal the behaviour will differ (putty will display hlp in the title which I am assuming are just the bytes that it is seeing). Anyway, I will probably just not use preexec() anymore for now. Is there are way to display multibyte characters as the base singlebyte character for the preexec string? Or possible just replace multibyte characters with "?" or something, just so my preexec would at least partially work? Thanks, Jordan