From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11922 invoked from network); 29 Jun 2001 08:39:42 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Jun 2001 08:39:42 -0000 Received: (qmail 21368 invoked by alias); 29 Jun 2001 08:38:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15178 Received: (qmail 21356 invoked from network); 29 Jun 2001 08:38:50 -0000 From: Sven Wischnowsky Date: Fri, 29 Jun 2001 10:37:37 +0200 (MET DST) Message-Id: <200106290837.KAA04083@beta.informatik.hu-berlin.de> To: zsh-workers@sunsite.dk Subject: Re: Picky criticism of ls completion list formatting In-Reply-To: <1010629083338.ZM13900@candle.brasslantern.com> Bart Schaefer wrote: > On Jun 29, 9:13am, Sven Wischnowsky wrote: > } Subject: Re: Picky criticism of ls completion list formatting > } > } It's all as it should be, including this one: > } > } > With > } > > } > listpacked on > } > listtypes on > } > > } > I *still* get equally-sized columns with three spaces between. > > But I'm not really getting three spaces, am I. I'm getting two spaces > plus the one-character type-marker of a plain file, which happens to > also be a space. The code just isn't clever enough to strip that off > when the longest name in the column is that of a plain file. Yes. One of the things I had thought about trying to write several times but never came around to really trying. It's one of the things inherited from the times before I started hacking zsh (the fact that, as Alexandre said, the code doesn't store the type character with the matches or uses it in its calculations and that it use spaces instead of empty strings for normal files). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de