From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7205 invoked by alias); 28 Feb 2013 01:59:33 -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: 31079 Received: (qmail 19650 invoked from network); 28 Feb 2013 01:59:31 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130227175900.ZM7434@torch.brasslantern.com> Date: Wed, 27 Feb 2013 17:59:00 -0800 In-reply-to: <21084.1361986051@thecus.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: Limitations of menuselect" (Feb 27, 6:27pm) References: <21084.1361986051@thecus.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Limitations of menuselect MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 27, 6:27pm, Oliver Kiddle wrote: } Subject: Re: Limitations of menuselect } } Olivier Teuliere wrote: } > Someone told me on IRC that in menuselect a hard-coded table is used } > to lookup the widget names. } } More or less. It seems any keybinding picked up from the main keymap } will work though menu selection is exited first. For anything from the } menuselect keymap, it hard codes the actions with various widgets being } overloaded from their original meanings. I'm not sure that I get the } point of this. At the time menuselect was added, the "local keymaps" implementation had not yet been done. So menuselect was implemented as a self-contained widget (just like the incremental search widgets, etc.) that does all its own key interpretation. The reason for overloading widgets from the main keymap was because the keystroke interpretation code always mapped everything directly to a known widget object. (I'm not sure user-defined widgets even existed yet at that time.) So the only way to have [say] ENTER mean one thing in the main keymap and another in menuselect was to overload the widget to which ENTER was mapped. When the local keymaps were introduced, nobody ever undertook to refit menuselect to use real widgets; it got its own keymap but the overload implementation was never ripped out and rebuilt. } > 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. } } That seems like a bug to me. I think it was punted as requiring too much implementation effort, given that up-arrow from the first result in menu-selection will cycle to the last result. } It certainly makes sense and is quite thought provoking. I'm only sorry } that my answers aren't especially helpful. Ditto ...