docs: Add syntax highlighting to more code blocks

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

docs/docs/features/backlight.md

@@ -16,7 +16,7 @@ Unlike [RGB Underglow](underglow.md), backlight can only control single color LE
 
 To enable backlight on your board or shield, add the following line to your `.conf` file of your user config directory as such:
 
-```
+```ini
 CONFIG_ZMK_BACKLIGHT=y
 ```
 
@@ -46,7 +46,7 @@ values={[
 
 First, you must enable PWM by adding the following lines to your `Kconfig.defconfig` file:
 
-```
+```kconfig
 if ZMK_BACKLIGHT
 
 config PWM
@@ -60,7 +60,7 @@ endif # ZMK_BACKLIGHT
 
 Then you have to add the following lines to your `.dts` file:
 
-```
+```dts
 &pwm0 {
     status = "okay";
     ch0-pin = <45>;
@@ -77,7 +77,7 @@ If your board uses a P-channel MOSFET to control backlight instead of a N-channe
 
 Then you have to add the following lines inside the root devicetree node on the same file as before:
 
-```
+```dts
 / {
     backlight: pwmleds {
         compatible = "pwm-leds";
@@ -98,7 +98,7 @@ Note that every LED inside of the backlight node will be treated as a backlight
 
 Finally you need to add backlight to the `chosen` element of the root devicetree node:
 
-```
+```dts
 / {
     chosen {
         zmk,backlight = &backlight;
@@ -113,7 +113,7 @@ You must first add a `boards/` directory within your shield folder. For each boa
 
 Inside your `<board>.defconfig` file, add the following lines:
 
-```
+```kconfig
 if ZMK_BACKLIGHT
 
 config PWM
@@ -127,7 +127,7 @@ endif # ZMK_BACKLIGHT
 
 Then add the following lines to your `.overlay` file:
 
-```
+```dts
 &pwm0 {
     status = "okay";
     ch0-pin = <45>;
@@ -144,7 +144,7 @@ If your shield uses a P-channel MOSFET to control backlight instead of a N-chann
 
 Then you have to add the following lines inside the root devicetree node on the same file:
 
-```
+```dts
 / {
     backlight: pwmleds {
         compatible = "pwm-leds";
@@ -165,7 +165,7 @@ Note that every LED inside of the backlight node will be treated as a backlight
 
 Finally you need to add backlight to the `chosen` element of the root devicetree node:
 
-```
+```dts
 / {
     chosen {
         zmk,backlight = &backlight;
@@ -175,7 +175,7 @@ Finally you need to add backlight to the `chosen` element of the root devicetree
 
 Optionally, on Pro Micro compatible shields you can add a LED GPIO node to your devicetree, this could be useful if you want your shield to be compatible with newer or untested boards. To do that you have to enable `CONFIG_LED_GPIO` in your `.conf` file and then add the following lines inside the root devicetree node of your `.dtsi` or `.dts` file:
 
-```
+```dts
 / {
     backlight: gpioleds {
         compatible = "gpio-leds";
@@ -199,7 +199,7 @@ It is possible to control multiple backlight LEDs at the same time. This is usef
 
 In order to do that, first you need to enable PWM for each pin:
 
-```
+```dts
 &pwm0 {
     status = "okay";
     ch0-pin = <45>; /* LED 0 */
@@ -213,7 +213,7 @@ This part may vary based on your MCU as different MCUs may have a different numb
 
 Then you can simply add each of your LED to the backlight node:
 
-```
+```dts
 backlight: pwmleds {
     compatible = "pwm-leds";
     label = "Backlight LEDs";

docs/docs/features/battery.md

@@ -26,7 +26,7 @@ Zephyr also provides some drivers for fuel gauge ICs such as the TI bq274xx seri
 
 Once you have the sensor driver defined, add a `zmk,battery` property to the `chosen` node and set it to reference the sensor node. For example:
 
-```
+```dts
 / {
     chosen {
       zmk,battery = &vbatt;

docs/docs/features/beta-testing.md

@@ -44,7 +44,7 @@ values={[
 ]}>
 <TabItem value="zmk">
 
-```
+```yaml
 manifest:
   remotes:
     - name: zmkfirmware
@@ -61,7 +61,7 @@ manifest:
 </TabItem>
 <TabItem value="macros">
 
-```
+```yaml
 manifest:
   remotes:
     - name: zmkfirmware
@@ -80,7 +80,7 @@ manifest:
 </TabItem>
 <TabItem value="sleep">
 
-```
+```yaml
 manifest:
   remotes:
     - name: zmkfirmware

docs/docs/features/bluetooth.md

@@ -42,7 +42,7 @@ Management of the bluetooth in ZMK is accomplished using the [`&bt` behavior](..
 
 Some users may experience a poor connection between the keyboard and the host. This might be due to poor quality BLE hardware, a metal enclosure on the keyboard or host, or the distance between them. Increasing the transmit power of the keyboard's BLE radio may reduce the severity of this problem. To do this, set the `CONFIG_BT_CTLR_TX_PWR_PLUS_8` configuration value in the `.conf` file of your user config directory as such:
 
-```
+```ini
 CONFIG_BT_CTLR_TX_PWR_PLUS_8=y
 ```
 
@@ -64,7 +64,7 @@ There are a few known issues related to BLE and ZMK:
 
 There is a known issue with Windows failing to update the battery information after connecting to a ZMK keyboard. You can work around this Windows bug by overriding a [Bluetooth config variable](../config/bluetooth.md) to force battery notifications even if a host neglects to subscribe to them:
 
-```
+```ini
 CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION=n
 ```
 

docs/docs/features/combos.md

@@ -10,7 +10,7 @@ Combo keys are a way to combine multiple keypresses to output a different key. F
 
 Combos configured in your `.keymap` file, but are separate from the `keymap` node found there, since they are processed before the normal keymap. They are specified like this:
 
-```
+```dts
 / {
     combos {
         compatible = "zmk,combos";

docs/docs/features/conditional-layers.md

@@ -14,7 +14,7 @@ Another way to think of this feature is as a simple combo system for layers, jus
 
 Conditional layers are configured via a `conditional_layers` node in your `.keymap` file as follows:
 
-```
+```dts
 / {
     conditional_layers {
         compatible = "zmk,conditional-layers";

docs/docs/features/debouncing.md

@@ -56,7 +56,7 @@ per-driver option.
 For example, if your board/shield has a kscan driver labeled `kscan0` in its
 `.overlay`, `.dts`, or `.dtsi` files,
 
-```devicetree
+```dts
 kscan0: kscan {
     compatible = "zmk,kscan-gpio-matrix";
     ...
@@ -65,7 +65,7 @@ kscan0: kscan {
 
 then you could add this to your `.keymap`:
 
-```devicetree
+```dts
 &kscan0 {
     debounce-press-ms = <3>;
     debounce-release-ms = <3>;

docs/docs/features/encoders.md

@@ -21,7 +21,7 @@ Keyboards and macropads with encoder support will typically take the two EC11 pi
 
 Rotation is handled separately as a type of sensor. The behavior for this is set in `sensor-bindings`. See [Sensor Rotation](../behaviors/sensor-rotate.md) for customizing this behavior.
 
-```
+```dts
 sensor-bindings = <BINDING [CW_KEY] [CCW_KEY]>;
 ```
 
@@ -33,7 +33,7 @@ Additional encoders can be configured by adding more bindings immediately after
 
 As an example, a complete `sensor-bindings` for a Kyria with two encoders could look like:
 
-```
+```dts
 sensor-bindings = <&inc_dec_kp C_VOL_UP C_VOL_DN &inc_dec_kp PG_UP PG_DN>;
 ```
 

docs/docs/features/keymaps.md

@@ -61,7 +61,7 @@ alter the behavior when that specific key position is activated/deactivated. For
 the "key press" (`kp`) behavior at a certain key position, you must specify _which_ keycode should
 be used for that key position.
 
-```
+```dts
 &kp A
 ```
 
@@ -69,7 +69,7 @@ In this case, the `A` is actually a define for the raw HID keycode, to make keym
 
 For example of a binding that uses two parameters, you can see how "mod-tap" (`mt`) is bound:
 
-```
+```dts
 &mt LSHIFT D
 ```
 
@@ -87,7 +87,7 @@ for what would otherwise be cryptic integer keycodes, etc. This also allows brin
 
 The top two lines of most keymaps should include:
 
-```
+```dts
 #include <behaviors.dtsi>
 #include <dt-bindings/zmk/keys.h>
 ```
@@ -100,7 +100,7 @@ The second include brings in the defines for all the keycodes (e.g. `A`, `N1`, `
 
 All the remaining keymap nodes will be nested inside of the root devicetree node, like so:
 
-```devicetree
+```dts
 / {
     // Everything else goes here!
 };
@@ -111,7 +111,7 @@ All the remaining keymap nodes will be nested inside of the root devicetree node
 Nested under the devicetree root, is the keymap node. The node _name_ itself is not critical, but the node **MUST** have a property
 `compatible = "zmk,keymap"` in order to be used by ZMK.
 
-```
+```dts
     keymap {
         compatible = "zmk,keymap";
 

docs/docs/features/underglow.md

@@ -28,7 +28,7 @@ Here you can see the RGB underglow feature in action using WS2812 LEDs.
 To enable RGB underglow on your board or shield, simply enable the `CONFIG_ZMK_RGB_UNDERGLOW` and `CONFIG_*_STRIP` configuration values in the `.conf` file for your board or shield.
 For example:
 
-```
+```ini
 CONFIG_ZMK_RGB_UNDERGLOW=y
 # Use the STRIP config specific to the LEDs you're using
 CONFIG_WS2812_STRIP=y
@@ -45,7 +45,7 @@ A common issue when enabling underglow is that some of the installed LEDs do not
 
 The number of underglow LEDs is controlled by the `chain-length` property in the `led_strip` node. You can [change the value of this property](../config/index.md#changing-devicetree-properties) in the `<keyboard>.keymap` file by adding a stanza like this one outside of any other node (i.e. above or below the `/` node):
 
-```
+```dts
 &led_strip {
     chain-length = <21>;
 };
@@ -70,7 +70,7 @@ With nRF52 boards, you can just use `&spi3` and define the pins you want to use.
 
 Here's an example on a definition that uses P0.06:
 
-```
+```dts
 #include <dt-bindings/led/led.h>
 
 &pinctrl {
@@ -135,7 +135,7 @@ For other boards, you must select an SPI definition that has the `MOSI` pin as y
 
 Here's another example for a non-nRF52 board on `spi3`:
 
-```
+```dts
 #include <dt-bindings/led/led.h>
 
 &spi3 {
@@ -161,7 +161,7 @@ Here's another example for a non-nRF52 board on `spi3`:
 
 Once you have your `led_strip` properly defined you need to add it to the root devicetree node `chosen` element:
 
-```
+```dts
 / {
     chosen {
         zmk,underglow = &led_strip;
@@ -171,7 +171,7 @@ Once you have your `led_strip` properly defined you need to add it to the root d
 
 Finally you need to enable the `CONFIG_ZMK_RGB_UNDERGLOW` and `CONFIG_*_STRIP` configuration values in the `.conf` file of your board (or set a default in the `Kconfig.defconfig`):
 
-```
+```ini
 CONFIG_ZMK_RGB_UNDERGLOW=y
 # Use the STRIP config specific to the LEDs you're using
 CONFIG_WS2812_STRIP=y