From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15407 invoked from network); 14 May 2003 19:55:43 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 14 May 2003 19:55:43 -0000 Received: (qmail 2038 invoked by alias); 14 May 2003 19:55:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18538 Received: (qmail 2027 invoked from network); 14 May 2003 19:55:37 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 14 May 2003 19:55:37 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [209.104.74.2] by sunsite.dk (MessageWall 1.0.8) with SMTP; 14 May 2003 19:55:36 -0000 Received: from OZoNE.TZoNE.ORG (vandry@localhost [127.0.0.1]) by OZoNE.TZoNE.ORG (8.12.3/8.12.3/Debian-5) with ESMTP id h4EJtZVx004933; Wed, 14 May 2003 15:55:35 -0400 Received: (from vandry@localhost) by OZoNE.TZoNE.ORG (8.12.3/8.12.3/Debian-5) id h4EJtZ7D004931; Wed, 14 May 2003 15:55:35 -0400 From: Phillip Vandry Date: Wed, 14 May 2003 15:55:34 -0400 To: Oliver Kiddle Cc: zsh-workers@sunsite.dk Subject: Re: Unicode support in Zle Message-ID: <20030514195534.GA4624@OZoNE.TZoNE.ORG> References: <20030429194325.GA843@OZoNE.TZoNE.ORG> <6134254DE87BD411908B00A0C99B044F05A0C904@mowd019a.mow.siemens.ru> <20030430204105.GA13631@OZoNE.TZoNE.ORG> <3342.1052302097@gmcs3.logica.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3342.1052302097@gmcs3.logica.co.uk> User-Agent: Mutt/1.3.28i On Wed, May 07, 2003 at 12:08:17PM +0200, Oliver Kiddle wrote: > The main advantage of the libc functions is that they work for other > multi-byte encodings than utf-8. They also do a lot of work for you but > don't let that stop you reproducing it if you want. You're right. Actually I believe I'm going to switch to the libc functions, with compatibility functions conditionally compiled if they're not available. > > - To enable the functionality to work on systems where Unicode is not > > handled at all in the system's libc & ascociated libraries. I still > > On the basis that such systems won't have utf-8 handling xterms, > filesystems or anything else, I'm sceptical about the value of that. I am almost always remotely logged in to such systems, with my xterm & fonts available on the local machine. So there is value. > Besides these comments, this all sounds very good. I look forward to > hearing about further progress. The biggest issue I've run into is [re]drawing the command line on the screen if wide characters are used. Zsh tries to use termcap tricks like deleting and inserting characters, but I found that different terminals react to these commands in different ways for wide characters. For example in xterm you need to delete two characters to delete a wide character. In mlterm deleting a single character if the cursor is on a wide character deletes it, and shifts the text by two cells. Currently I deal with this unpredictability by suppressing the delete character functionality if there are wide characters. I can't wait to find out how different terminals handle combining characters! -Phil