From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26 invoked from network); 15 Oct 2008 04:35:29 -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=0.0 required=5.0 tests=none 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; 15 Oct 2008 04:35:29 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 23523 invoked from network); 15 Oct 2008 04:35:12 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 15 Oct 2008 04:35:12 -0000 Received: (qmail 27673 invoked by alias); 15 Oct 2008 04:35:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25900 Received: (qmail 27639 invoked from network); 15 Oct 2008 04:34:59 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 15 Oct 2008 04:34:59 -0000 Received: from www890.sakura.ne.jp (www890.sakura.ne.jp [219.94.128.100]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 2C15E80524C0 for ; Wed, 15 Oct 2008 06:34:55 +0200 (CEST) Received: from [192.168.1.10] (pl240.nas932.p-gunma.nttpc.ne.jp [219.102.183.240]) (authenticated bits=0) by www890.sakura.ne.jp (8.13.6/8.13.6) with ESMTP id m9F4YlkS015064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 13:34:49 +0900 (JST) (envelope-from morita-pub-en-debian@inz.sakura.ne.jp) Message-ID: <48F572E7.3050600@inz.sakura.ne.jp> Date: Wed, 15 Oct 2008 13:34:47 +0900 From: Morita Sho User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: zsh-workers@sunsite.dk CC: 501851@bugs.debian.org Subject: =?UTF-8?B?UmU6IEJ1ZyM1MDE4NTE6IHpzaDogQ29tcGxldGlvbiBmYWlscyBpZiA=?= =?UTF-8?B?YSBkaXJlY3RvcnkgbmFtZSBjb250YWlucyAnKCcsICcpJyBhbmQgJ8SEICcu?= References: <20081010230611.23133.42221.reportbug@debian> <20081010231712.GA20915@scru.org> <48F0AE88.1020307@inz.sakura.ne.jp> <20081011225255.0df2e350@pws-pc> <48F2A515.1030203@inz.sakura.ne.jp> <2d460de70810122325r7e576759t204653bd537006b5@mail.gmail.com> <48F3F9F5.1040009@inz.sakura.ne.jp> <20081014130445.73a7033d@news01> In-Reply-To: <20081014130445.73a7033d@news01> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.92.1/8426/Wed Oct 15 02:11:44 2008 on bifrost X-Virus-Status: Clean On 10/14/2008 09:04 PM, Peter Stephenson wrote: > Until then you should be able to get away with the old syntax, > > zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}' > > since before I finish the job it won't actually handle non-ASCII character > conversions properly anyway. Thanks for detailed explanation! But I'm still confusing. Even with the old syntax, the completion Ą/[TAB] won't work. As far as I understand, the following configuration should fix the completion problem, but it won't. % cat ~/.zshrc # Lines configured by zsh-newuser-install HISTFILE=~/.histfile HISTSIZE=1000 SAVEHIST=1000 bindkey -e # End of lines configured by zsh-newuser-install # The following lines were added by compinstall #zstyle ':completion:*' matcher-list 'm:{[:lower:]}={[:upper:]}' zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}' zstyle :compinstall filename '/home/qw/.zshrc' autoload -Uz compinit compinit # End of lines added by compinstall BTW, to find out why replacing _path_files with the old one solves the problem for me, I put a debug output into _path_files as below to watch the value of $tmp1 before the $~tmp1 expansion. print "DEBUG: LINENO=$LINENO tmp1=$tmp1" > /dev/stderr tmp1=( $~tmp1 ) 2> /dev/null When I type Ą/[TAB], I got this debug output. DEBUG: LINENO=400 tmp1=ă�*(-/) DEBUG: LINENO=400 tmp1=ă�*(-/) Afterward, I replaced _path_files with the old one (which is from zsh 4.3.6), and put the same debug output, then I got this debug output. DEBUG: LINENO=372 tmp1=ă�*(-/) DEBUG: LINENO=372 tmp1=Ą/* It seems that tmp1 has a invalid (meta-encoded?) character. In _path_files which is from zsh 4.3.6, they seems to retry with a normal (non-meta-encoded?) character. Unfortunately, I couldn't understand why they are differ.... -- Morita Sho