From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5487 invoked from network); 30 Mar 1999 12:04:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Mar 1999 12:04:24 -0000 Received: (qmail 21669 invoked by alias); 30 Mar 1999 12:03:52 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5990 Received: (qmail 21661 invoked from network); 30 Mar 1999 12:03:49 -0000 From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: PATCH: was RE: PATCH: old lists compstate Date: Tue, 30 Mar 1999 16:02:42 +0400 Message-ID: <001701be7aa5$371a3710$21c9ca95@mowp.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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <199903301110.NAA07289@beta.informatik.hu-berlin.de> Importance: Normal I get a feeling, you are going to hate me ... So, do I understand it correctly: 1. The first TAB always inserts the longest prefix and throughs the list away. If autolist is set but listambiguous is unset, list is displayed immediately. 2. The second TAB reruns the completion and finds out, that no more unambiguous prefix exists. If autolist and listambiguous are both set, the list is displayed now and nothing is inserted; list is thrown away. If autolist is unset, list is retained for possible menucompletion 3. Only if both autolist and listambiguous are set - the completion code is rerun again on third TAB - and nothing is inserted 4. Finally, automenu cuts in on the forth TAB. I just tried it with vanilla zsh -f; just try ls ChTAB in zsh top level dir :-) Look: bor@itsrm2:/tools/src/zsh-3.1.5-pws-14%> zsh -f itsrm2% l Ch itsrm2% l ChangeLog itsrm2% l ChangeLog ChangeLog ChangeLog.3.0 (beep) itsrm2% l ChangeLog ChangeLog ChangeLog.3.0 (beep) itsrm2% l ChangeLog.3.0 ChangeLog ChangeLog.3.0 So, I need four TABS to get at the automenu completion. _path_files does it on the third TAB. confused. > > You wrote: > > > with automenu without autolist, listambiguous > > - menu is started at the second TAB. List is never shown. > Cursor moves to > > end of word when menu starts > > with automenu,autolist without listambiguous > > - list is shown at the first tab; menu at the second TAB; > cursor moves to > > the end of word when menu starts > > with all three set > > - list is shown at the second TAB; menu is started at the > third TAB; cursor > > is moved at the end of inserted string when menu starts! > > The difference in cursor placement is a -- probably somewhat ugly -- > interference between `listambiguous' and `automenu'. On the first TAB > it inserts the unambiguous part (non-menucompletion). in all three cases? So it looks like. And in all three cases cursor is (at least, optically) left after inserted string. On the second > TAB it runs through the completion code again and finds nothing > unambiguous to insert so that `listambiguous' means to show the list > now. Before this the cursor was in the middle of the word. But this is (at least, optically) in all three cases. The third > TAB runs the completion code again, but immediatly starts > menucompletion, the real completion code (generating matches) is not > run. Different from the other two cases menucompletion is now > started when the cursor is already in the middle of the word (which is > remembered by automenu). Ehem ... the cursor is in the same place in all three cases for all I can tell. In this case menucompletion always left the > cursor there instead of moving it to the end. > The problem is, of course, that one has to realise that the first two > TABs do normal completion and since that leaves the cursor in the > word... > The difference (if the four steps at the beginning are correct) seems to be, that not previous, but "one before previous" position seems to be remembered. That looks really strange in view, that the list built by the first TAB is discarded in any case and we start from scratch the on the second TAB ... and in all three cases the cursor is in *exactly* the same position. > Now try `setopt alwaystoend'... > Well, it always moves to the end ... where I'd like to see an option to stay in word :-) But in any case, it looks more like a bug to me ... regards /andrej