From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1952 invoked from network); 8 Mar 2002 12:55:41 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 8 Mar 2002 12:55:41 -0000 Received: (qmail 4035 invoked by alias); 8 Mar 2002 12:55:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16782 Received: (qmail 4022 invoked from network); 8 Mar 2002 12:55:33 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.46201.219885.149096@wischnow.berkom.de> Date: Fri, 8 Mar 2002 13:54:17 +0100 To: zsh-workers@sunsite.dk Subject: Re: Redirection completion In-Reply-To: <21013.1015590794@csr.com> References: <21013.1015590794@csr.com> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid Peter Stephenson wrote: > ... > > Is the patch at the end useful? I got caught out because I originally > defined a completion for a non-existent type `redir'. The list of types > appears to be closed --- i.e. you can't add your own because they're > handled internally --- in which case it's safe to test the type. Yes and no. In its last incarnation, the types are completely defined by the functions making use of them. compinit/compdef collects them from the -T options it gets. So, for the time being, the patch below is (almost) fine. I was thinking about people who might want to stuff calls to compdef into the startup files and later (somehow) make the functions known that use those completion types. Maybe that's not really an issue, my brain was getting pretty fuzzy at that time. Anyway, `almost' because compdef updates the array _comp_assocs to contain all completion type names it knows about, so the patch should use that. > Next, it looks like the context for redirections isn't all that helpful > at the moment. After `echo 2>' I seem to get just > `:completion::complete:echo::'. Could we have something like the way > arguments work, so that it at least indicates we're in a redirection, > and preferably also the `2>' bit? Along the lines of > :completion::complete:dvips:option-o-1: > I would suggest > :completion::complete:echo:redir-2>:' > for `echo 2>'. Hm, yes. The strings given to _dispatch are currently only used for lookup-as-in-command-name-lookup, not for context name lookup. And for redirections we use `command:op', so you can do e.g.: compdef '_files -g "*.log"' -T redirs 'echo:2>' compdef '_files -g "*.log"' -T redirs 'echo:2>|' This should also work with pattern-completions... but not with a line like the ones above, because _dispatch doesn't use eval for pattern completions. I've overlooked that and will produce a patch till next week, together with a patch for: I wasn't sure about using a colon to separate the command name from the redirection operator anyway, but I simply forgot to stuff the information into the context string. That's a good idea, I'll do that and put the fix with the missing `eval's into the same patch (should I also include the change to make compdef() use _comp_assocs? saving you some time?) > ... > > This always prefers log files, and it would probably be nicer to use > _alternative. But then I need a tag order to make sure they don't all > get shown at once, and for that I need a context. At least, I think. > Thinking some more, I could probably do all this more easily with > file-patterns, but that definitely requires more specific context > information.) Right. > By the way, I think I'm going to expand the user guide to include more > recipe-style information. If anyone wants to send me a list of stuff > that can be done that's not described at the moment (see > http://zsh.sunsite.dk/Guide/zshguide06.html) I'll add it. Sounds good, no ideas yet, will try to think of some... Bye Sven -- Sven Wischnowsky wischnow@berkom.de