From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6507 invoked from network); 15 Oct 2004 08:55:06 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 15 Oct 2004 08:55:06 -0000 Received: (qmail 91637 invoked from network); 15 Oct 2004 08:54:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 15 Oct 2004 08:54:58 -0000 Received: (qmail 25311 invoked by alias); 15 Oct 2004 08:54:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20489 Received: (qmail 25297 invoked from network); 15 Oct 2004 08:54:54 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 15 Oct 2004 08:54:54 -0000 Received: (qmail 91303 invoked from network); 15 Oct 2004 08:53:55 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 15 Oct 2004 08:53:53 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.13.1/8.13.1) with ESMTP id i9F8rq9h007165 for ; Fri, 15 Oct 2004 01:53:52 -0700 Date: Fri, 15 Oct 2004 01:53:52 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: zsh-workers@sunsite.dk Subject: menu-select widget interacts badly with interactive style Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 I just stumbled upon a bit of confusing behavior that probably warrants a mention somewhere ... I'm just not sure where. I have a widget defined with "#compdef -k menu-select ...". This bypasses _main_complete for that widget because of the implementation of #compdef in compinit, even though menu-select itself is mapped onto _main_complete. Most of the time this is OK. (Evidently this is something I should be doing with _generic instead?) However, if I also use "zstyle ':completion:*' menu select interactive" things get interesting. With this setting, since none of the values is "yes", the automenu rules are in effect and normal TAB completion produces a listing on the first TAB and enters menu selection (with interactive mode) on the second TAB. So far this is all as expected. When I invoke my own widget before having done any other completions, it does not start interactive selection, because _main_complete is never called -- but after I've entered menu selection through TAB completion, _main_complete leaves the MENUSELECT et al. control variables set. Thus the *next* time I invoke my menu-select widget, that also starts up in interactive mode. (I presume the same would apply to search mode.) It was quite disconcerting for a while there not being able to predict whether I was going to get interactive mode or not, before I figured out what was going on. Another less urgent factor is that the SPACE key breaks out of interactive menu selection even when there are spaces in some of the possible matches. In some cases this makes it impossible to disambiguate the match, and one is forced to (a) remember not to type space because it'll stop completion and perform self-insert, and (b) use down-history et al. to begin normal menu selection and navigate to the desired match.