From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 184 invoked from network); 23 Sep 1999 08:38:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Sep 1999 08:38:29 -0000 Received: (qmail 7279 invoked by alias); 23 Sep 1999 08:38:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8015 Received: (qmail 7272 invoked from network); 23 Sep 1999 08:38:22 -0000 Date: Thu, 23 Sep 1999 10:38:22 +0200 (MET DST) Message-Id: <199909230838.KAA23316@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Adam Spiers's message of Wed, 22 Sep 1999 23:13:17 +0100 Subject: PATCH and Re: simulation of dabbrev-expand First: there was a buglet in `_history_complete_word' which made it pretty useless if `history_stop' wasn't set. I hope the patch below doesn't interfere with your work... Adam Spiers wrote: > The current situation is that _history_complete_word crawls through > matching history words, oldest first. Now I'm confused. For me it works from the bottom up. *But* words from the same line are inserted left-to-right. Since the C-code walks up maybe we should add the words from the end of the line to the beginning. We should then use the hunk for `zle_tricky.c' below. > This is counter-intuitive, > impractical, and not what tcsh users would expect; so I've been > trying to change it to the following setup: > > M-/ _reverse_history_complete_word > M-, _history_complete_word > > _reverse_history_complete_word startest with the most recent match and > works back, and vice versa for _history_complete_word. ... but a `_reverse_*' would still be good to have (I thought about this when I made my last changes to `_h_c_w' but was to lazy...). > However, I got stuck when handling the history_stop feature. > When in verbose mode, history_stop uses _message to indicate that the > beginning/end of the history has been reached. However, unless I've > got things really wrong, _message seems to destroy any old list of matches > which you might want to keep. I can't understand why, as it's only > essentially a compadd -X ... -n ''. That's right. To be able to display the message we have to add a dummy completion (that empty string) and throw away the old list. > I want to do something like: > > compstate[old_list]=keep > _message 'beginning of history reached' This can't work and I don't think it should. Since the `messages' are really only explanation string they belong to their own list and should only be displayed when that list is used. > so that if you hit the oldest match and press M-/ again, it displays > this message but keeps the oldest match (should I need a > compstate[insert]=1 again, or is it enough to have done that the first > time the oldest match was displayed?), and if you switch to M-, it > will keep this old_list again and start moving in the opposite > direction. If I were to implement that, I would use two (global) parameters set when the end is reached with `verbose' (or always when the end is reached). Any of the two ends, that is. The first parameter just says that the end was reached (and could say which end if that is needed). The other one would contain the value of `BUFFER' at the time the end was reached. Now if you invoke the widget for the other direction when an end was reached (the first parameter sayeth so), you compare the second parameter with the current value of `BUFFER'. If they are equal, the thing was just invoked (hm, maybe we shouldn't compare `BUFFER', maybe we should check `LASTWIDGET'; or both; and if you use the numeric argument thing, the latter may also need to have to take that into its calculation). Anyway, the test would say that we just reached one of the ends by the history_complete function for the other direction and if we find that out, we just call completion again (that `compgen') and then use `compstate[insert]=-1' (or `...=1' for the other direction). Getting words to complete from the history should be fast enough so that the user doesn't really notice that a new list was created. For this we would also have to keep the original values of `PREFIX' and `SUFFIX' -- and set them anew in the right place. Anyway, I think it can be done... > Finally, should forward and reverse motion both be handled by the same > widget? Shrug, dunno. The builtin widgets always have two forms and use the numeric argument (and use the other direction if that is negative)... > If you can help with the above problem then with luck I'll be able to > save you the hassle of rewriting all the code. Thanks! I hope it helped. Bye Sven diff -u oldcompletion/Commands/_history_complete_word Completion/Commands/_history_complete_word --- oldcompletion/Commands/_history_complete_word Tue Sep 21 10:26:40 1999 +++ Completion/Commands/_history_complete_word Thu Sep 23 10:14:42 1999 @@ -23,8 +23,8 @@ _description -V expl 'history word' fi compgen "$expl[@]" -Q -H 0 '' - compstate[insert]=1 if [[ -n "$compconfig[history_stop]" ]]; then + compstate[insert]=1 _hist_menu_length="$compstate[nmatches]" _hist_menu_end='' fi diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c --- os/Zle/zle_tricky.c Thu Sep 23 10:19:05 1999 +++ Src/Zle/zle_tricky.c Thu Sep 23 10:21:09 1999 @@ -6932,7 +6932,7 @@ /* Now search the history. */ while (n-- && he) { int iwords; - for (iwords = 0; iwords < he->nwords; iwords++) { + for (iwords = he->nwords - 1; iwords >= 0; iwords--) { h = he->text + he->words[iwords*2]; e = he->text + he->words[iwords*2+1]; hpatsav = *e; -- Sven Wischnowsky wischnow@informatik.hu-berlin.de