From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29258 invoked from network); 11 Oct 1999 21:44:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Oct 1999 21:44:15 -0000 Received: (qmail 27833 invoked by alias); 11 Oct 1999 21:44:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8213 Received: (qmail 27826 invoked from network); 11 Oct 1999 21:44:09 -0000 Date: Mon, 11 Oct 1999 22:44:08 +0100 From: Adam Spiers To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH and Re: simulation of dabbrev-expand Message-ID: <19991011224408.B23117@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh-workers@sunsite.auc.dk References: <199910111112.NAA02526@beta.informatik.hu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <199910111112.NAA02526@beta.informatik.hu-berlin.de> X-URL: http://www.new.ox.ac.uk/~adam/ X-OS: Linux 2.2.12 i686 Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote: > > [ Trying to reduce the number of replies by answering multiple > messages... ] Welcome back to the fun :-) > 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. Yep, this should be fine I guess. > ...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). That would be nice too. Then you could be quite intelligent about what to display. For example you might want to specify LIST_MAX as multiples of the screen length. > > Selecting completion groups would be a nice feature in any case. > > 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). I look forward to it :-)