Re: $KEYMAP in command, isearch and menuselect

[Peter Stephenson <Peter.Stephenson@csr.com>]

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