General-purpose keymap management à-la Emacs.
This keymap library is inspired by Emacsy (
keymap.scm), which in turn is
inspired by Emacs.
The main types are:
keystructure has a hardware
code, a symbolic
value, an ordered set ofmodifiers (the order is to avoid inequality on permutation) and possibly morein the future.
Whitespaces are the only reserved characters. Anything else can be stored in the
keyspecis a string representation of a
keyspecis aspace-separated string representation of a sequence of =key=s.
keymapcontains a hash-table where the keys are a
keyspecand the valuesare either a keymap or anything else. As a special case, a
nilvalueunbinds the key.
- Support prefix keys to other keymaps. For instance, prefixing my-mode-mapwith
C-cmakes all bindings for my-mode accessible after pressing
- List all bindings matching a given prefix. (Also known as
- List the bindings associated to a command.
- Support multiple inheritance.
- Support keycode.
- Validate keyspec at compile time.
define-keycan set multiple bindings in a single call.
- Support multiple keyschemes to make it easy to switch between, say, Emacs-styleand VI-style bindings. This orthogonality to keymaps composes better thanhaving multiple keymaps: changing keyscheme applies to the entire program, whichis easier than looping through all keymaps to change them.
- Translate keyspecs as a fallback. For instance if
shift-ais unbound, check
- Customizable behaviour with global parameters such as
composefunction can merge multiple keymaps together.
- Support multiple arguments when that makes sense (e.g. multiple keymaps for
- Key remapping à-la Emacs.
- Typed keymaps, i.e. keymaps where bound values can only be of a given type.This is convenient to catch typos, for instance when binding ='FOO= instead of
- Customizable modifiers: the input system must decide how to map
- Dead key support: the input system must handle it.
- Fallback function when binding is not found: the caller of
nilwhen unbound, thus it can decide of a default behaviour.
- Provide a self-insert function: the caller must handle it.
- Global or local bindings: it's up to the calling application to manage thelocality of their keymaps.
(let* ((parent-keymap (nkeymaps:make-keymap "parent-keymap")) (my-keymap (nkeymaps:make-keymap "my-keymap" parent-keymap))) (nkeymaps:define-key parent-keymap "C-c" 'copy "C-v" 'paste) (nkeymaps:define-key my-keymap "C-x" 'cut) (values (nkeymaps:lookup-key "C-x" parent-keymap) (nkeymaps:lookup-key "C-x" my-keymap) (nkeymaps:lookup-key "C-c" my-keymap))) ;; => NIL, CUT, COPY
See the package documentation for a usage guide and more examples.
NKeymaps was originally developed for keymap management in Nyxt, so the "N" may stand for it, or "New", or whatever poetic meaning you may find behind it!
- Lookup order (for instance parent-first or next-keymap-first) should be customizable.
- For now
*translator*is a global, but ideally it would be part of thekeyscheme and keymap. But this would impact the lookup order, sincetranslations come after all the keymaps and their parents have been searched for.
keyscheme-map.It's more consistent and intuitive. The previous naming was really confusing.
- All warnings have now their own conditions, see the
define-keyscheme-maphas a different syntax, it's now
(define-keyscheme-map "NAME-PREFIX" (:import OPTIONAL-KEYSCHEME-MAP-TO-IMPORT) KEYSCHEME BINDINGS...)
- The predefined
keyscheme=s are now accessible from the =nkeymapspackage.
default=keyscheme= which is the new parent of other keyschemes(including
cua), instead of
*modifier-list*is no longer exported. Instead, both
modifiersslot for the modifiers they accept.
- Switched testing framework from
- Removed the