Re: accept-and-hold in interactive mode of menu select

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

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. accept-line-and-down-history does the same but doesn't seem to be
documented. It's a useful feature.

Coopting existing widgets in this way allows existing key bindings to
automatically pick up related behaviour but it does mean that they
aren't quite doing what their name would imply.

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, I didn't think anyone had even
> noticed that existed.

The keymap+widget technique is somewhat related. I was aware of it but
haven't applied it because it involves rebinding lots of core widgets.
A number of omz plugins rebind stuff en-masse and I suspect that's one
reason why people turn up on IRC wondering why things are broken when
they enable too many plugins.

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.

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

We could then make, e.g vi-up-line-or-history an explicit alias for a
new menuselect+prev-entry widget in the menuselect keymap.

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.

Oliver