Merge remote-tracking branch 'origin/develop' into xap

docs/cli_commands.md

@@ -17,12 +17,12 @@ qmk compile [-c] <configuratorExport.json>
 **Usage for Keymaps**:
 
 ```
-qmk compile [-c] [-e <var>=<value>] [-j <num_jobs>] [--compiledb] -kb <keyboard_name> -km <keymap_name>
+qmk compile [-c] [-e <var>=<value>] [-j <num_jobs>] [--compiledb] -kb <keyboard> -km <keymap>
 ```
 
 **Usage in Keyboard Directory**:
 
-Must be in keyboard directory with a default keymap, or in keymap directory for keyboard, or supply one with `--keymap <keymap_name>`
+Must be in keyboard directory with a default keymap, or in keymap directory for keyboard, or supply one with `--keymap <keymap>`
 ```
 qmk compile
 ```
@@ -30,7 +30,7 @@ qmk compile
 **Usage for building all keyboards that support a specific keymap**:
 
 ```
-qmk compile -kb all -km <keymap_name>
+qmk compile -kb all -km <keymap>
 ```
 
 **Example**:
@@ -62,7 +62,7 @@ $ qmk compile
 
 Must be under `qmk_firmware/layouts/`, and in a keymap folder.
 ```
-qmk compile -kb <keyboard_name>
+qmk compile -kb <keyboard>
 ```
 
 **Example**:
@@ -77,11 +77,11 @@ $ qmk compile -kb dz60
 
 It is possible to speed up compilation by adding the `-j`/`--parallel` flag.
 ```
-qmk compile -j <num_jobs> -kb <keyboard_name>
+qmk compile -j <num_jobs> -kb <keyboard>
 ```
 The `num_jobs` argument determines the maximum number of jobs that can be used. Setting it to zero will enable parallel compilation without limiting the maximum number of jobs.
 ```
-qmk compile -j 0 -kb <keyboard_name>
+qmk compile -j 0 -kb <keyboard>
 ```
 
 **Compilation Database**:
@@ -120,7 +120,7 @@ qmk flash [-bl <bootloader>] [-c] [-e <var>=<value>] [-j <num_jobs>] <configurat
 **Usage for Keymaps**:
 
 ```
-qmk flash -kb <keyboard_name> -km <keymap_name> [-bl <bootloader>] [-c] [-e <var>=<value>] [-j <num_jobs>]
+qmk flash -kb <keyboard> -km <keymap_name> [-bl <bootloader>] [-c] [-e <var>=<value>] [-j <num_jobs>]
 ```
 
 **Usage for pre-compiled firmwares**:

docs/hardware_keyboard_guidelines.md

@@ -71,8 +71,8 @@ Your keyboard should be located in `qmk_firmware/keyboards/` and the folder name
 * `keyboard.json` (or `info.json`)
 * `config.h`
 * `rules.mk`
-* `<keyboard_name>.c`
-* `<keyboard_name>.h`
+* `<keyboard>.c`
+* `<keyboard>.h`
 
 ### `readme.md`
 
@@ -203,7 +203,7 @@ The `post_rules.mk` file can interpret `features` of a keyboard-level before `co
 See `build_keyboard.mk` and `common_features.mk` for more details.
 :::
 
-### `<keyboard_name.c>`
+### `<keyboard.c>`
 
 This file should contain C code required for the functionality of your keyboard, for example hardware initialisation code, OLED display code, and so on. This file should only contain code necessary for the keyboard to work, and *not* things that should be left to the end user to configure in their keymap. This file is automatically included in compilation if it exists. This is not a required file.
 
@@ -214,9 +214,9 @@ The following functions are typically defined in this file:
 * `bool process_record_kb(uint16_t keycode, keyrecord_t *record)`
 * `bool led_update_kb(led_t led_state)`
 
-### `<keyboard_name.h>`
+### `<keyboard.h>`
 
-This file can contain function prototypes for custom functions and other header file code utilised by `<keyboard_name>.c`. The `<keyboard_name>.c` file should include this file. This is not a required file.
+This file can contain function prototypes for custom functions and other header file code utilised by `<keyboard>.c`. The `<keyboard>.c` file should include this file. This is not a required file.
 
 ## Image/Hardware Files
 

docs/newbs_building_firmware.md

@@ -33,7 +33,7 @@ qmk new-keymap
 If you did not configure your environment, or you have multiple keyboards, you can specify a keyboard name:
 
 ```sh
-qmk new-keymap -kb <keyboard_name>
+qmk new-keymap -kb <keyboard>
 ```
 
 Look at the output from that command, you should see something like this:

docs/newbs_flashing.md

@@ -60,7 +60,7 @@ open .
 The firmware file always follows this naming format:
 
 ```
-<keyboard_name>_<keymap_name>.{bin,hex}
+<keyboard>_<keymap>.{bin,hex}
 ```
 
 For example, the `planck/rev5` with a `default` keymap will have this filename:

docs/reference_info_json.md

@@ -2,7 +2,7 @@
 
 The information contained in `info.json` is combined with the `config.h` and `rules.mk` files, dynamically generating the necessary configuration for your keyboard at compile time. It is also used by the [QMK API](https://github.com/qmk/qmk_api), and contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. Its key/value pairs are ruled by the [`data/schemas/keyboard.jsonschema`](https://github.com/qmk/qmk_firmware/blob/master/data/schemas/keyboard.jsonschema) file. To learn more about the why and how of the schema file see the [Data Driven Configuration](data_driven_config) page.
 
-You can create `info.json` files at every level under `qmk_firmware/keyboards/<keyboard_name>`. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies information common to all Clueboard products, such as `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` contains more specific information about Clueboard 66%.
+You can create `info.json` files at every level under `qmk_firmware/keyboards/<keyboard>`. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies information common to all Clueboard products, such as `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` contains more specific information about Clueboard 66%.
 
 ## General Metadata {#general-metadata}