kofal.net/zmk
1
0
Fork 1
mirror of https://github.com/zmkfirmware/zmk.git synced 2026-03-21 05:25:18 -05:00
Code Issues Packages Projects Releases Wiki Activity

docs: Fix typos and inconsistent spellings (#1079)

Browse Source
This commit is contained in:
Evan Callicoat
2022-01-02 04:34:21 -06:00
committed by GitHub
parent 7b2edbad43
commit be343674de
5 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/docs/development/build-flash.md
View File

@@ -26,7 +26,7 @@ From here on, building and flashing ZMK should all be done from the `app/` subdi
cd app
```
To build for your particular keyboard, the behaviour varies slightly depending on if you are building for a keyboard with
To build for your particular keyboard, the behavior varies slightly depending on if you are building for a keyboard with
an onboard MCU, or one that uses an MCU board addon.
### Keyboard (Shield) + MCU Board

2
docs/docs/development/hardware-metadata-files.md
View File

@@ -100,7 +100,7 @@ Boards and shields should document the sets of hardware features found on them u
The `siblings` array is used to identify multiple hardware items designed to be used together as one logical device. Right now, that primarily is used to identify the two halves of a split keyboard, but future enhancements will include more complicated and flexible combinations.
The array should contrain the complete harware IDs of the siblings that combine in the logical device, e.g. with the `corne.zmk.yml` file:
The array should contain the complete hardware IDs of the siblings that combine in the logical device, e.g. with the `corne.zmk.yml` file:
```yaml
id: corne

2
docs/docs/development/new-shield.md
View File

@@ -360,7 +360,7 @@ The two `#include` lines at the top of the keymap are required in order to bring
Further documentation on behaviors and bindings is forthcoming, but a summary of the current behaviors you can bind to key positions is as follows:
- `kp` is the "key press" behavior, and takes a single binding argument of the key code from the 'keyboard/keypad" HID usage table.
- `mo` is the "momentary layer" behaviour, and takes a single binding argument of the numeric ID of the layer to momentarily enable when that key is held.
- `mo` is the "momentary layer" behavior, and takes a single binding argument of the numeric ID of the layer to momentarily enable when that key is held.
- `trans` is the "transparent" behavior, useful to be place in higher layers above `mo` bindings to be sure the key release is handled by the lower layer. No binding arguments are required.
- `mt` is the "mod-tap" behavior, and takes two binding arguments, the modifier to use if held, and the keycode to send if tapped.