Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Distribution terms
- X-seq: zsh-workers 2080
- From: "Greg J. Badros" <gjb@xxxxxxxxxxxxxxx>
- To: Bruce Stephens <stephens@xxxxxxxxxxx>
- Subject: Re: Distribution terms
- Date: Tue, 27 Aug 1996 13:04:09 -0400 (EDT)
- Cc: schaefer@xxxxxxx, zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <199608271537.RAA19912@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx
> (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@xxxxxxxxxxx
http://www.cs.duke.edu/~gjb
Messages sorted by:
Reverse Date,
Date,
Thread,
Author