zsh-workers
 help / color / mirror / code / Atom feed
From: "Greg J. Badros" <gjb@moa.cs.duke.edu>
To: Bruce Stephens <stephens@math.ruu.nl>
Cc: schaefer@nbn.com, zsh-workers@math.gatech.edu
Subject: Re: Distribution terms
Date: Tue, 27 Aug 1996 13:04:09 -0400 (EDT)	[thread overview]
Message-ID: <Pine.SOL.3.93.960827124800.8505E-100000@moa.cs.duke.edu> (raw)
In-Reply-To: <199608271537.RAA19912@cantecler.math.ruu.nl>

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




  reply	other threads:[~1996-08-27 17:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-15 18:17 zsh-3.0.0 released Zoltan Hidvegi
1996-08-15 18:57 ` zsh-3.0.0 installed in the US Tom Kaczmarski
1996-08-16  4:18   ` Andrew Cosgriff
1996-08-16 11:55     ` Tom Kaczmarski
1996-08-20  1:32       ` Andrew Cosgriff
1996-08-20 12:55         ` Tom Kaczmarski
1996-08-15 19:56 ` zsh-3.0.0 released John Harres
1996-08-15 20:14   ` Richard Coleman
1996-08-15 20:27     ` John Harres
1996-08-15 21:22       ` Richard Coleman
1996-08-15 21:35       ` Wayne Davison
1996-08-27 14:25 ` Distribution terms Greg J. Badros
1996-08-27 15:28   ` Bart Schaefer
1996-08-27 15:37     ` Bruce Stephens
1996-08-27 17:04       ` Greg J. Badros [this message]
1996-08-27 18:58         ` Bart Schaefer
1996-08-27 19:04     ` Zefram
1996-08-27 19:25     ` Zoltan Hidvegi
1996-08-27 19:53       ` future of zsh Richard Coleman
1996-08-27 16:32         ` zsh: future and loadable modules Chip Salzenberg
1996-08-28  9:03           ` Bruce Stephens
1996-08-27 20:23         ` future of zsh Zoltan Hidvegi
1996-08-27 20:20       ` Distribution terms Zefram
1996-08-27 20:32         ` Zoltan Hidvegi
1996-08-27 16:37   ` Richard Coleman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SOL.3.93.960827124800.8505E-100000@moa.cs.duke.edu \
    --to=gjb@moa.cs.duke.edu \
    --cc=schaefer@nbn.com \
    --cc=stephens@math.ruu.nl \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).