zsh-workers
 help / color / mirror / code / Atom feed
From: "Oliver Kiddle" <okiddle@yahoo.co.uk>
To: Felix Rosencrantz <f_rosencrantz@yahoo.com>
Cc: zsh-workers@sunsite.dk
Subject: Re: Per command _redirect completion
Date: Mon, 25 Feb 2002 09:47:29 +0000 (GMT)	[thread overview]
Message-ID: <20020225094729.25283.qmail@web9303.mail.yahoo.com> (raw)
In-Reply-To: <20020225055948.43039.qmail@web10408.mail.yahoo.com>

 --- Felix Rosencrantz <f_rosencrantz@yahoo.com> wrote:
> Below is a proposed change for the _redirect completion function.  If
> there
> is a function with the name _redirect:COMMAND, that function is
> called
> to perform completion.  Otherwise, the default behavior of completing
> files
> is performed.  This is the way we do variable specific dispatch for
> _value.
> 
> If there are no objections, I'll create a real diff and checkin.

I would prefer if - both for redirection and for values - we had
separate associative arrays like _comps. And then, perhaps a compdef
option for adding to these new associations.

This is for a number of reasons, one being consistency with the way we
handle commands.

Many of the _value: functions just call one other function. It'd be
better if instead, for example we could specify in the #compdef on
_x_display to handle the $DISPLAY variable. Also, in many cases what
should be completed is already being done in another function. For
example, $GZIP should complete gzip options. It'd be more useful to
direct this into _gzip where gzip options are already completed and
_gzip would just need a compstate test. 

This redirection suggestion is even more linked to the command being
run and again it would be more useful to use the existing command's
completion function and have it work out what sort of files to
complete.

Oliver



__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


  parent reply	other threads:[~2002-02-25  9:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-25  5:59 Felix Rosencrantz
2002-02-25  8:18 ` Sven Wischnowsky
2002-02-25  9:47 ` Oliver Kiddle [this message]
2002-02-26  6:56   ` Felix Rosencrantz
2002-02-26  8:44     ` Sven Wischnowsky
2002-02-27  9:35       ` Sven Wischnowsky
2002-02-27 13:10         ` Oliver Kiddle
2002-02-27 14:30           ` Sven Wischnowsky
2002-02-28  6:35         ` Felix Rosencrantz
2002-02-28  8:42           ` Sven Wischnowsky
2002-03-01  5:47             ` Bart Schaefer
2002-03-04  8:50               ` Sven Wischnowsky
2002-03-01  9:24             ` Oliver Kiddle
2002-03-01 10:49               ` Sven Wischnowsky
2002-03-02 16:28 Felix Rosencrantz

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=20020225094729.25283.qmail@web9303.mail.yahoo.com \
    --to=okiddle@yahoo.co.uk \
    --cc=f_rosencrantz@yahoo.com \
    --cc=zsh-workers@sunsite.dk \
    /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).