From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9424 invoked from network); 31 May 2000 06:51:12 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 May 2000 06:51:12 -0000 Received: (qmail 14758 invoked by alias); 31 May 2000 06:51:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11683 Received: (qmail 14750 invoked from network); 31 May 2000 06:51:04 -0000 Date: Wed, 31 May 2000 08:51:02 +0200 (MET DST) Message-Id: <200005310651.IAA22451@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 30 May 2000 15:36:20 +0000 Subject: Re: #compdef tag and menu-select Bart Schaefer wrote: > On May 30, 10:16am, Sven Wischnowsky wrote: > } > } Bart Schaefer wrote: > } > } > At other places in the completion system we automatically load complist when > } > it seems wanted. Perhaps compdef should too? > } > } Nowadays I'm a bit reluctant to change that because I've too often > } thought about removing menu-select -- after all, it's just > } menu-complete with enforcing selection, which can be achieved by other > } means. > > Really? What other means? Specifically, I have a widget that is entirely > independent of the completion system (except that it's created with zle -C > and uses compadd; but it has nothing to do with _main_complete) and *for > that widget only* I want menu-select behavior *all the time*. > > It's convenient to put `#compdef -k menu-select ^X:' at the top of the > file that defines this widget and let compinstall bind it for me, even > though it's otherwise not part of the completion system. Yes. > What can I put *in the definition file* for this widget that will enable > menu selection "by other means"? I tried everything I could think of, > poking into various values of compstate and assigning to MENUSELECT and > whatnot, and I couldn't force menu-selection to start if the widget was > e.g. bound with `#compdef -k menu-complete ^X:'. foo() { compadd ... MENUSELECT=0 compstate[insert]=menu } zle -C foo complete-word foo bindkey '...' foo Works for me. > } And there is the question if menu-select should be re-bound to > } _main_complete when compdef finds a widget using menu-select. > > In the situation described above I definitely do not want that. Err, I meant the automatic re-binding compinit already does for all the completion widgets (including menu-select if complist is already loaded), at line 452. So if compdef can make complist be loaded automatically, should it do the same for menu-select if that isn't re-bound already? Probably not very important... Should I apply the patch? Shouldn't be able to do any harm, should it? Bye Sven Index: Completion/Core/compinit =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Core/compinit,v retrieving revision 1.3 diff -u -r1.3 compinit --- Completion/Core/compinit 2000/05/25 14:48:38 1.3 +++ Completion/Core/compinit 2000/05/31 06:49:03 @@ -232,6 +232,7 @@ fi [[ $1 = _* ]] || 1="_$1" [[ $2 = .* ]] || 2=".$2" + [[ $2 = .menu-select ]] && zmodload -i zsh/complist zle -C "$1" "$2" "$func" if [[ -n $new ]]; then bindkey "$3" | read -A opt @@ -250,8 +251,10 @@ # Define the widget. if [[ $1 = .* ]]; then + [[ $1 = .menu-select ]] && zmodload -i zsh/complist zle -C "$func" "$1" "$func" else + [[ $1 = menu-select ]] && zmodload -i zsh/complist zle -C "$func" ".$1" "$func" fi shift -- Sven Wischnowsky wischnow@informatik.hu-berlin.de