Added more examples to the Stringy Keymaps docs
Rearranged text Removed blank lines Fixed "string name" to "string" Enclosed string in single qutoes
This commit is contained in:
		| @@ -1,6 +1,7 @@ | ||||
| # Stringy Keymaps | ||||
|  | ||||
| Enables referring to keys by `'NAME'` rather than `KC.NAME`. | ||||
| Enables referring to keys by `'NAME'` rather than `KC.NAME`.\ | ||||
| This extension allows for a seamless integration of both string-based key references and standard keycodes. | ||||
|  | ||||
| For example: | ||||
|  | ||||
| @@ -13,6 +14,9 @@ from kmk.extensions.stringy_keymaps import StringyKeymaps | ||||
| # Indexed | ||||
| # keyboard.keymap = [[ KC['A'], KC['B'], KC['RESET'] ]] | ||||
|  | ||||
| # String names mixed with normal keycodes | ||||
| # keyboard.keymap = [[ 'A' , KC.B, KC.RESET ]] | ||||
|  | ||||
| # String names | ||||
| keyboard.keymap = [[ 'A' , 'B', 'RESET' ]] | ||||
|  | ||||
| @@ -27,3 +31,5 @@ keyboard.extensions.append(stringyKeymaps) | ||||
|  | ||||
| It should be noted that these are **not** ASCII. The string is **not** what | ||||
| will be sent to the computer. The examples above have no functional difference. | ||||
|  | ||||
| When utilizing layer keycodes, such as `KC.MO(layer)`, it's not possible to use a string like `'MO(layer)'` instead employ the standard notation of e.g. `KC.MO(1)` in your keymap. | ||||
		Reference in New Issue
	
	Block a user