From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id DAA01791 for ; Wed, 28 Aug 1996 03:08:39 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id NAA22905; Tue, 27 Aug 1996 13:07:32 -0400 (EDT) Resent-Date: Tue, 27 Aug 1996 13:07:32 -0400 (EDT) Date: Tue, 27 Aug 1996 13:04:09 -0400 (EDT) From: "Greg J. Badros" To: Bruce Stephens Cc: schaefer@nbn.com, zsh-workers@math.gatech.edu Subject: Re: Distribution terms In-Reply-To: <199608271537.RAA19912@cantecler.math.ruu.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"nm4fW.0.pb5.Jjo8o"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2080 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Tue, 27 Aug 1996, Bruce Stephens wrote: > > Before you go through that hassle, perhaps we should have (a) a statement > > from Zoltan on whether he thinks the patches are worth including in the > > first place, and (b) a discussion on zsh-workers about that statement. Agreed, but I believe in doing things in parallel, especially when it's not that much trouble. Peter Anvin, author of the patch, has no problem with its being used in Zsh. I'm still waiting for word from RMS as the FSF says the copyright has been assigned to them. > In their present state, they shouldn't be added, but if cleaned up so > they're independent of list_types, I don't see why not. list_types They are now-- see http://www.cs.duke.edu/~gjb/patches/Zsh3-ColorPostPrompt.patch Of course, there are several other things in this patch, including my PostPrompt mechanism (nobody has said anything about that? Anybody like this idea?), a lame (commented out) attempt at dynamic abbreviation completion, and some word movement zle fns. > suggests that there's some equivalence between listing files for > completion and listing files generally, so perhaps a better solution > (which wouldn't involve much extra code) would be to allow users to > execute a command on lists of completions, so I could just pass it to > ls. Does anybody see anything wrong with that? (Potentially, one > could then get rid of list_types in favour of the user providing "ls > -F", but there are obvious speed problems with that.) To me, the colorized completion in a shell is where the color-ls patch has always belonged. *Interactive* use is what the color-ls patch is for, and that is what a lot of the features of zsh are about. Launching an external command is slow, like you said, and makes zsh more dependent on other software. > > > I, for one, find this to be complete fluff and would just as soon skip it. > > It's certainly fluff, but I think it's quite pretty. I'd just as soon > do it differently, though: I'd be happy for zsh to use an external ls. > Or, one day, when we have dynamic loading in zsh like ksh93, perhaps a > dynamically loaded ls function that I've extracted from fileutils. > -- > Bruce Stephens | email: B.Stephens@math.ruu.nl > (rest of sig deleted) I even question whether it's totally fluff. One especially useful feature is the colorizing of orphaned symlinks-- true color_ls will do this too, but I look at directories as much, if not more, from the completionn menu as from a ls process. This lets me notice problems with my file system early. Even if it is fluff, it's pretty useful fluff, and it's a hard line to draw to stop featuritis, while adding good features. Greg J. Badros gjb@cs.duke.edu http://www.cs.duke.edu/~gjb