From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22780 invoked from network); 12 Mar 2002 09:04:40 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 12 Mar 2002 09:04:40 -0000 Received: (qmail 24828 invoked by alias); 12 Mar 2002 09:04:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16812 Received: (qmail 24816 invoked from network); 12 Mar 2002 09:04:34 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15501.50297.139401.277883@wischnow.berkom.de> Date: Tue, 12 Mar 2002 10:03:53 +0100 To: zsh-workers@sunsite.dk Subject: Re: Redirection completion In-Reply-To: <1020311165607.ZM27129@candle.brasslantern.com> References: <15500.37377.808155.293654@wischnow.berkom.de> <19534.1015846146@csr.com> <15500.40522.132670.814408@wischnow.berkom.de> <1020311165607.ZM27129@candle.brasslantern.com> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid [I'm withholding the patch for now...] Many questions from Bart: > ... > > Firstly I'd like to keep the "flavor" of redirection tightly associated > with the word `redirect', i.e. rather than > > -redirect-echo-2> > > It should be > > -redirect-2>-echo That's ok, I think. What do you suggest for values, then? `-value---'? is the parameter name, is scalar/array/... and is only set when completing after something like `make FOO='. That, by the way, is the reason why I put the command directly after the `-value-' or `-redirect-': it can be there in both cases. > Then, I think, it would not be necessary to try each of `-redirect-', > `-redirect-2>', and `-redirect-2>-echo' in turn, because styles could be > written easily with wildcards e.g. `-redirect-*' or `-redirect-2>*'. > > Unless I'm missing something about why all three are tried? Yes. The main reason for this is that I want it to be easy to define functions (not styles) for types of redirections or for parameters without having to use `compdef -[pP]' everywhere. > This points up the second change I'd like to request: Make this style > fragment work the same way that styles in general work, e.g., define a > fixed set of delimiter-separated segments and have them always be there > even if sometimes empty. E.g. supposing we switched to comma as the > delimiter, as Sven tossed out in one of the earlier messages on this > thread, the context would look like `-redirect-,2>,echo' and if for some > reason the command name were not known it would be `-redirect-,2>,'. I've actually been thinking the same (before that idea with the comma). I'd prefer a solution where the different can have at least almost the same meaning in every case, though (i.e. values and parameters for now). Just as we did with full context names. > I suppose strictly speaking the first of those commas could be omitted > because we must always know what redirection operator we're dealing with > (else we wouldn't be in -redirect- context at all), e.g. `-redirect-2>,'. If we go this way, I'd be in favour of putting it there -- it might also make the description in the docs easier (`some functions redispatch and modify the context name to show this, leaving the base name of the command/context field and appending to it the more precise description, separated by commas'). > Random additional comments: > > If we do stick with hyphens, what does the context look like in the case > of completion after: > > zsh% - 2> > > (It's perfectly legal syntax to put the redirection anywhere on the line, > even before the command for which the precommand modifier is intended.) Since completion for redirection is determined on the same lave as _precommand would be found, you should (haven't tried) currently get `-' in the command part. Hrm, that's ugly, obviously, because you would get the same for `- foo > '. We've got to thnk some more about this... > If we instead switch to commas, what do we do in case of a command named > `,'? (I knew people in grad school who used a csh script named that, for > reasons too obscure to go into). On a similar note, do we need to fix > somehow the existing contexts for completing after the `:' command? Hrm. We could quote the separation character if it appears inside the command name. > Different tack: If I have > > zsh% ls > > > with the cursor positioned ON the `>', what context(s) get tried when I > press TAB? I might expect it to complete file descriptor numbers ... > and in that case, I'd want to complete only the numbers of *valid* file > descriptors, but those aren't available to shell functions (yet). Yes that would be nice. Currently you should get argument completion (but strangely, trying `echo >' shows that `-command-' is tried, only after `echo foo >' do we get argument completion -- I'll have to have a look). Bye Sven -- Sven Wischnowsky wischnow@berkom.de