From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28025 invoked by alias); 10 Apr 2011 14:49:27 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28985 Received: (qmail 20031 invoked from network); 10 Apr 2011 14:49:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110410074855.ZM9428@torch.brasslantern.com> Date: Sun, 10 Apr 2011 07:48:54 -0700 In-reply-to: Comments: In reply to Mikael Magnusson "Re: menu-select interactive mode" (Apr 9, 10:58pm) References: <110409131236.ZM16037@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: menu-select interactive mode MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 9, 10:58pm, Mikael Magnusson wrote: } } On 9 April 2011 22:12, Bart Schaefer wrote: } } > } Additionally, when you do the second one, ie set both select and } > } interactive, the menu-select widget does invoke interactiveness, so my } > } guess is the code simply checks the style instead of also checking } > } which widget invoked it. } > } > That's sort of the right diagnosis. There are several possible ways } > to "fix" this if it's wrong, and I don't know which one is correct. } > } I might be getting myself in a confused state by this point, but } neither of these seemed to do it for me with just setting 'menu } interactive' and using menu-complete, I did check that I zmodload } complist first too. Using menu-complete or using menu-select? Note that the test looks explicitly for the menu-select widget by name. Should it instead be looking for menu-* as a pattern? I've just re-tested both of these and found that the second one does not always work, and I can't figure out what I did to convince myself it was working consistently before. This first one, however (excerpted again below), does it for me when starting from zsh -f and with no other styles defined: torch% print $ZDOTDIR /home/schaefer/.zsh-test torch% head ~/.zsh-test/.zshrc zmodload zsh/complist autoload -Uz compinit compinit -D zstyle ':completion:*' menu interactive bindkey '\em' menu-select return torch% zstyle -L zstyle ':completion:*' menu interactive torch% ls interactive: [] BUILD config.log Etc/ Src/ Completion/ config.modules Functions/ stamp-h Config/ config.modules.sh local stamp-h.in config.h config.status* Makefile Test/ config.h-xx Doc/ sleep ul* It does, of course, also depend on there being more than one match. } > Here's the first, which has the smallest number of side-effects: } > } > Index: Completion/Base/Core/_main_complete } > =================================================================== } > --- _main_complete 21 Dec 2010 16:41:14 -0000 1.12 } > +++ _main_complete 9 Apr 2011 19:57:11 -0000 } > @@ -284,7 +284,7 @@ } > unset MENUSELECT } > fi } > fi } > - if [[ -n "$MENUSELECT" ]]; then } > + if [[ -n "$MENUSELECT" || "$WIDGET" = menu-select ]]; then } > if [[ -n "$_menu_style[(r)interactive*]" ]]; then } > MENUMODE=interactive } > elif [[ -n "$_menu_style[(r)search*]" ]]; then } } btw, both MENUSELECT and MENUMODE seem to "leak" out into the main } shell environment, is that necessary to keep the state consistent } during completion? It's because the complist module needs both of them set (and MENUSCROLL if you have that style) and on any given entry to _main_complete it's not known whether they were previously set by either the user or by _main_complete itself maintaining state for the next pass. That is, _main_complete gets menu selection started but then _main_complete returns to the top level. The menu-select internals are then in control and need those variables to remain set. To clean them up properly we'd need a hook on menu-select exiting. Hmm, nowadays it might be possible to do it with a zle-line-init hook. That didn't exist when this code in _main_complete was written. } btw#2, this whole interactive feature is very under-advertised, I've } used zsh since 2003 and even have commit access, and I never heard } about it before today. Zsh doesn't really have a marketing department. :-) Volunteers? There are still some bugs in the interactive mode. Starting from the "ls" above, type "c": torch% ls c interactive: config.[] config.h config.log config.modules.sh config.h-xx config.modules config.status* Now press TAB: torch% ls config. interactive: config.[] config.h config.log config.modules.sh config.h-xx config.modules config.status* Then type "l": torch% ls config.l interactive: config.log[] config.log Then press ENTER to accept the one-and-only match: torch% ls config.log l Finally type ENTER again: torch% ls config.logl ls: config.logl: No such file or directory --