From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16404 invoked by alias); 28 Feb 2013 09:35:07 -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: 31084 Received: (qmail 27759 invoked from network); 28 Feb 2013 09:35:05 -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.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.219.54 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=79wPjrXlMdHQN8ZhL/n+OVTRTXLsAgmrE0VI49DZLJc=; b=qcJCh/HDhRvDGuP6kogfAimQgr8u2KJJ+AU+Z79kwaRTnB4eDWYFf281NTLDQFjICq S0+m+nKjvJyiV3ZdE04yQLzNBj3a0Sr94sxzwt5wjvc4ju0MvVGzlAuyWynX5mhgGfA2 SDldROfM0BnxnaU9Ae2uxtj+sVBLzbR83tmc5Z6JYrW2ckeqDvHrGvLD9pNyu56hTciq yvOJ+DAIg5F5lROeE/MA15K1ob7uEscDP20RX+0/sL5Z3QRAwrg60DmlS0PIR6psPAJo 51l0QqUTZ6Vj61h9xizrwlXccsn59tKPjHBqtQD4H/XGjzV7lHCAKT5sAiEyys67GhJ9 VBhA== X-Received: by 10.60.172.198 with SMTP id be6mr5257924oec.20.1362044100436; Thu, 28 Feb 2013 01:35:00 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <26011.1362013659@thecus.kiddle.eu> References: <21084.1361986051@thecus.kiddle.eu> <26011.1362013659@thecus.kiddle.eu> From: Olivier Teuliere Date: Thu, 28 Feb 2013 10:34:40 +0100 Message-ID: Subject: Re: Limitations of menuselect To: zsh-workers@zsh.org Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Feb 27, 2013 at 6:27 PM, Oliver Kiddle wrote: >> 1) Custom bindings don't work. You can try it with the following: >> my-widget() { zle down-line-or-history }; zle -N my-widget; >> bindkey -M menuselect k my-widget >> (replacing "my-widget" with "down-line-or-history" in the bindkey >> command works as expected). > > Yes, unfortunately it isn't possible. Are there plans to implement this in the future? On Thu, Feb 28, 2013 at 2:07 AM, Oliver Kiddle wrote: > I wrote: > > Was this perhaps a bug introduced later > > such as when local keymaps were added? > > It does work correctly as mentioned by Peter so sorry for the > misinformation. I think I got mixed up between > accept-line-and-down-history and accept-and-infer-next-history. It then > seems that the intention is to enable the features on logical keys from > the main keymap. I understand the intention, but IMVHO this adds a lot of complexity (and confusion), just to avoid a few explicit bindings. And I wonder what the '.' widgets (e.g.: .up-line-or-history) would mean, if custom widgets could be used in menuselect mode: would they refer to the menuselect "original override" or to the original version from main? >> 2) Moving the selected menu item line by line is nice, but scrolling >> several lines at a time would be nicer (that's what I would expect >> PageUp and PageDown to do by default in menuselect, for example). I >> couldn't find an existing widget for that. > > You can do some hacks with bindkey -s. For example: > bindkey -M menuselect j down-line-or-history > bindkey -M menuselect -s n 'jj' > What you can do with that is limited. Also, it doesn't cope well with putting > escapes in the latter string. That's a great idea! It works fine for this case. > > > 3) When using the reverse-menu-complete widget to open menuselect, I > > > would like to select the last result, not the first one (otherwise I > > > can use menu-complete directly...). It doesn't sem to be possible at > > > the moment. > > This doesn't seem to be easy to solve. It seems to be in the > REVERSEMENUHOOK where it fixes things to go backwards but the initial > call to reversemenucomplete is not returning from menucomplete() until > it is too late. The clean fix in zsh may not be easy, but bindkey -s gives a rather simple work-around (sacrificing the ^P binding): bindkey "^P" reverse-menu-complete bindkey -s "\e[Z" "^P^P" bindkey -M menuselect "\e[Z" reverse-menu-complete The last line is there to restore the expected behavior of reverse-menu-complete in menuselect mode, otherwise the selection moves 2 lines at a time. Unfortunately, this is a bit invasive if you don't use menu completion all the time, since "\e[Z" is bound unconditionally. >> 4) [...] > > This probably wouldn't be hard to implement if we keep to the scheme of > overloading existing widgets. > > You can abuse the behaviour I described earlier to make Enter really > accept the line: > bindkey -M menuselect -r '^M' > zle -N new-accept-line > new-accept-line() { > zle .accept-line > } > bindkey '^M' new-accept-line > > But don't do this because it'll break the enter key in other contexts > (reading from the mini-buffer). To replace accept-line without breaking > things you need to use zle -A but that won't work here. Inspired by your idea, I got a working solution: really-accept-line() { zle .accept-line } zle -N really-accept-line bindkey -M menuselect '^M' really-accept-line Binding "^M" only in menuselect avoids the problem you mentioned. > > > 5) [...] >> >> Actually, this is possible. Bind a key to vi-insert in menuselect and >> you get "interactive" mode which does this. Still, there is a lot of >> ways this could be better. Unfortunately, you stay in the menuselect >> keymap at this point which is irritating if you've, for example, bound / >> to history-incremental-search-forward. >> >> I can't think of a way to go straight into this mode. The bindkey -s >> trick stuck it in an infinite loop. > > Actually, it turns out this is as simple as including the word > "interactive" in the menu style. For example: > zstyle ':completion*:default' menu select=0 interactive I need to play more with it, but it looks very promising. Minor usability suggestion: a accept-selection-or-line widget could be handy here. It would accept the selection (i.e. insert text and leave menuselect) when no text has been inserted, and it would leave menuselect and accept the line, as described in item 4 above, when the selected text is already inserted (in pure menuselect mode, or when moving the selection around in "interactive" mode). At the moment, this behavior seems impossible to achieve. >> accept-line-and-infer-history maybe?), while still allowing to select > > That also does something similar already: > bindkey -M menuselect '^M' accept-and-infer-next-history > then enter will keep in menu selection. > >> I hope that these remarks make sense and that I haven't overlooked >> some existing features... > > It certainly makes sense and is quite thought provoking. I'm only sorry > that my answers aren't especially helpful. They turned out to be very helpful, thanks. What are the next steps here? The work-arounds given in this thread are mostly enough for my needs, but IMHO several things should be improved in zsh itself. Should I file formal bug reports and/or feature requests somewhere? Best regards, -- Olivier