From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3996 invoked from network); 7 Jan 2006 22:45:00 -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; 7 Jan 2006 22:45:00 -0000 Received: (qmail 96251 invoked from network); 7 Jan 2006 22:44:54 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 Jan 2006 22:44:54 -0000 Received: (qmail 10812 invoked by alias); 7 Jan 2006 22:44:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22138 Received: (qmail 10803 invoked from network); 7 Jan 2006 22:44:51 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 7 Jan 2006 22:44:51 -0000 Received: (qmail 95954 invoked from network); 7 Jan 2006 22:44:51 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO dot.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 7 Jan 2006 22:44:50 -0000 Received: by dot.blorf.net (Postfix, from userid 1000) id 286928E3D; Sat, 7 Jan 2006 14:44:47 -0800 (PST) Date: Sat, 7 Jan 2006 14:44:47 -0800 From: Wayne Davison To: zsh-workers@sunsite.dk Subject: Re: bug in completion/expansion of files with LANG=C Message-ID: <20060107224447.GA30232@dot.blorf.net> References: <20060106215829.GG10111@dot.blorf.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20060106215829.GG10111@dot.blorf.net> User-Agent: Mutt/1.5.11 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's a patch to fix the first part of having non-convertable characters found when completing filenames: we now output the full filename string instead of a truncated version of it. I chose to just call nicechar() to have it output a \M-x sequence (to make it the same as the non-multibyte code). However, I was wondering if it would be nicer to switch both the old and the new code over to using a 3-digit octal value in such output? E.g. output "\303" instead of "\M-C", and "\201" instead of "\M-^A"? ..wayne.. --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mb_niceformat.patch" --- Src/utils.c 15 Dec 2005 14:51:41 -0000 1.108 +++ Src/utils.c 7 Jan 2006 22:36:34 -0000 @@ -3475,22 +3475,21 @@ mb_niceformat(const char *s, FILE *strea if (ret == (size_t)-1 || ret == (size_t)-2) { + /* The byte didn't convert, so output it as a \M-x sequence. */ + fmt = nicechar(*(unsigned char*)ptr); + ret = newl = 1; + } else { /* - * We're a bit stuck here. I suppose we could - * just stick with \M-... for the individual bytes. + * careful in case converting NULL returned 0: NULLs are + * real characters for us. */ - break; + if (c == L'\0' && ret == 0) + ret = 1; + fmt = wcs_nicechar(c, &newl, NULL); } - /* - * careful in case converting NULL returned 0: NULLs are real - * characters for us. - */ - if (c == L'\0' && ret == 0) - ret = 1; + umlen -= ret; ptr += ret; - - fmt = wcs_nicechar(c, &newl, NULL); l += newl; if (stream) --fdj2RfSjLxBAspz7--