From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20090 invoked from network); 7 Jan 2006 00:59:44 -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 00:59:44 -0000 Received: (qmail 14708 invoked from network); 7 Jan 2006 00:59:38 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 Jan 2006 00:59:38 -0000 Received: (qmail 25913 invoked by alias); 7 Jan 2006 00:59:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22131 Received: (qmail 25904 invoked from network); 7 Jan 2006 00:59:35 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 7 Jan 2006 00:59:35 -0000 Received: (qmail 14460 invoked from network); 7 Jan 2006 00:59:35 -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 00:59:33 -0000 Received: by dot.blorf.net (Postfix, from userid 1000) id 438A68E00; Fri, 6 Jan 2006 16:59:30 -0800 (PST) Date: Fri, 6 Jan 2006 16:59:30 -0800 From: Wayne Davison To: Peter Stephenson Cc: zsh-workers@sunsite.dk Subject: Re: bug in completion/expansion of files with LANG=C Message-ID: <20060107005930.GI10111@dot.blorf.net> References: <20060106215829.GG10111@dot.blorf.net> <20060106224019.38347e0e.p.w.stephenson@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106224019.38347e0e.p.w.stephenson@ntlworld.com> User-Agent: Mutt/1.5.11 On Fri, Jan 06, 2006 at 10:40:19PM +0000, Peter Stephenson wrote: > If we can't convert a multibyte character to a wchar_t we therefore > can't do anything with it. One thing we could do would be to transform an invalid value into a literal '?' -- that would at least match the filename, but it could be dangerous. Another thing we could do is to pick a legal wide-character value that would be used to indicate that the real value for this character was stored in a parallel (byte-sized) array. For instance, choosing the delete character would be one possibility (obviously making it necessary to turn a real \177 char into a \177 value in the parallel array). Yes, this would complicate the code a good bit, but I think we need to do something to make it possible for people to complete all filenames that may be on their system. > Second, and less difficult, it's quite a big change to have characters > in the command line displayed differently from the way they naturally > output. No, there's already a precedence for this: control characters. To handle this, zsh has a refresh string that is built up from the command- line string, and adding one extra rule to the code in zrefresh() that would make these invalid characters display as multiple physical characters would actually be pretty easy. > It would be quite helpful to have them with some terminal effect, too. That would certainly be nice, and could be used to make the display of literal control characters better. The simplest way to add it would probably be to extend the rparams structure to add some per-character flags that zrefresh() would set and refreshline() would obey. An alternate possibility would be to use the idiom "^123" to output the octal value of the invalid byte. (I chose '^' because it is already special for displaying control characters, and ctrl-digit values aren't already used to indicate anything.) ..wayne..