From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8236 invoked from network); 23 Sep 1999 14:24:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Sep 1999 14:24:36 -0000 Received: (qmail 7578 invoked by alias); 23 Sep 1999 14:23:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8032 Received: (qmail 7562 invoked from network); 23 Sep 1999 14:23:57 -0000 Date: Thu, 23 Sep 1999 16:23:53 +0200 (MET DST) Message-Id: <199909231423.QAA24746@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Adam Spiers's message of Thu, 23 Sep 1999 14:44:53 +0100 Subject: Re: PATCH and Re: simulation of dabbrev-expand [ Last mail from me for the next two weeks... ] Adam Spiers wrote: > Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote: > > *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. > > Nice touch. Reminds me of another feature I've wanted in > _history_complete_word for ages - would it be possible to modify > compgen -H to include words from the currently edited line? Not that simple because we don't have it in parsed form yet. We could make `get_comp_string()' save them but then we still would only get the words for the current command and all commands before it. > Hmm. I'm still puzzled why compadd -X ... -n '' throws away the old > list though, since compwidget == lastcompwidget and > compstate[old_list] is set to keep. If I understood you correclty: it doesn't. It only looks like that because of the compstate[insert]='' in _message. > - Doesn't cope with numeric arguments yet. > - Whenever duplicates get removed, it breaks. It looks like > compstate[nmatches] corresponds with the number of matches > /including/ duplicates, even if some/all duplicates have been > removed. At the time where you can look at `compstate', it is `...will be removed'. Remember that all the sorting and uniquifying is only done after the widget has returned (and for performance reasons we should probably only do it then). Although... we could do it whenever someone looks at `compstate[*nmatches]', set a flag if the list is sorted and clear the flag when another match is added. Hm. No time now... > - The error message given when unknown keys are bound to the > widget doesn't work. Should I be using zle -R here? No, `zle -R' will only flash the message (and only one line). Ignore that? Beep? Use `_message' or similar code? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de