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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 16,  8:11pm, Oliver Kiddle wrote:
}
} 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.

Yes, but my point is that in the interactive sub-mode, so to speak, there
is no "currently selected match" -- there's a highlighted item in the
menu, but in the example given the interactively-entered prefix is still
ambiguous, so nothing has been "selected" until that's resolved.  In this
sense the interactive mode is different from the navigation mode.

In the navigation mode the command line and the menu highlight are always
in sync so this distinction doesn't matter.

I acknowledge that this is being pedantic and that seeing a highlighted
item could lead one to believe it has been "selected" and it's probably
better to have the interactive mode behave that way.

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

Something like that; it's an attempt to get behavior a bit more similar
to an emacs minor mode.  The examples only deal with rebinding self-insert
and accept-line but you could do a whole suite of related bindings.  I
started rewriting predict-on with it but didn't ever finish; auto-fu seems
to have done a much more thorough job.

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

If at some point I get especially ambitious, I'd like to use zstyles to
create something like emacs "advice" hooks.

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

We might learn a lot by looking at the way emacs and Xwindows manage
key bindings.