From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21294 invoked from network); 11 Oct 1999 11:12:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Oct 1999 11:12:15 -0000 Received: (qmail 22392 invoked by alias); 11 Oct 1999 11:12:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8201 Received: (qmail 22385 invoked from network); 11 Oct 1999 11:12:04 -0000 Date: Mon, 11 Oct 1999 13:12:02 +0200 (MET DST) Message-Id: <199910111112.NAA02526@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Adam Spiers's message of Sat, 25 Sep 1999 15:45:41 +0100 Subject: Re: PATCH and Re: simulation of dabbrev-expand [ Trying to reduce the number of replies by answering multiple messages... ] Adam Spiers wrote: > > Although... we could do it whenever someone > > looks at `compstate[*nmatches]', set a flag if the list is sorted and > > clear the flag when another match is added. Hm. No time now... > > Sounds reasonable, but still feels (IMO) a bit of a workaround forced by the > wrong design decision. Maybe there's no good solution. *shrug* First, the `design decision' comes from a time when one couldn't execute shell code (and look at the current state) during completion. Then, I think it is still right to execute the probably expansive sorting and uniquifying as seldom as possible -- and in most cases this is really only needed at the end. But I after thinking some more about this, I really think, the solution to do the calculation when one of the `nmatches' keys is used is ok. Normally we do this at the very beginning (so there are no matches and this doesn't take any time) and at the end (and then we still do the work only once because the stuff calculated when `compstate[nmatches]' was used at the end). This could also be combined with... Benjamin Korvemaker wrote: > 2) When there are too many completions, and a prompt like > > zsh: do you wish to see all 102 possibilities? > > shows up, can I simply get it to: > a) not prompt, > b) not list, and > c) maybe say "**lotsa completions - not listing**" > > Thanks for the help! ...by adding a key, say `list_lines' or whatever which would allow us to write shell code that can find out if the listing code would ask (well, of course we could also check this in C and have a key saying whether it would ask, but that check is easy and knowing the number of lines may be intersting anyway, maybe, hm...). Anyway, with the relatively new `calclist()' this would be quite easy to implement (heck, we could give many different types of information about the list). Adam Spiers wrote: > d) list the completion groups and the number of matches in each, > and then let you choose which group to complete from. > > Selecting completion groups would be a nice feature in any case. > > I might have a go at hacking some of these, but will probably fail and > have to wait for Sven to get back. I'm away this w/e myself, however. This is something I want to achieve (see 12241, at least if I understand you correctly) with the grouping anhancements to the completion system discussed lately (keywords: tags, priorities, and Peter's auto-documentation suggestion). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de