From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5034 invoked from network); 27 Mar 2001 21:42:57 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Mar 2001 21:42:57 -0000 Received: (qmail 3180 invoked by alias); 27 Mar 2001 21:42:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13804 Received: (qmail 3169 invoked from network); 27 Mar 2001 21:42:50 -0000 Sender: opk Message-ID: <3AC1032D.263705A8@u.genie.co.uk> Date: Tue, 27 Mar 2001 22:16:29 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.18 i586) X-Accept-Language: en MIME-Version: 1.0 To: Zsh workers Subject: Re: prefix-needed style in _popd References: <200103270942.LAA15423@beta.informatik.hu-berlin.de> <20010327113950.51186.qmail@web9304.mail.yahoo.com> <1010327175637.ZM14146@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bart Schaefer wrote: > This is actually what _mailboxes does ... it adds all possible matches, > with + or @ or % or full paths or whatever ... I was wondering whether > it ought to be testing prefix-needed, too. It should really. As should _mh. Also, it seems that _mh acts as if prefix-needed is true while _mailboxes acts like it is false. > Sven's patch to _popd makes it behave as if prefix-needed were true > without actually testing the style any more, whereas _mailboxes behaves > as if prefix-needed were false. The inconsistency concerns me (but not > very much). We should probably agree on a consistent default for prefix-needed (and quite possibly other styles). It is already `true' by default for options which is the most significant thing which prefix-needed affects so true is going to suprise the least people. On the other hand, there is the argument that the default should be completeness and the styles should be used to refine this down to what the user wants. > I don't set prefix-needed at all, myself, but I don't understand the > objection to the `false' behavior. If you're used to typing a prefix, > then you'll have typed one, and any listing will be restricted to the > matches that have that prefix. Is the issue that you don't want to > see the possible completions that have a prefix when you complete with > no prefix in the word on the line? It is exactly what you describe at the end. I consider the completion system to be as valuable for providing information as for "completing". I now rarely use ls other than with -l, so I regularly press tab without first typing a few letters. Without options in the list of completions, it is often much easier to see what I want. I'm not even convinced that I like having long options completed unless I first type two minuses. Completion can be more useful if it is generating fewer matches but is being intelligent enough to include those things which the user wants (the fewer things in the list of matches, the less buried the one the user wants is). I find that with prefix-needed it is more often successful with this and I find it predictable because I'm used to it working that way. Oliver