docs: Add devicetree and kconfig syntax highlighting

docs/README.md

@@ -8,21 +8,21 @@ The ZMK Documentation is licensed [CC-BY-NC-SA](http://creativecommons.org/licen
 
 ### Installation
 
-```
+```sh
 $ npm ci
 ```
 
 ### Local Development
 
-```
+```sh
 $ npm start
 ```
 
 This command starts a local development server and open up a browser window. Most changes are reflected live without having to restart the server.
 
 ### Build
 
-```
+```sh
 $ npm build
 ```
 

docs/blog/2020-10-03-bootloader-fix.md

@@ -77,7 +77,7 @@ So first I enabled logging of the NVS module by adding
 `CONFIG_NVS_LOG_LEVEL_DBG=y` to my `.conf` file. I repeated the same test of
 spamming RGB underglow effect cycle and the resulting logs I got were this:
 
-```
+```log
 [00:00:00.000,671] <inf> fs_nvs: 8 Sectors of 4096 bytes
 [00:00:00.000,671] <inf> fs_nvs: alloc wra: 3, f70
 [00:00:00.000,671] <inf> fs_nvs: data wra: 3, f40
@@ -130,7 +130,7 @@ and [Dan Halbert](https://github.com/dhalbert) pointed me towards the [linker
 map](https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/linker/nrf52840.ld)
 of the nRF52840. Let's take a look.
 
-```
+```linker-script
 FLASH (rx) : ORIGIN = 0xF4000, LENGTH = 0xFE000-0xF4000-2048 /* 38 KB */
 
 BOOTLOADER_CONFIG (r): ORIGIN = 0xFE000 - 2048, LENGTH = 2048
@@ -166,7 +166,7 @@ Now that we've found the issue, we can pretty easily fix this. We'll need to
 move the settings flash area back so that it doesn't overlap with the
 bootloader. First we calculate the size of the of flash area the bootloader is using.
 
-```
+```linker-script
 0x100000 (end of flash) - 0x0F4000 (start of bootloader) = 0xC000 (48KB)
 ```
 

docs/blog/2020-11-09-zmk-sotf-3.md

@@ -30,7 +30,7 @@ This also laid the foundation for the other keymap related changes that are now
 
 [okke-formsma] added the ability to apply modifiers to a code, e.g.:
 
-```
+```dts
 &kp LC(C)
 ```
 
@@ -63,7 +63,7 @@ and nice!nano that have specialized hardware for this purpose.
 
 With this change, you can add
 
-```
+```dts
 &ext_power EP_TOG
 ```
 

docs/blog/2021-01-27-zmk-sotf-4.md

@@ -25,7 +25,7 @@ The initial [combos](/docs/features/combos) work has landed! The amazing [okke-f
 
 An example, that would send the `ESC` keycode when pressing both the first and second positions on your keyboard:
 
-```
+```dts
 / {
     combos {
         compatible = "zmk,combos";
@@ -46,13 +46,13 @@ Combos currently are "global", and not scoped to a given active layer. There is
 
 [okke-formsma] also contributed the initial "sticky keys" behavior, which can be used for functionality sometimes called "one shot mods" or "one shot layers". In your keymap, this would like like:
 
-```
+```dts
 &sk LEFT_CONTROL
 ```
 
 for a sticky key/modifier, or:
 
-```
+```dts
 &sl NAV
 ```
 
@@ -68,7 +68,7 @@ This is most frequently used when using multiple core base layers with different
 
 [okke-formsma] added an implementation of the "Grave Escape" behavior, developing a more generic "mod-morph" behavior to do so. Adding
 
-```
+```dts
 &gresc
 ```
 

docs/blog/2022-04-02-zephyr-3-0.md

@@ -29,12 +29,12 @@ Existing user config repositories using Github Actions to build will pull down Z
 - Change `zmkfirmware/zmk-build-arm:2.5` to `zmkfirmware/zmk-build-arm:stable` wherever it is found
 - Locate and delete the lines for the DTS output step, which is no longer needed:
 
-  ```
-    - name: ${{ steps.variables.outputs.display-name }} DTS File
-      if: ${{ always() }}
-      run: |
-        if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
-        if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
+  ```yaml
+  - name: ${{ steps.variables.outputs.display-name }} DTS File
+    if: ${{ always() }}
+    run: |
+      if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
+      if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
   ```
 
 :::note
@@ -76,7 +76,7 @@ The following changes have [already been completed](https://github.com/zmkfirmwa
 
 Zephyr's WS2812 `led_strip` driver added a new required property. When adding [underglow](/docs/features/underglow#adding-rgb-underglow-to-a-board) to a board, you now must also add the additional include `#include <dt-bindings/led/led.h>` at the top of your devicetree file, and add a `color-mapping` property like:
 
-```
+```dts
 led_strip: ws2812@0 {
   compatible = "worldsemi,ws2812-spi";
   label = "WS2812";
@@ -108,7 +108,7 @@ Zephyr moved to using a `chosen` node named `zephyr,display` to select the displ
 
 For example, for a shield with:
 
-```
+```dts
 &pro_micro_i2c {
   status = "okay";
 
@@ -132,7 +132,7 @@ For example, for a shield with:
 
 You would add a `chosen` node like:
 
-```
+```dts
 / {
   chosen {
     zephyr,display = &oled;
@@ -148,7 +148,7 @@ two sections of the `<board>.dts` file need updating.
 
 Underneath the USB device, add the CDC ACM node:
 
-```
+```dts
 &usbd {
   status = "okay";
   cdc_acm_uart: cdc_acm_uart {
@@ -160,7 +160,7 @@ Underneath the USB device, add the CDC ACM node:
 
 Then, an additional `chosen` node (near the top of the file) will mark the CDC ACM device as the console:
 
-```
+```dts
 / {
   chosen {
     ...
@@ -175,7 +175,7 @@ Then, an additional `chosen` node (near the top of the file) will mark the CDC A
 Previously, to get ZMK to build a UF2 image to flash to a given board required adding a `CMakeLists.txt` file that added a custom post build command.
 Now, the only thing necessary to have Zephyr build a UF2 is to add the following to your `<board>_defconfig` file:
 
-```
+```ini
 CONFIG_BUILD_OUTPUT_UF2=y
 ```
 
@@ -187,7 +187,7 @@ For more details on the implementation, see [zephyr#31066](https://github.com/ze
 
 Clock configuration moved to devicetree as well, out of the Kconfig files. Here is a sample config for a board that uses the HSI for the PLL source:
 
-```
+```dts
 &clk_hsi {
   status = "okay";
 };

docs/blog/2022-04-10-zmk-sotf-5.md

@@ -32,7 +32,7 @@ to the host capitalized until a non-alpha, non-"continue list" keycode is sent.
 
 [petejohanson], taking heavy inspiration on the initial work from [okke-formsma], added [macro support](/docs/behaviors/macros) in [#1168](https://github.com/zmkfirmware/zmk/pull/1166). Several [common patterns](/docs/behaviors/macros#common-patterns) are documented, but one example, changing the underglow color as you activate/deactivate a layer, looks like:
 
-```
+```dts
 ZMK_MACRO(layer_color_macro,
   wait-ms = <0>;
   tap-ms = <0>;
@@ -50,7 +50,7 @@ ZMK_MACRO(layer_color_macro,
 [kurtis-lew] worked diligently to add the [tap-dance behavior](/docs/behaviors/tap-dance) in [#1139](https://github.com/zmkfirmware/zmk/pull/1139), allowing different behaviors to be invoked based on the number of times
 a user taps a single key in their keymap, e.g.
 
-```
+```dts
 / {
     behaviors {
         td0: tap_dance_0 {
@@ -80,7 +80,7 @@ a user taps a single key in their keymap, e.g.
 
 Example:
 
-```
+```dts
 / {
     conditional_layers {
         compatible = "zmk,conditional-layers";
@@ -164,7 +164,7 @@ using "high voltage mode" with that SoC.
 
 [petejohanson]'s work on the HID foundation also included adding support for full NKRO HID in [#726](https://github.com/zmkfirmware/zmk/pull/726) that can be enabled by adding the following to your `.conf` file for your config:
 
-```
+```ini
 CONFIG_ZMK_HID_REPORT_TYPE_NKRO=y
 ```
 
@@ -176,7 +176,7 @@ It's been live for a while, but [nicell] added an amazing [power profiler](/powe
 
 [malinges](https://github.com/malinges) added support for configuring min/max underglow brightness in [#944](https://github.com/zmkfirmware/zmk/pull/944) by setting the values in your `.conf` file as percentages of full:
 
-```
+```ini
 CONFIG_ZMK_RGB_UNDERGLOW_BRT_MIN=20
 CONFIG_ZMK_RGB_UNDERGLOW_BRT_MAX=80
 ```

docs/blog/2023-04-06-zephyr-3-2.md

@@ -26,7 +26,7 @@ Existing user config repositories using Github Actions to build will pull down Z
 
 1.  Replace the contents of your `.github/workflows/build.yml` with:
 
-    ```
+    ```yaml
     on: [push, pull_request, workflow_dispatch]
 
     jobs:
@@ -36,7 +36,7 @@ Existing user config repositories using Github Actions to build will pull down Z
 
 1.  If it doesn't exist already, add a new file to your repository named `build.yaml`:
 
-    ```
+    ```yaml
     # This file generates the GitHub Actions matrix
     # For simple board + shield combinations, add them
     # to the top level board and shield arrays, for more
@@ -63,12 +63,12 @@ If you have a custom GitHub Actions workflow you need to maintain for some reaso
 - Change `zmkfirmware/zmk-build-arm:2.5` to `zmkfirmware/zmk-build-arm:stable` wherever it is found
 - Locate and delete the lines for the DTS output step, which is no longer needed:
 
-  ```
-    - name: ${{ steps.variables.outputs.display-name }} DTS File
-      if: ${{ always() }}
-      run: |
-        if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
-        if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
+  ```yaml
+  - name: ${{ steps.variables.outputs.display-name }} DTS File
+    if: ${{ always() }}
+    run: |
+      if [ -f "build/zephyr/${{ matrix.board }}.pre.tmp" ]; then cat -n build/zephyr/${{ matrix.board }}.pre.tmp; fi
+      if [ -f "build/zephyr/zephyr.dts" ]; then cat -n build/zephyr/zephyr.dts; fi
   ```
 
 ### VS Code & Docker (Dev Container)
@@ -107,7 +107,7 @@ A few testers have reported inconsistent issues with bluetooth connections on Wi
 
 Zephyr 3.2 introduced [a new Kconfig setting](https://github.com/zephyrproject-rtos/zephyr/pull/48929) that can be used to work around a bug in Windows related to battery reporting. Check out our [bluetooth config](/docs/config/bluetooth) for the full details. The key new configuration that can be set if using Windows is:
 
-```
+```ini
 CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION=n
 ```
 
@@ -133,7 +133,7 @@ The main area this affects existing shields is those with board specific overrid
 
 Previously in ZMK, we relied on per-driver devicetree source properties to set the alternate pin functions for things like SPI or I2C. For example, here is the I2C bus setup as it was previously on the `nice_nano` board:
 
-```
+```dts
 &i2c0 {
     compatible = "nordic,nrf-twi";
     sda-pin = <17>;
@@ -143,7 +143,7 @@ Previously in ZMK, we relied on per-driver devicetree source properties to set t
 
 With the move to the `pinctrl` system, this setup now look like:
 
-```
+```dts
  &i2c0 {
     compatible = "nordic,nrf-twi";
     pinctrl-0 = <&i2c0_default>;
@@ -154,7 +154,7 @@ With the move to the `pinctrl` system, this setup now look like:
 
 which references the `pinctrl` configuration:
 
-```
+```dts
 &pinctrl {
        i2c0_default: i2c0_default {
                group1 {
@@ -185,7 +185,7 @@ The approach is the following when updating a _board_:
 1. Add a new file with the naming convention `<board>-pinctrl.dtsi` to your board directory.
 1. In the new file, add your `pinctrl` entries that set up different pin control configurations for whatever peripherals/buses are needed. Here's the nice!nano file as an example:
 
-   ```
+   ```dts
    /*
    * Copyright (c) 2022 The ZMK Contributors
    * SPDX-License-Identifier: MIT
@@ -230,7 +230,7 @@ The approach is the following when updating a _board_:
 1. From the main `<board>.dts` file, add an `#include "<board>-pinctrl.dtsi"` to have the C-preprocessor combine the files.
 1. Update the various peripheral nodes to use the new `pinctrl` configurations. For example, the following old configuration:
 
-   ```
+   ```dts
    &i2c0 {
        compatible = "nordic,nrf-twi";
        sda-pin = <15>;
@@ -240,7 +240,7 @@ The approach is the following when updating a _board_:
 
    would be changed to:
 
-   ```
+   ```dts
    &i2c0 {
        compatible = "nordic,nrf-twi";
        pinctrl-0 = <&i2c0_default>;

docs/blog/2023-06-18-encoder-refactors.md

@@ -35,7 +35,7 @@ Splitting these two parts of the encoder configuration allows greater flexibilit
 
 Previously, an encoder configuration looked like:
 
-```
+```dts
     left_encoder: encoder_left {
         compatible = "alps,ec11";
         label = "LEFT_ENCODER";
@@ -47,7 +47,7 @@ Previously, an encoder configuration looked like:
 
 Here, the `resolution` property was used to indicate how many encoder pulses should trigger the sensor behavior one time. Next, the encoder is selected in the sensors node:
 
-```
+```dts
     sensors {
         compatible = "zmk,keymap-sensors";
         sensors = <&left_encoder &right_encoder>;
@@ -58,7 +58,7 @@ That was the entirety of the configuration for encoders.
 
 ### New Configuration
 
-```
+```dts
     left_encoder: encoder_left {
         compatible = "alps,ec11";
         label = "LEFT_ENCODER";
@@ -70,7 +70,7 @@ That was the entirety of the configuration for encoders.
 
 Here, the `steps` property is now used to indicate how many encoder pulses there are in a single complete rotation of the encoder. Next, the encoder is selected in the sensors node as before, but an additional configuration is used to indicate how many times the encoder should trigger the behavior in your keymap per rotation:
 
-```
+```dts
     sensors {
         compatible = "zmk,keymap-sensors";
         sensors = <&left_encoder &right_encoder>;
@@ -84,7 +84,7 @@ For tactile encoders that have detents, the `triggers-per-rotation` would match
 
 The configuration changes bring ZMK's code in line with how upstream Zephyr sensor drivers handle rotations. This has the added advantage of allowing us to leverage other sensor drivers. On Nordic MCUs, like nRF52840, the NRFX QDEC driver can be used, for example:
 
-```
+```dts
 &pinctrl {
     qdec_default: qdec_default {
         group1 {