Re: Limitations of menuselect

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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.

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

> 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

Oliver