From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11742 invoked from network); 20 Jul 1999 07:53:49 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Jul 1999 07:53:49 -0000 Received: (qmail 19419 invoked by alias); 20 Jul 1999 07:53:30 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2454 Received: (qmail 19412 invoked from network); 20 Jul 1999 07:53:29 -0000 Date: Tue, 20 Jul 1999 09:53:25 +0200 (MET DST) Message-Id: <199907200753.JAA00773@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-users@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 19 Jul 1999 23:59:57 +0000 Subject: Re: Inserting all completions Bart Schaefer wrote: > On Jul 19, 4:03pm, Danek Duvall wrote: > > > > Hmmm, okay ... I don't want to replace completion with this entirely. I'd > > like to have two keystrokes -- one, tab, is the normal completion > > mechanism. The second, ^X^I or something, puts all the matches on the > > line. > > Just change the "compdef" in my previous example to: > > compdef -k _all expand-or-complete '^X^I' > > This creates a binding that acts like expand-or-complete but that calls > the function _all to generate the matches. > > > The question then is, how to write function_to_compute_reply() in a > > suitably generic manner ... > > Hmm. The existing Completions/*/* functions would be ideal for this, if > there were some way to refer to "all the matches that have already been > added by some other completer." Unfortunately I've forgotten whether > there is, and I can't find anything about it in the docs ... Sven? I hadn't thought about this use, but I once suggested a way to access the data for the matches already added. Hm, I see two possibilities: 1) a way to get at the strings for the matches added 2) some more magic with compstate[insert] Unfortunately 1) is not trivial: - we really have the information about the matches only *after* the completion widget finished, because then the code that sorts the matches and eliminates duplicates is run; changing that would make adding matches much more expensive (checking for duplicates after each added match) - the completion-inside-braces-problem: if we have a{b, the matches are abx, aby, and so on and only the match-insertion code really knows where to re-insert the brace(s) correctly Because of these two problems I haven't implemented something like that yet. The 2) is something I only thought about now. That wouldn't be too hard, I think. We could make compstate[insert] accept a comma- separated list of ranges or something like that (a la cut), e.g.: `compstate[insert]=1-' would insert all matches, and something like `compstate[insert]=1,3,5-10' would insert the first, third, and fifth-to-tenth match (in that order). We could also try to combine 1) and 2), i.e. a way to get at the match-strings plus `compstate[insert]="($foo $bar)"' -- but that wouldn't work with the braces-stuff. Comments? Opinions? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de