From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17843 invoked from network); 20 Jul 1999 17:39:40 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Jul 1999 17:39:40 -0000 Received: (qmail 1536 invoked by alias); 20 Jul 1999 17:39:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7227 Received: (qmail 1529 invoked from network); 20 Jul 1999 17:39:29 -0000 From: "Bart Schaefer" Message-Id: <990720173925.ZM5289@candle.brasslantern.com> Date: Tue, 20 Jul 1999 17:39:25 +0000 In-Reply-To: <199907200753.JAA00773@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Inserting all completions" (Jul 20, 9:53am) References: <199907200753.JAA00773@beta.informatik.hu-berlin.de> <9907201232.AA24396@ibmth.df.unipi.it> In-Reply-To: <9907201232.AA24396@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: Inserting all completions" (Jul 20, 2:32pm) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Inserting all completions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii (I've dropped zsh-users from the discussion, it's getting pretty thick.) On Jul 20, 9:53am, Sven Wischnowsky wrote: } Subject: Re: Inserting all completions } } > > 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." } } 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 That may not be as much of a problem as you think. The interface for getting at the previous matches can be exactly like "compadd -A array" except that the source is the existing list of potential matches rather than the command line arguments; the only side-effect would be that the matches copied into the array would be removed at that time from the internal list. Perhaps an option "G" (for "get") that's combined with -O or -A: compadd -GA [-J group] array compadd -GO [-J group] array Copies the internal list of completions not yet added to the command line into the named array and erases the internal list (as if no completions had ever been added). The completions must be re-added later, for example with "compadd $array", in order to be considered as matches. If -J group is given, only the matches from the named group are retrieved. If "compadd -[AO]" isn't performing the sorting/matching, document that, thus effectively punting it to the later "compadd". The problem I see is that this would dissipate the cloud of other data that surrounds each match, such as whether it should be added with -U or -Q, the -X strings, etc. But maybe that's OK, as there can't be very many reasons that a function wants to intercept all the matches added "ahead of" it. } - 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 I'm not sure how that one interacts with the above suggestion. } 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). That's a nice idea, but one still needs a way to find out what the first, third, and fifth etc. matches *are* in order to decide whether to insert them. Otherwise it might as well be an all-or-nothing thing. Maybe all-or-nothing is actually sufficient; what about simply: compstate[insert]=expand Which would act much like the _expand completer with only expand_glob. Thinking about this, however, makes me notice that it's always dangerous to "chain" completers together when any of them use compstate[], because there's no way to tell (a) whether the input state is from the completion system or is the output state of some previous completer, nor (b) whether changing the state is going to garble the results from some previous completer. In that sense, actually destroying the previous completer's data with my suggested "compadd -G" might be preferable ... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com