From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16986 invoked from network); 17 Sep 1999 10:36:10 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 1999 10:36:10 -0000 Received: (qmail 16348 invoked by alias); 17 Sep 1999 10:35:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7908 Received: (qmail 16338 invoked from network); 17 Sep 1999 10:35:48 -0000 Date: Fri, 17 Sep 1999 12:35:46 +0200 (MET DST) Message-Id: <199909171035.MAA02368@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 17 Sep 1999 09:48:27 +0000 Subject: Re: Completion heuristics (was Re: bug in _rpm?) Bart Schaefer wrote: > On Sep 17, 10:45am, Sven Wischnowsky wrote: > } Subject: Re: bug in _rpm? > } > } > % rpm -ihv /usr/src/redhat/RPMS/i386/ > } > % rpm -ihv /usr/src/redhat/RPMS/i386/-- > } > zsh: do you wish to see all 28 possibilities? > } > > } > Where did that `--' come from? > } > } Do you have many files in that directory, all of the form `*-*-*' > > He must. That's what RPM file names look like. I know, that one wasn't meant that serious. > In this situation the amount of information and typing assistance that > is provided by inserting any ambiguous string at all is so small as to > be merely confusing. The whole point of ambigous string insertion is > that the human is supposed to be better than zsh at resolving the > ambiguity, which ceases to be true below a certain information-content > threshold. [unambiguous] Yes, in fact, I've already been thinking in the same direction after the latest discussion. > Better cursor placement would only help a little, and I think in this > example not at all. Well, if done right... see below. > One approach would be to figure out some heuristic for determining that > the ambiguous string "looks enough like" an element of the set of possible > matches, and not insert it at all if it looks "too different." > > A wild guess at such a heuristic: > > 1. There's exactly one choice for cursor placement to resolve the > ambiguity; OR > > 2. The ambiguous string shares a common (non-empty) prefix with ALL > of the possible matches; OR > > 3. The ambiguous string is at least half as long as the difference > between the lengths of the shortest match and the longest and at > least one-fourth as long as the length of the shortest. > > Number (3) is obviously the wildest of the guesses. I'd probably go with > just the first two, but I don't rely on intra-word match-specs all that > often, so I don't know exactly how to predict what's useful there. I'm not so sure about (1) either. But I need play with different implementations to be better able to think about this. Maybe at the weekend. > As for cursor placement: Put it wherever the addition of a character > would make the greatest difference in the number of matches; another > way to say this is, place the cursor at the implicit * that matches the > greatest number of alternatives. That's what I tried to implement before 7630. The problem is that we can't reliably calculate that information, as you thought. > This may be beyond our ability to > determine ... but the whole point of completion is to help the user > reduce the set of alternatives from N to 1 as quickly as possible, so > wherever will help throw out the most alternatives is the right place > to ask for more input. And that's what I've tried to achieve from the beginning. Remember the older discussions about cursor positioning? The completion code even puts the cursor preferably in a position where the user can continue by simply inserting something instead of having to type backspace-. The problem we have now is a problem at a lower level. How to find the best position between those that look equally interesting for the completion code and if to insert string-parts for which there is nothing on the line at all. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de