From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27949 invoked from network); 28 Feb 2009 19:36:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 28 Feb 2009 19:36:25 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 94557 invoked from network); 28 Feb 2009 19:36:20 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 28 Feb 2009 19:36:20 -0000 Received: (qmail 14146 invoked by alias); 28 Feb 2009 19:36:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26637 Received: (qmail 14134 invoked from network); 28 Feb 2009 19:36:14 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 28 Feb 2009 19:36:14 -0000 Received: from mail-fx0-f171.google.com (mail-fx0-f171.google.com [209.85.220.171]) by bifrost.dotsrc.org (Postfix) with ESMTP id E53658058F83 for ; Sat, 28 Feb 2009 20:36:11 +0100 (CET) Received: by fxm19 with SMTP id 19so1510330fxm.45 for ; Sat, 28 Feb 2009 11:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=CYqe0/l+qa73jqh9MBHqeonqe40gUwORYJntR0J9Uak=; b=j1qecKFhgSREJH+JGHIhTqK70gRyF+v8aavaV2ttxo5gcMlzq9ls3Fk83Q0+xopgqZ TBwsFFBI6M9gJUJK6GPZRUlHpcXaF1301yQExAb0kZ+IEqrRCFgOih2EExbS9XAUh++j mF0HWCBmr5vVdGjC8A4A6J74V3zRQoveuAD7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=paR1WD3FQB/gQ5JioJKnyWqe5apjX0Ix5xNOumu1C0k1pjqzsYseCACE7i4XWcM5Ps m0wyEKX+Cft+XrysdIrWb1KYxsoa8pKlyEUMB+74UrrpEAQLW8mJIONjxOVzzrTJ+qBH c7i3yEEtDPTZM7uUWmqJ4JHUXjHBbYkIa/pYo= Received: by 10.181.146.11 with SMTP id y11mr1401414bkn.60.1235849759980; Sat, 28 Feb 2009 11:35:59 -0800 (PST) Received: from cooker.localnet (ppp91-77-192-41.pppoe.mtu-net.ru [91.77.192.41]) by mx.google.com with ESMTPS id d13sm11299311fka.0.2009.02.28.11.35.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Feb 2009 11:35:59 -0800 (PST) From: Andrey Borzenkov To: zsh-workers@sunsite.dk Subject: Re: Problems with non-ascii filenames Date: Sat, 28 Feb 2009 22:35:50 +0300 User-Agent: KMail/1.11.0 (Linux/2.6.29-rc6-1avb; KDE/4.2.0; i686; ; ) References: <19e566510902280137s3bb02510te650364cb03145a9@mail.gmail.com> <090228102250.ZM3434@torch.brasslantern.com> In-Reply-To: <090228102250.ZM3434@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8496743.rLsHrG7an3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902282235.52527.arvidjaar@gmail.com> X-Virus-Scanned: ClamAV 0.92.1/9057/Sat Feb 28 14:56:20 2009 on bifrost X-Virus-Status: Clean --nextPart8496743.rLsHrG7an3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2009 21:22:50 Bart Schaefe= r wrote: > On Feb 28, 11:37am, Ismail wrote: > } [~]> echo xo<0308>o<0308>o<0308>x > } x=C3=83=C3=83=C3=83x > } > } Somehow "=C3=83" character is replaced by <0308> while tab completing. [...] > Wolfgang, if you're reading this, something that I forgot to mention > in my reply to you is that sometime during 4.3.x zsh began to pay > closer attention to characters that are absent from the declared LANG > character set and to either refuse to process them at all, or to > render them as digits surrounded by angle brackets.=20 Unfortunately that does not play nicely with PRINTEIGHTBIT. Currently=20 manual states: PRINT_EIGHT_BIT Print eight bit characters literally in completion lists, etc. This option is not necessary if your system correctly returns the printability of eight bit characters (see man page ctype(3)). But PRINTEIGHTBIT affect only one function - (wcs_)niceputchar. Still=20 conversion to happens directly in zrefresh() if character deemed=20 to be unprintable *and* MULTIBYTE_SUPPORT is set. So either documentation must be fixed (by clearly mentioning that this=20 option has no effect if compiled with multibyte). This is bad IMHO as=20 average user is not supposed to know build options. Or code should be fixed. I am not exactly sure - is it correct that raw=20 character is stuffed into output buffer? Or are they all supposed to go=20 via niceputchar in the first place? --nextPart8496743.rLsHrG7an3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmpkhgACgkQR6LMutpd94zAJACfWoNbZWeBjYjma7Q8ETdIbUT8 ZqAAn3md3hpTcuOZFF6oPrEDHo/24Mfq =DYiT -----END PGP SIGNATURE----- --nextPart8496743.rLsHrG7an3--