$KEYMAP in command, isearch and menuselect

$KEYMAP in command, isearch and menuselect

[Ole Jørgen Brønner]

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.

Any solution for this?

- Ole Jørgen Brønner

Re: $KEYMAP in command, isearch and menuselect

[Peter Stephenson]

On Mon, 09 Aug 2010 19:25:41 +0200
Ole Jørgen Brønner <olejorgenb@yahoo.no> 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@csr.com>            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

Re: $KEYMAP in command, isearch and menuselect

[Peter Stephenson]

On Mon, 23 Aug 2010 10:36:38 +0100
Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> 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.

At the risk of prolonging this further than I really want...  Oh, too
late...

This is really geeky, but it's not 100% true that binding functions in a
keymap for the special modes has no effect.  The function is first looked
up in the local map; if it's not one of the functions implemented in that
mode, the input string is pushed back onto the input, and then looked up in
the main map, which might give a different result.  So far as I can see
this isn't particularly useful.

It also strikes me as not very useful that $KEYMAP is shown as "main",
although I suppose it does mean you can do

  if [[ $KEYMAP = main ]]; then
    # We're in the main keymap, so we can do that special thing we
    # do when we know the user hasn't switched keymaps...
    ...
  fi

so it should probably should be left.

Even so, I would think what you're more likely to want to know (if you're
interested in the name rather than just getting a value that can be used
for key lookup, in which case the name isn't important) is what keymap is
linked to main.  The real problem is you can't even query that, as far
as I can see from a brief scan of the documentation, and the following,
which you might have thought would at least give you the information:

% bindkey -lL
bindkey -N .safe
bindkey -N command
bindkey -N emacs
bindkey -N isearch
bindkey -N listscroll
bindkey -N main
bindkey -N menuselect
bindkey -N vicmd
bindkey -N viins

is mendacious: "main" wasn't created by "bindkey -N", it got created by the
internal equivalent of "bindkey -A", and this distinction is important
since it's the whole reason for main's existence.

It's also not crystal clear from the bindkey documentation what the
difference between "selecting <keymap>" and "binding it to main" is; I
think the former means "selecting <keymap> for use with any following
bindkey commands", doesn't it?  The latter definitely means "make the
keymap available for editing in the mode in which the line editor starts
up", and although it's a little bit obscure it has been explained in the
keymap documentation just above bindkey.  The doc there says the line
editor will "select" the main keymap, which means a completely different
thing from "select" in the bindkey docs, I think.

I'm sorry I started looking at this now.

-- 
Peter Stephenson <pws@csr.com>            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