From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27980 invoked from network); 11 Oct 2000 10:56:25 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Oct 2000 10:56:25 -0000 Received: (qmail 16769 invoked by alias); 11 Oct 2000 10:55:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12959 Received: (qmail 16762 invoked from network); 11 Oct 2000 10:55:43 -0000 Date: Wed, 11 Oct 2000 12:55:41 +0200 (MET DST) Message-Id: <200010111055.MAA26535@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Wed, 11 Oct 2000 13:15:08 +0400 Subject: PATCH: RE: completion widgets in menu selection Andrej Borsenkow wrote: > ... > > > The more I think about this, the more sense does it seem to make, > > especially because this allows everything that was possible before > > plus some. > > One problem. How should undo after this second widget behave? Curretly it > leaves the last match, selected in menu selection, inserted and forgets about > list. I've modified the patch to make it go back to where it was when menu selection was started. I'm going to commit this version of the patch. > It would be very nice if it returned to menu selection ... but I do not > know how difficult it is. Very. At that time it has left the menu selection code and doesn't have any information about the state that was in any more. > More general. With amount of state information kept in compstate it is very > easy to write separate bindable commands that modify generated lists. One can currently only say what to do with that list, display-wise and insertion-wise. > It would > be very nice if undo returned to previous state in this case. Hm, maybe, yes. The problem is that the undo-stuff isn't handled by the completion code but by the zle main loop, so we don't really have any control over it, other than inserting additional undo-return points -- the opposite of what you want. Maybe it's one of the things you can bring to our minds when (and if) we try to improve zle and the integration of completion widgets into zle after 4.0. Bye Sven Index: Src/Zle/compcore.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v retrieving revision 1.39 diff -u -r1.39 compcore.c --- Src/Zle/compcore.c 2000/10/04 13:24:45 1.39 +++ Src/Zle/compcore.c 2000/10/11 10:49:38 @@ -524,14 +524,16 @@ dat[1] = 0; menucmp = menuacc = 0; minfo.cur = NULL; - if (ret == 2) { + if (ret >= 2) { fixsuffix(); cs = 0; foredel(ll); inststr(origline); cs = origcs; - clearlist = 1; - invalidatelist(); + if (ret == 2) { + clearlist = 1; + invalidatelist(); + } } } } Index: Src/Zle/complist.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v retrieving revision 1.32 diff -u -r1.32 complist.c --- Src/Zle/complist.c 2000/07/03 08:05:28 1.32 +++ Src/Zle/complist.c 2000/10/11 10:49:38 @@ -2237,7 +2237,11 @@ continue; } else { ungetkeycmd(); - acc = 1; + if (cmd->widget && (cmd->widget->flags & WIDGET_NCOMP)) { + acc = 0; + broken = 2; + } else + acc = 1; break; } do_single(**p); @@ -2260,6 +2264,7 @@ menucmp = 2; showinglist = -2; minfo.asked = 0; + zrefresh(); } if (!noselect && (!dat || acc)) { showinglist = -2; @@ -2271,7 +2276,8 @@ mlbeg = -1; fdat = NULL; - return ((dat && !broken) ? (acc ? 1 : 2) : (!noselect ^ acc)); + return (broken == 2 ? 3 : + ((dat && !broken) ? (acc ? 1 : 2) : (!noselect ^ acc))); } /* The widget function. */ -- Sven Wischnowsky wischnow@informatik.hu-berlin.de