From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15669 invoked from network); 21 Jun 1999 07:54:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 21 Jun 1999 07:54:38 -0000 Received: (qmail 21239 invoked by alias); 21 Jun 1999 07:54:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6736 Received: (qmail 21232 invoked from network); 21 Jun 1999 07:54:30 -0000 From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: pws-23: RE: _match and auto menu with multipath again Date: Mon, 21 Jun 1999 11:53:25 +0400 Message-ID: <000501bebbbb$24061750$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <199906170837.KAA04058@beta.informatik.hu-berlin.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > > Does any of these do what you want? Note that setting `match_insert=unambig' > may sometimes remove a short pattern if enough components further up > the path were expanded. This is a bit ugly, yes, but I can't think of > an easy way to find out where that precious pattern is which one might > want to have preserved. > Thinking more and more about it: what is the reason for _match to automatically start menu completion at all (apart from compatibility with old zsh, that can be preserved with configuration key). Think about it: 1. We complete /u/l/s/z/f -> /usr/local/share/zsh/functions This is actually the same as if we completed /u*/l*/s*/z*/f* - and is interpreted and implemented this way. What happens is, that unambiguous prefix is replaced and first ambiguous part is replaced with the largest common prefix; remaining parts retain there (implicit) glob pattern. That is, we get something like /usr/local/s/z*/f* share status ... how does it differ from 2. We complete /u/l/s/z/f*s -> /usr/local/share/zsh/functions ? In no way, except, that we know better some patterns (more than only initial character) and thus are able to reduce possible matches. Note, that patterns are often longer than most common prefix - typing /u/l/lib*X* will typically leave me with just 'lib' prefix. So, I think, that either match_insert should be changed to always insert prefix (irrespectively of length) or we need additional config key to force it. And about cutrrent behaviour: compconf correct_accept='2n' compconf match_original='yes' compconf completer='_complete:_match' compconf dumpfile='/home/bor/.zcompdump' compconf path_cursor='yes' compconf match_insert='unambig' compconf correct_prompt='correct to:' bor@itsrm2:~%> l /u/l/lib*X* bor@itsrm2:~%> l /usr/lib/lib*X* lib/ lib64s/ ^ cursor here That is correct and is what I expected. But simply pressing TAB once more results in bor@itsrm2:~%> l /usr/lib/libX11.a lib/ lib64s/ While if I press any cursor movement key and then TAB I get bor@itsrm2:~%> l /usr/lib/lib*X* lib/ lib64s/ ^ cursor here (after cursor-right) bor@itsrm2:~%> l /usr/lib/libX11.a libX11.a@ libXaw.so.6.1@ libXmSni.so.3.0@ libXpm.so.3.4@ libX11.so@ libXdUtils.so.3.1@ libXmu.a@ libXpm.so.4.6@ .................... (long list), or if I explicitly enter '6' bor@itsrm2:~%> l /usr/lib/lib*X* lib/ lib64s/ ^ cursor here bor@itsrm2:~%> l /usr/lib6/lib*X* lib/ lib64s/ ^ cursor here and TAB bor@itsrm2:~%> l /usr/lib64s/libX11.a libX11.a@ libXaw.so.6.1@ libXmu.so@ libXpm.so@ libX11.so@ libXdmcp.a@ libXmu.so.6.0@ libXpm.so.3.4@ ........................ Looks like a problem with list redisplay. Completion code thinks, it has still old valid list. And this also illustrates my point - in this case I do not want menu completion - I just want list to be dislpayed. But, unfortunatley, length(lib) < length(lib*X*) :-( /andrej Just in case: 6731, 6732 applied