From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13501 invoked from network); 25 Sep 1999 14:46:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Sep 1999 14:46:37 -0000 Received: (qmail 21066 invoked by alias); 25 Sep 1999 14:45:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8045 Received: (qmail 21026 invoked from network); 25 Sep 1999 14:45:48 -0000 Date: Sat, 25 Sep 1999 15:45:41 +0100 From: Adam Spiers To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH and Re: simulation of dabbrev-expand Message-ID: <19990925154541.B26666@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh-workers@sunsite.auc.dk References: <199909231423.QAA24746@beta.informatik.hu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <199909231423.QAA24746@beta.informatik.hu-berlin.de> X-URL: http://www.new.ox.ac.uk/~adam/ X-OS: Linux 2.2.9 i686 Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote: > [ Last mail from me for the next two weeks... ] :-( > > - Whenever duplicates get removed, it breaks. It looks like > > compstate[nmatches] corresponds with the number of matches > > /including/ duplicates, even if some/all duplicates have been > > removed. > > At the time where you can look at `compstate', it is `...will be > removed'. Remember that all the sorting and uniquifying is only done > after the widget has returned (and for performance reasons we should > probably only do it then). Hmm. This really is a problem. Anything which wants full control of menucompletion (and hence implements it itself, e.g. _history_complete_word, which wants the ability to stop at either end of the matches) will need to know an accurate compstate[nmatches] straight after the compgen call. What's the correct solution here? It would be nice if the C code implemented loop prevention (it feels kind of hacky doing it all through messing around with compstate[insert]) but it's difficult to draw the line between what should be in the C code and what should be shell script ... for example you might want control over what message (if any) should be displayed when you hit one of the ends of the list of matches. Any ideas on what's the Right Way here? One workaround would be to ensure that whenever compstate[oldlist] is set to `keep', compstate[nmatches] is set to the size of the old list. That way, in the _history_complete_word case, you could recalculate nmatches accurately on the second call to the widget, which would be good enough. > 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*