From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22687 invoked from network); 6 Jul 1998 06:50:48 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 6 Jul 1998 06:50:48 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id CAA01640; Mon, 6 Jul 1998 02:36:26 -0400 (EDT) Resent-Date: Mon, 6 Jul 1998 02:36:26 -0400 (EDT) Date: Mon, 6 Jul 1998 08:37:52 +0200 (MET DST) Message-Id: <199807060637.IAA26729@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: "Bart Schaefer"'s message of Fri, 3 Jul 1998 12:33:48 -0700 Subject: Re: Compctl completion tweaking Resent-Message-ID: <"HfjIa1.0.ZP.g17er"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4203 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart Schaefer wrote: > > On Jul 1, 8:13am, Sven Wischnowsky wrote: > > Subject: Re: Compctl completion tweaking > > > > First, I would try to change the behaviour of -P (and -S) so that they > > are not inserted straight away, but instead [...], the prefixes > > are walked through, too [....] > > This sounds to me rather like the behavior of compctl -U. Perhaps the > use of inclusive-or should simply imply, or require pairing with, -U ? > No, with -U the stuff on the command line is simply ignored. What I described is a bahaviour that treats -P/-S sruff a bit more like the matches. In fact, they are already treated a bit like them: if you have a compctl with `-P foo' and type `fd', the `f' is expanded to `foo' and the `d' is taken as the prefix for the matches. The importent difference is, that currently there can be only one such -P/-S and we can insert it immediatly. But with inclusively-ored compctls, we have to make sure, that the right prefix/suffix is inserted along the matches. I would certainly not implement some connection/requirement with -U, since that would mean that we couldn't give a prefix/suffix for the matches we want to see (-U is the user's way to say to the completion code: "You don't have a clue what kind of words I want to complete here, anyway, so simply throw away the current word, and do no matching at all, I'll give you the whole matching words."). > > More problematic is the case where > > we have prefixes like, say `barrr' and `bazzz'. The completion code > > would insert the `ba' [...] > > but without completeinword (and without automenu), the user > > would have to type `rrr' or `zzz' which is a bit ugly. > > That's no worse than what happens without a prefix when completing in > the middle of a word that happens to match more than one result, is it? It is very similar, but with a little difference: currently, this can only happen with matches, but with inclusive-ors, it can also happen with prefixes/suffixes (it simply might surprise the unaware a bit, but if you are using all this, you are probably so deep into compctl-hacking that you know, what you are doing anyway). > > > So, does this seem to make sense? > > Mostly, but as with most completion stuff it's probably necessary to see > it in action. Yep. I hope I find some time soon. If I don't find some time soon, you might have to wait surprisingly long, since the semester is coming to its end, we have to hold some examinations, and, most importantly, our whole institute will move to a new building starting on July, 21th and of course we can't be sure, when we will be able to work again after that. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de