Re: Limitations of menuselect

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Olivier Teuliere 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.

> 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. If it meant that your existing key-bindings would do
something appropriate it might make sense but you do have to duplicate
them in the menuselect keymap. Was this perhaps a bug introduced later
such as when local keymaps were added? In any case, I'd have thought it
was simpler if there were separate widgets - e.g. menu-up-entry instead
of up-line-or-history being overloaded.

> 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.

> 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.

> 4) When moving the selection in the menu, the inserted text changes.
> But for some reason, the accept-line widget only closes the menu,
> without accepting the line. So to really accept the line I have to
> call accept-line again (basically, I have to hit Enter twice). This
> behavior seems a bit backwards: if I wanted to accept the current
> selection, which is already inserted, I could simply go on typing, I
> don't need an extra validation step. So, would it be possible to have
> accept-line really accept the line? :) If the current behavior is
> still wanted, it could maybe be called "accept-selection", because the
> current name is misleading...

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.

> 5) Apparently, menuselect always inserts the selected text. But if
> there was a way (maybe using a style) to select a menu entry without
> inserting the corresponding text, it could allow a killer feature:
> typing characters could shrink the list of results (for example, by
> binding individual letter keys to an appropriate widget...

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.

> 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.

Oliver