From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3160 invoked from network); 21 Jan 2008 14:30:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 21 Jan 2008 14:30:11 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 80893 invoked from network); 21 Jan 2008 14:30:08 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 21 Jan 2008 14:30:08 -0000 Received: (qmail 8154 invoked by alias); 21 Jan 2008 14:30:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24417 Received: (qmail 8129 invoked from network); 21 Jan 2008 14:30:03 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 21 Jan 2008 14:30:03 -0000 Received: from virusfilter.dotsrc.org (bifrost [127.0.0.1]) by spamfilter.dotsrc.org (Postfix) with ESMTP id 2A6478058F58 for ; Mon, 21 Jan 2008 15:29:49 +0100 (CET) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by bifrost.dotsrc.org (Postfix) with ESMTP for ; Mon, 21 Jan 2008 15:29:48 +0100 (CET) Received: by rv-out-0910.google.com with SMTP id b22so1583166rvf.21 for ; Mon, 21 Jan 2008 06:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IvG4i/ebINx2O10jtT+xiKeaCbfBFoiG+mEHjLt3rq0=; b=yE41VjlJIjn4mDX1cwvgQmIuXJVoPClc4PgBJe1EnxYrHUmyWE+YB/yqy5QqFvBpdcGTf1VEn29VSpumGLIAXSXr5dcykomxRLyWeya/H4eL059HmRwcicI2RWdpizD/5uTpK0dTSLhnC9poZ5VU6S9IlpivtAZyrY1DkSCXAu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HBvEdrIpRb6NutCxIPNoURWatrc+UrXKtUoHRhOqBS1mufIK1KnyOt/ueHtbWX5lL45jfmUnQTN7my0lnlmzFldAO+hKj0NUlSqicROqwRiqAs16GluOdSNLgVCejyLbw2iPJkwNlwjtH/QSpdo5wbWisk73h5mk7VuEVDSWmw8= Received: by 10.141.50.17 with SMTP id c17mr4495695rvk.33.1200925788270; Mon, 21 Jan 2008 06:29:48 -0800 (PST) Received: by 10.140.127.7 with HTTP; Mon, 21 Jan 2008 06:29:48 -0800 (PST) Message-ID: <237967ef0801210629t201392a6h4d28fe80fcb5ab44@mail.gmail.com> Date: Mon, 21 Jan 2008 15:29:48 +0100 From: "Mikael Magnusson" To: zsh-workers@sunsite.dk Subject: Re: Unicode problem In-Reply-To: <200801211415.m0LEFbbU017355@news01.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080117120932.4458d35a@news01> <200801211415.m0LEFbbU017355@news01.csr.com> X-Virus-Scanned: ClamAV using ClamSMTP On 21/01/2008, Peter Stephenson wrote: > > The zero width character is drawn with width one? > > Yes, that's what gnome-terminal is doing. It seems to agree with the > screen width the library code is reporting (I didn't check explicitly > but the behaviour is consistent with that). > > I think there are actually two widths involved here: the screen width > used with a fixed-size font for editing (applicable to zsh), and the > logical width of the character that would appear in a document. The > latter is typically different to the former (in particular when a > variable width font is in use), and it's the latter case where it needs > to be zero width. There's a kind of hybrid case for a WYSIWYG word > processor where it needs to flag up the space for editing even though > pretending it's behaving as zero-width, but this is a special case of > variable-width fonts. The information in the library as returned by > wcwidth() is only applicable to fixed width fonts, where "zero width" is > essentially meaningless; a character width must be 1, 2, ... So I think > gnome-terminal is doing the right thing here, although I can understand > the confusion. Combining characters combine with the character(s) that come before them. So if you write an feff or 336 or whatever, they will combine. The terminal doesn't know where the prompt ends and the input line starts, so when you give it a space and a combining char, it will draw the combining char on top of the space before it. The combining char always has width 0 because nothing has moved from drawing it. The space with the combining char on top is of course width 1. If you write a double width space and then a combining char, it will similarily appear to have width 2. I guess what you want to do in zsh is just count them as width 0, and have the cursor skip over them, so if you are on the right of a<336> and press left you should end up to the left of a. If the user types one at the start of the line, i think you should _draw_ an extra space before it, but not insert the space into the actual commandline (because everything should work if a binary is named with a combining character first i think). Alternatively you could disallow it and have the user type out \u0336 instead (if that's the right syntax), or maybe autoconvert it? I don't know what do do with the zero width space though. :) -- Mikael Magnusson