| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Key lookup is the process of finding the binding of a key sequence from a given keymap. Actual execution of the binding is not part of key lookup.
Key lookup uses just the event type of each event in the key sequence;
the rest of the event is ignored. In fact, a key sequence used for key
lookup may designate mouse events with just their types (symbols)
instead of with entire mouse events (lists). See section 21.6 Input Events. Such
a "key-sequence" is insufficient for command-execute to run,
but it is sufficient for looking up or rebinding a key.
When the key sequence consists of multiple events, key lookup processes the events sequentially: the binding of the first event is found, and must be a keymap; then the second event's binding is found in that keymap, and so on until all the events in the key sequence are used up. (The binding thus found for the last event may or may not be a keymap.) Thus, the process of key lookup is defined in terms of a simpler process for looking up a single event in a keymap. How that is done depends on the type of object associated with the event in that keymap.
Let's use the term keymap entry to describe the value found by
looking up an event type in a keymap. (This doesn't include the item
string and other extra elements in menu key bindings, because
lookup-key and other key lookup functions don't include them in
the returned value.) While any Lisp object may be stored in a keymap as
a keymap entry, not all make sense for key lookup. Here is a table of
the meaningful kinds of keymap entries:
nil
nil means that the events used so far in the lookup form an
undefined key. When a keymap fails to mention an event type at all, and
has no default binding, that is equivalent to a binding of nil
for that event type.
keymap, then the list
is a keymap, and is treated as a keymap (see above).
lambda, then the list is a
lambda expression. This is presumed to be a command, and is treated as
such (see above).
(othermap . othertype) |
When key lookup encounters an indirect entry, it looks up instead the binding of othertype in othermap and uses that.
This feature permits you to define one key as an alias for another key.
For example, an entry whose CAR is the keymap called esc-map
and whose CDR is 32 (the code for SPC) means, "Use the global
binding of Meta-SPC, whatever that may be."
Note that keymaps and keyboard macros (strings and vectors) are not
valid functions, so a symbol with a keymap, string, or vector as its
function definition is invalid as a function. It is, however, valid as
a key binding. If the definition is a keyboard macro, then the symbol
is also valid as an argument to command-execute
(see section 21.3 Interactive Call).
The symbol undefined is worth special mention: it means to treat
the key as undefined. Strictly speaking, the key is defined, and its
binding is the command undefined; but that command does the same
thing that is done automatically for an undefined key: it rings the bell
(by calling ding) but does not signal an error.
undefined is used in local keymaps to override a global key
binding and make the key "undefined" locally. A local binding of
nil would fail to do this because it would not override the
global binding.
In short, a keymap entry may be a keymap, a command, a keyboard macro,
a symbol that leads to one of them, or an indirection or nil.
Here is an example of a sparse keymap with two characters bound to
commands and one bound to another keymap. This map is the normal value
of emacs-lisp-mode-map. Note that 9 is the code for TAB,
127 for DEL, 27 for ESC, 17 for C-q and 24 for
C-x.
(keymap (9 . lisp-indent-line)
(127 . backward-delete-char-untabify)
(27 keymap (17 . indent-sexp) (24 . eval-defun)))
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |