keybind: Complemented hierarchy information
This commit is contained in:
parent
1fed4d2c17
commit
0baf79c120
1 changed files with 47 additions and 15 deletions
|
|
@ -80,27 +80,59 @@ Some terminology
|
||||||
|
|
||||||
In general a keybinding json shows this hierarchy:
|
In general a keybinding json shows this hierarchy:
|
||||||
|
|
||||||
```
|
>[]($block.attrs('tree'))
|
||||||
Mode > Imode > press > Key and commands
|
>`flow.json` `<-- keybindings for flow mode`
|
||||||
map > map > array > array(array(string,numbers),strings,numbers)
|
>`{`
|
||||||
```
|
>* "project": { `<-- imode`
|
||||||
|
> * "press": [ `<-- react when press`
|
||||||
|
> * ["ctrl+alt+shift+r", "restart"], `<-- the keys with commands`
|
||||||
|
> *
|
||||||
|
> * ]
|
||||||
|
>* },
|
||||||
|
>* "normal": [ `<-- imode`
|
||||||
|
> * "inherit": "project" `<-- Inherits all the keypresses and reactions from project`
|
||||||
|
> * "press": [ `<- custom actions for normal imode`
|
||||||
|
> * ["ctrl+z", "undo"],
|
||||||
|
> *
|
||||||
|
> * ],
|
||||||
|
> * "release": [ `<-- normal imode also reacts when some keys are released`
|
||||||
|
> * ["left_control", "disable_jump_mode"], `<-- no more jumping when left control is released`
|
||||||
|
> * ]
|
||||||
|
>* ],
|
||||||
|
>* "select": { "cursor":"block" }, `<-- imode with a cursor change`
|
||||||
|
>* "home": { "on_match_failure": "ignore" }, `<-- imode`
|
||||||
|
>* "overlay/palette": { } `<-- keys are handled by a palette`
|
||||||
|
>* "mini/numeric": { } `<-- minimodes also handle actions`
|
||||||
|
>* `}`
|
||||||
|
|
||||||
`Mode` is the json file that holds a map, where each entry has a map
|
|
||||||
called `press` that is an array of arrays.
|
|
||||||
|
|
||||||
`project` is the main imode in `flow.json` and it can be noticed that
|
`project` is the main imode in `flow.json`, mapping many combo key down
|
||||||
`normal` imode `inherits` from `project`, some modes have `release`,
|
presses.
|
||||||
usually one will be using only `press` inside `normal` imode or the
|
|
||||||
specific mode if inside `vim`, `helix` or `emacs` modes.
|
Notice that `normal` imode `inherits` from `project`, meaning all the
|
||||||
|
key presses handled by project react the same way in normal, which also
|
||||||
|
extends with other keypresses. `normal` also captures key
|
||||||
|
releases, we show a sample when the control key is released,
|
||||||
|
stopping jumping mode inside flow.json.
|
||||||
|
|
||||||
|
`SELECT` imode inherits from normal and shows a different cursor to
|
||||||
|
remind it is the current one.
|
||||||
|
|
||||||
|
`home` mode is shown when no buffer is open and if the user presses
|
||||||
|
keys that are not explicitly handled to bring mental peace to the
|
||||||
|
user.
|
||||||
|
|
||||||
|
`overlay/palette` gets active when a
|
||||||
|
[palette](/docs/architecture) is active.
|
||||||
|
|
||||||
Looking further, it can be seen that
|
Looking further, it can be seen that
|
||||||
[minimodes](/docs/architecture/minimode) have their own keybinding
|
[minimodes](/docs/architecture/minimode) have their own keybinding
|
||||||
mappings defined in a particular imode.
|
mappings defined in a particular imode, the same as palettes.
|
||||||
|
|
||||||
As stated previously, there is a mode hierarchy, the main mode is flow
|
As stated previously, there is a mode hierarchy, the main mode is flow
|
||||||
and other modes inherit from it. We remind that also imodes have a
|
and other modes inherit from it. Each mode inherits, extends and
|
||||||
hierarchy and it's common for major imodes to be descendants from
|
overrides actions and define their internal imodes extending as
|
||||||
`project`.
|
required each minimode.
|
||||||
|
|
||||||
[]($section.id('adding'))
|
[]($section.id('adding'))
|
||||||
## Adding a Keybinding
|
## Adding a Keybinding
|
||||||
|
|
@ -134,7 +166,7 @@ the `f5` key.
|
||||||
`create_scratchbuffer` is invoked receiving the parameter `*test*`
|
`create_scratchbuffer` is invoked receiving the parameter `*test*`
|
||||||
which results in creating a scratch buffer if didn't exist. And then
|
which results in creating a scratch buffer if didn't exist. And then
|
||||||
executing the command `shell_execute_insert` that receives the
|
executing the command `shell_execute_insert` that receives the
|
||||||
paramaters `zig`, `build`, `test`. This latter command is executing
|
parameters `zig`, `build`, `test`. This latter command is executing
|
||||||
a shell command called `zig` with the parameters `build` and `test`;
|
a shell command called `zig` with the parameters `build` and `test`;
|
||||||
if you don't have zig installed, it will not work, and you might
|
if you don't have zig installed, it will not work, and you might
|
||||||
want to remap `f5` to a different shell command.
|
want to remap `f5` to a different shell command.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue