docs: Add syntax highlighting to more code blocks

Added language tags to more code blocks in the documentation to enable
syntax highlighting.

docs/docs/development/build-flash.md

@@ -76,13 +76,13 @@ For split keyboards, you will have to build and flash each side separately the f
 
 By default, the `build` command outputs a single .uf2 file named `zmk.uf2` so building left and then right immediately after will overwrite your left firmware. In addition, you will need to pristine build each side to ensure the correct files are used. To avoid having to pristine build every time and separate the left and right build files, we recommend setting up separate build directories for each half. You can do this by using the `-d` parameter and first building left into `build/left`:
 
-```
+```sh
 west build -d build/left -b nice_nano -- -DSHIELD=kyria_left
 ```
 
 and then building right into `build/right`:
 
-```
+```sh
 west build -d build/right -b nice_nano -- -DSHIELD=kyria_right
 ```
 
@@ -99,7 +99,7 @@ Instead of building .uf2 files using the default keymap and config files, you ca
 
 For instance, building kyria firmware from a user `myUser`'s `zmk-config` folder on Windows 10 may look something like this:
 
-```
+```sh
 west build -b nice_nano -- -DSHIELD=kyria_left -DZMK_CONFIG="C:/Users/myUser/Documents/Github/zmk-config/config"
 ```
 
@@ -117,7 +117,7 @@ volume automatically -- we need to delete the default volume before binding it t
 
 Then you can bind the `zmk-config` volume to the correct path pointing to your local [zmk-config](customization.md) folder:
 
-```
+```sh
 docker volume create --driver local -o o=bind -o type=none -o \
     device="/full/path/to/your/zmk-config/" zmk-config
 ```
@@ -137,7 +137,7 @@ Alternatively, if your board supports flashing and you're not developing from
 within a Dockerized environment, enable Device Firmware Upgrade (DFU) mode on
 your board and run the following command to flash:
 
-```
+```sh
 west flash
 ```
 

docs/docs/development/ide-integration.md

@@ -71,7 +71,7 @@ If you are developing inside a Docker container, set the IntelliSense mode to `l
 
 Open VS Code's integrated terminal and run the following command:
 
-```
+```sh
 cmake -P zephyr/cmake/verify-toolchain.cmake
 ```
 

docs/docs/development/new-behavior.md

@@ -357,7 +357,7 @@ For behaviors that do not require central locality, the following options for up
 
 For the purpose of this section, we will discuss the structure of `app/dts/behaviors/gresc.dtsi` below.
 
-```dtsi title="app/dts/behaviors/gresc.dtsi"
+```dts title="app/dts/behaviors/gresc.dtsi"
 /*
  * Copyright (c) 2020 The ZMK Contributors
  *
@@ -383,7 +383,7 @@ The format of a behavior's `.dtsi` file is identical to declaring an instance of
 
 After creating the `.dtsi` from above, update `app/dts/behaviors.dtsi` to include your newly predefined behavior instance, making it accessible by the devicetree.
 
-```dtsi title="app/dts/behaviors.dtsi"
+```dts title="app/dts/behaviors.dtsi"
 #include <behaviors/key_press.dtsi>
 #include <behaviors/transparent.dtsi>
 #include <behaviors/none.dtsi>

docs/docs/development/new-shield.md

@@ -53,7 +53,7 @@ shield to get it picked up for ZMK, `Kconfig.shield` and `Kconfig.defconfig`.
 
 The `Kconfig.shield` file defines any additional Kconfig settings that may be relevant when using this keyboard. For most keyboards, there is just one additional configuration value for the shield itself.
 
-```
+```kconfig
 config SHIELD_MY_BOARD
     def_bool $(shields_list_contains,my_board)
 ```
@@ -62,7 +62,7 @@ This will make sure that a new configuration value named `SHIELD_MY_BOARD` is se
 
 **For split boards**, you will need to add configurations for the left and right sides. For example, if your split halves are named `my_board_left` and `my_board_right`, it would look like this:
 
-```
+```kconfig
 config SHIELD_MY_BOARD_LEFT
     def_bool $(shields_list_contains,my_board_left)
 
@@ -83,7 +83,7 @@ The updated new default values should always be wrapped inside a conditional on
 The keyboard name must be less than or equal to 16 characters in length, otherwise the bluetooth advertising might fail and you will not be able to find your keyboard from your device.
 :::
 
-```
+```kconfig
 if SHIELD_MY_BOARD
 
 config ZMK_KEYBOARD_NAME
@@ -97,7 +97,7 @@ You'll also want to set which half is the central side. Most boards set it to th
 Then on the peripheral half, you'll want to turn USB on so that it shows USB status on displays properly.
 Finally, you'll want to turn on the split option for both sides. This can all be seen below.
 
-```
+```kconfig
 if SHIELD_MY_BOARD_LEFT
 
 config ZMK_KEYBOARD_NAME
@@ -136,7 +136,7 @@ values={[
 The `<shield_name>.overlay` is the devicetree description of the keyboard shield that is merged with the primary board devicetree description before the build. For ZMK, this file at a minimum should include the chosen node named `zmk,kscan` that references a KSCAN driver instance. For a simple 3x3 macropad matrix,
 this might look something like:
 
-```
+```dts
 / {
     chosen {
         zmk,kscan = &kscan0;
@@ -174,7 +174,7 @@ Unlike unibody keyboards, split keyboards have a core .dtsi file with shield ove
 It is preferred to define only the `col-gpios` or `row-gpios` in the common shield .dtsi, depending on the `diode-direction` value.
 For `col2row` directed boards like the iris, the shared .dtsi file may look like this:
 
-```
+```dts
 #include <dt-bindings/zmk/matrix_transform.h>
 
 / {
@@ -228,9 +228,7 @@ Furthermore, the column offset for the [matrix transform](#optional-matrix-trans
 because the keyboard's switch matrix is read from left to right, top to bottom.
 This is exemplified with the iris .overlay files.
 
-```
-// iris_left.overlay
-
+```dts title=iris_left.overlay
 #include "iris.dtsi" // Notice that the main dtsi files are included in the overlay.
 
 &kscan0 {
@@ -245,9 +243,7 @@ This is exemplified with the iris .overlay files.
 };
 ```
 
-```
-// iris_right.overlay
-
+```dts title=iris_right.overlay
 #include "iris.dtsi"
 
 &default_transform { // The matrix transform for this board is 6 columns over because the left half is 6 columns wide according to the matrix.
@@ -281,9 +277,7 @@ For example, a split board called `my_awesome_split_board` would have the follow
 
 In most case you'll only need to use the .conf file that affects both halves of a split board. It's used for adding features like deep-sleep or rotary encoders.
 
-```
-// my_awesome_split_board.conf
-
+```ini title=my_awesome_split_board.conf
 CONFIG_ZMK_SLEEP=y
 ```
 
@@ -306,7 +300,7 @@ the logical key location as perceived by the end user. All _keymap_ mappings act
 
 _Without_ a matrix transform, that intentionally map each key position to the row/column pair that position corresponds to, the default equation to determine that is:
 
-```
+```c
 ($row * NUMBER_OF_COLUMNS) + $column
 ```
 
@@ -316,7 +310,7 @@ Whenever that default key position mapping is insufficient, the `<shield_name>.o
 
 Here is an example for the [nice60](https://github.com/Nicell/nice60), which uses an efficient 8x8 GPIO matrix, and uses a transform:
 
-```
+```dts
 #include <dt-bindings/zmk/matrix_transform.h>
 
 / {
@@ -419,7 +413,7 @@ values={[
 
 In your configuration file you will need to add the following lines so that the encoders can be enabled/disabled:
 
-```
+```ini
 # Uncomment to enable encoder
 # CONFIG_EC11=y
 # CONFIG_EC11_TRIGGER_GLOBAL_THREAD=y
@@ -435,7 +429,7 @@ If building locally for split boards, you may need to add these lines to the spe
 <TabItem value = "dtsi">
 In your device tree file you will need to add the following lines to define the encoder sensor:
 
-```
+```dts
 left_encoder: encoder_left {
         compatible = "alps,ec11";
         label = "LEFT_ENCODER";
@@ -452,8 +446,8 @@ Add additional encoders as necessary by duplicating the above lines, replacing `
 
 Once you have defined the encoder sensors, you will have to add them to the list of sensors:
 
-```
-sensors {
+```dts
+    sensors {
         compatible = "zmk,keymap-sensors";
         sensors = <&left_encoder &right_encoder>;
     };
@@ -465,7 +459,7 @@ In this example, a left_encoder and right_encoder are both added. Additional enc
 <TabItem value = "overlay">
 Add the following lines to your overlay file(s) to enable the encoder:
 
-```
+```dts
 &left_encoder {
     status = "okay";
 };
@@ -479,7 +473,7 @@ For split keyboards, make sure to add left hand encoders to the left .overlay fi
 <TabItem value = "keymap">
 Add the following line to your keymap file to add default encoder behavior bindings:
 
-```
+```dts
 sensor-bindings = <&inc_dec_kp C_VOL_UP C_VOL_DN>;
 ```
 
@@ -493,7 +487,7 @@ Add additional bindings as necessary to match the default number of encoders on
 Once you've fully created the new keyboard shield definition,
 you should be able to test with a build command like:
 
-```
+```sh
 west build --pristine -b proton_c -- -DSHIELD=my_board
 ```
 
@@ -506,7 +500,7 @@ Alternatively, if your board supports flashing and you're not developing from
 within a Dockerized environment, enable Device Firmware Upgrade (DFU) mode on
 your board and run the following command to test your build:
 
-```
+```sh
 west flash
 ```
 

docs/docs/development/posix-board.md

@@ -14,7 +14,7 @@ with a compiler that can target 32-bit POSIX.
 
 On Debian, you can do this with:
 
-```
+```sh
 apt install -y gcc-multilib
 ```
 
@@ -23,7 +23,7 @@ apt install -y gcc-multilib
 To do this, you can build ZMK targeting the
 `native_posix_64` board.
 
-```
+```sh
 west build --pristine --board native_posix_64 -- -DZMK_CONFIG=tests/none/normal/
 ```
 

docs/docs/development/usb-logging.md

@@ -33,7 +33,7 @@ In Github Actions, you can check the `<Keyboard> Kconfig file` step output to ve
 for you successfully.
 :::
 
-```
+```ini
 # Turn on logging, and set ZMK logging to debug output
 CONFIG_ZMK_USB_LOGGING=y
 ```
@@ -53,7 +53,7 @@ values={[
 
 On Linux, this should be a device like `/dev/ttyACM0` and you can connect with `minicom` or `tio` as usual, e.g.:
 
-```
+```sh
 sudo tio /dev/ttyACM0
 ```
 
@@ -74,7 +74,7 @@ If you already have the Ardunio IDE installed you can also use its built-in Seri
 On macOS, the device name is something like `/dev/tty.usbmodemXXXXX` where `XXXXX` is some numerical ID.
 You can connect to the device with [tio](https://tio.github.io/) (can be installed via [Homebrew](https://formulae.brew.sh/formula/tio)):
 
-```
+```sh
 sudo tio /dev/tty.usbmodem14401
 ```