From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18935 invoked by alias); 17 Dec 2014 03:07:21 -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: 33983 Received: (qmail 9117 invoked from network); 17 Dec 2014 03:07:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=LrklEcZZ c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=A92cGCtB03wA:10 a=yUkRgET4Nnsuz-qeNyQA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141216190706.ZM19162@torch.brasslantern.com> Date: Tue, 16 Dec 2014 19:07:06 -0800 In-reply-to: <10372.1418757100@thecus.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: accept-and-hold in interactive mode of menu select" (Dec 16, 8:11pm) References: <6B615901-83A3-41A0-9017-3EFA7EF5CA42@kba.biglobe.ne.jp> <141216084537.ZM18852@torch.brasslantern.com> <10372.1418757100@thecus.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: accept-and-hold in interactive mode of menu select MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 16, 8:11pm, Oliver Kiddle wrote: } } Bart wrote: } > } > I'm not entirely sure that's wrong; accept means to accept what is on the } > command line, not to accept what is highlighted in the menu. You have to } > finish the action of choosing one of the menu items so that the command } > line is updated, before you accept. } } No, with menu selection many widgets have quite different behaviour. The } documented behaviour of accept-and-hold is to insert the currently } selected match but keep the menu active so that you can select another } match. Yes, but my point is that in the interactive sub-mode, so to speak, there is no "currently selected match" -- there's a highlighted item in the menu, but in the example given the interactively-entered prefix is still ambiguous, so nothing has been "selected" until that's resolved. In this sense the interactive mode is different from the navigation mode. In the navigation mode the command line and the menu highlight are always in sync so this distinction doesn't matter. I acknowledge that this is being pedantic and that seeing a highlighted item could lead one to believe it has been "selected" and it's probably better to have the interactive mode behave that way. } In a separate thread Bart recently wrote: } > I hadn't seen auto-fu before but it appears to be a rewrite of the old } > incremental-complete-word functions. I'm mildly surprised to see that } > it's using the keymap+widget technique } } At its basic level keymap+widget seems to just be a way to define the } behaviour of a widget for a particular keymap separately so you can have } one function for say ucase and another for say lcase and you can use one } without the other. Something like that; it's an attempt to get behavior a bit more similar to an emacs minor mode. The examples only deal with rebinding self-insert and accept-line but you could do a whole suite of related bindings. I started rewriting predict-on with it but didn't ever finish; auto-fu seems to have done a much more thorough job. } Perhaps a more generic mechanism would be to allow zle widget aliases to } be keymap specific. (Or possibly conditional on a selection of things } using zstyle as a backend.) If at some point I get especially ambitious, I'd like to use zstyles to create something like emacs "advice" hooks. } For the too many omz plugins case, we'd need to somehow allow the } aliases to be chained so I'm not sure that this is a complete solution. We might learn a lot by looking at the way emacs and Xwindows manage key bindings.