Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: $KEYMAP in command, isearch and menuselect



On Mon, 09 Aug 2010 19:25:41 +0200
Ole JÃrgen BrÃnner <olejorgenb@xxxxxxxx> wrote:
> I was trying to make a zle widget to display the currently active
> bindings when I noticed that KEYMAP is set to 'main' in widgets run
> from command, isearch and menuselect.
> 
> show-keymap() {
> 	{ print "$KEYMAP:\n"; bindkey -M $KEYMAP } | less
> }
> zle -N show-keymap
> bindkey -M vicmd "^Ki" show-keymap
> bindkey -M main "^Ki" show-keymap
> bindkey -M command "^Ki" show-keymap
> bindkey -M menuselect "^Ki" show-keymap
> bindkey -M isearch "^Ki" show-keymap
> 
> In 'command' the binding doesn't work. (since you only can bind a few
> widgets in 'command')
> 
> In vicmd and main it works as expected
> 
> In isearch and menuselect the 'main' keymap is displayed and the
> search/completion is aborted on the current entry.
> 
> Poking in the code for 'executenamedcommand', it seems there is
> something called a 'localkeymap' and this is not exposed to zle
> widgets.

Unfortunately you can't do what you're trying to here, and probably
not what you really want to. Not just the command but also the
menuselect and isearch environments (I deliberately didn't say
keymaps) only have a limited number of commands they can execute. What's
more, even if you rebind the command in question the shell will still
run the same code from its limited repertoire of things it can do in
those special modes. Basically, the only thing you can do is bind one of
the names listed in the documentation to a different key. The
documentation should probably be clearer the behaviour isn't
extensible.  Internally, this is because those modes are each
implemented within a single function, not by looking up function
behaviour like standard editing behaviour.

What you're seeing with menuselect and isearch is if they encounter a
command they don't understand, they put you back in the normal editing mode
which runs that.

There is indeed the issue that there's no way of getting the local keymap
from shell code.  It would be straightforward to add a variable that shows
it, so you could decide if there was a binding that took precedence over
the principal keymap.  However, because of the way the code that uses it is
implemented I can't think of a case where you would ever get to shell code
that could use it.

-- 
Peter Stephenson <pws@xxxxxxx>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom



Messages sorted by: Reverse Date, Date, Thread, Author