chore: cleanup whitespace in docs (#26356)

docs/development/build-instructions-gn.md

@@ -6,9 +6,9 @@ Follow the guidelines below for building Electron.
 
 Check the build prerequisites for your platform before proceeding
 
-  * [macOS](build-instructions-macos.md#prerequisites)
-  * [Linux](build-instructions-linux.md#prerequisites)
-  * [Windows](build-instructions-windows.md#prerequisites)
+* [macOS](build-instructions-macos.md#prerequisites)
+* [Linux](build-instructions-linux.md#prerequisites)
+* [Windows](build-instructions-windows.md#prerequisites)
 
 ## Build Tools
 
@@ -74,6 +74,7 @@ Running `gclient sync -f` ensures that all dependencies required
 to build Electron match that file.
 
 So, in order to pull, you'd run the following commands:
+
 ```sh
 $ cd src/electron
 $ git pull
@@ -91,6 +92,7 @@ $ gn gen out/Testing --args="import(\"//electron/build/args/testing.gn\") $GN_EX
 ```
 
 Or on Windows (without the optional argument):
+
 ```sh
 $ cd src
 $ set CHROMIUM_BUILDTOOLS_PATH=%cd%\buildtools
@@ -124,11 +126,13 @@ $ gn gen out/Release --args="import(\"//electron/build/args/release.gn\") $GN_EX
 Nota Bene: This will also take a while and probably heat up your lap.
 
 For the testing configuration:
+
 ```sh
 $ ninja -C out/Testing electron
 ```
 
 For the release configuration:
+
 ```sh
 $ ninja -C out/Release electron
 ```
@@ -156,11 +160,13 @@ $ ./out/Testing/electron
 ### Packaging
 
 On linux, first strip the debugging and symbol information:
+
 ```sh
 electron/script/strip-binaries.py -d out/Release
 ```
 
 To package the electron build as a distributable zip file:
+
 ```sh
 ninja -C out/Release electron:electron_dist_zip
 ```
@@ -193,6 +199,7 @@ and [`target_cpu`][target_cpu values].
 [target_cpu values]: https://gn.googlesource.com/gn/+/master/docs/reference.md#built_in-predefined-variables-target_cpu_the-desired-cpu-architecture-for-the-build-possible-values
 
 #### Windows on Arm (experimental)
+
 To cross-compile for Windows on Arm, [follow Chromium's guide](https://chromium.googlesource.com/chromium/src/+/refs/heads/master/docs/windows_build_instructions.md#Visual-Studio) to get the necessary dependencies, SDK and libraries, then build with `ELECTRON_BUILDING_WOA=1` in your environment before running `gclient sync`.
 
 ```bat
@@ -201,6 +208,7 @@ gclient sync -f --with_branch_heads --with_tags
 ```
 
 Or (if using PowerShell):
+
 ```powershell
 $env:ELECTRON_BUILDING_WOA=1
 gclient sync -f --with_branch_heads --with_tags
@@ -208,7 +216,6 @@ gclient sync -f --with_branch_heads --with_tags
 
 Next, run `gn gen` as above with `target_cpu="arm64"`.
 
-
 ## Tests
 
 To run the tests, you'll first need to build the test modules against the
@@ -274,6 +281,7 @@ $ gclient sync -f
 ```
 
 ### I'm being asked for a username/password for chromium-internal.googlesource.com
+
 If you see a prompt for `Username for 'https://chrome-internal.googlesource.com':` when running `gclient sync` on Windows, it's probably because the `DEPOT_TOOLS_WIN_TOOLCHAIN` environment variable is not set to 0. Open `Control Panel` → `System and Security` → `System` → `Advanced system settings` and add a system variable
 `DEPOT_TOOLS_WIN_TOOLCHAIN` with value `0`.  This tells `depot_tools` to use
 your locally installed version of Visual Studio (by default, `depot_tools` will

docs/development/clang-format.md

@@ -30,6 +30,6 @@ run `git-clang-format HEAD~1`. See `git-clang-format -h` for more details.
 You can also integrate `clang-format` directly into your favorite editors.
 For further guidance on setting up editor integration, see these pages:
 
-  * [Atom](https://atom.io/packages/clang-format)
-  * [Vim & Emacs](https://clang.llvm.org/docs/ClangFormat.html#vim-integration)
-  * [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=xaver.clang-format)
+* [Atom](https://atom.io/packages/clang-format)
+* [Vim & Emacs](https://clang.llvm.org/docs/ClangFormat.html#vim-integration)
+* [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=xaver.clang-format)

docs/development/debugging-instructions-macos-xcode.md

@@ -1,10 +1,13 @@
 ## Debugging with XCode
 
 ### Generate xcode project for debugging sources (cannot build code from xcode)
+
 Run `gn gen` with the --ide=xcode argument.
+
 ```sh
 $ gn gen out/Testing --ide=xcode
 ```
+
 This will generate the electron.ninja.xcworkspace. You will have to open this workspace
 to set breakpoints and inspect.
 

docs/development/debugging-instructions-macos.md

@@ -24,6 +24,7 @@ you prefer a graphical interface.
   debugging C, Objective-C and C++ on the desktop and iOS devices and simulator.
 
 * **.lldbinit**: Create or edit `~/.lldbinit` to allow Chromium code to be properly source-mapped.
+
    ```text
    command script import ~/electron/src/tools/lldb/lldbinit.py
    ```
@@ -120,6 +121,7 @@ Now, if you open up Electron's developer tools and call `setName`, you will once
 breakpoint.
 
 ### Further Reading
+
 LLDB is a powerful tool with a great documentation. To learn more about it, consider
 Apple's debugging documentation, for instance the [LLDB Command Structure Reference][lldb-command-structure]
 or the introduction to [Using LLDB as a Standalone Debugger][lldb-standalone].

docs/development/patches.md

@@ -41,6 +41,7 @@ To help manage these patch sets, we provide two tools: `git-import-patches` and
 ### Usage
 
 #### Adding a new patch
+
 ```bash
 $ cd src/third_party/electron_node
 $ vim some/code/file.cc
@@ -53,6 +54,7 @@ $ ../../electron/script/git-export-patches -o ../../electron/patches/node
 Re-exporting patches will sometimes cause shasums in unrelated patches to change. This is generally harmless and can be ignored (but go ahead and add those changes to your PR, it'll stop them from showing up for other people).
 
 #### Editing an existing patch
+
 ```bash
 $ cd src/v8
 $ vim some/code/file.cc
@@ -64,6 +66,7 @@ $ ../electron/script/git-export-patches -o ../electron/patches/v8
 ```
 
 #### Removing a patch
+
 ```bash
 $ vim src/electron/patches/node/.patches
 # Delete the line with the name of the patch you want to remove
@@ -76,6 +79,7 @@ $ ../../electron/script/git-export-patches -o ../../electron/patches/node
 Note that `git-import-patches` will mark the commit that was `HEAD` when it was run as `refs/patches/upstream-head`. This lets you keep track of which commits are from Electron patches (those that come after `refs/patches/upstream-head`) and which commits are in upstream (those before `refs/patches/upstream-head`).
 
 #### Resolving conflicts
+
 When updating an upstream dependency, patches may fail to apply cleanly. Often, the conflict can be resolved automatically by git with a 3-way merge. You can instruct `git-import-patches` to use the 3-way merge algorithm by passing the `-3` argument:
 
 ```bash

docs/development/pull-requests.md

@@ -35,6 +35,7 @@ $ git fetch upstream
 
 Build steps and dependencies differ slightly depending on your operating system.
 See these detailed guides on building Electron locally:
+
 * [Building on macOS](https://electronjs.org/docs/development/build-instructions-macos)
 * [Building on Linux](https://electronjs.org/docs/development/build-instructions-linux)
 * [Building on Windows](https://electronjs.org/docs/development/build-instructions-windows)
@@ -96,16 +97,16 @@ Examples of commit messages with semantic prefixes:
 
 Common prefixes:
 
-  - fix: A bug fix
-  - feat: A new feature
-  - docs: Documentation changes
-  - test: Adding missing tests or correcting existing tests
-  - build: Changes that affect the build system
-  - ci: Changes to our CI configuration files and scripts
-  - perf: A code change that improves performance
-  - refactor: A code change that neither fixes a bug nor adds a feature
-  - style: Changes that do not affect the meaning of the code (linting)
-  - vendor: Bumping a dependency like libchromiumcontent or node
+- fix: A bug fix
+- feat: A new feature
+- docs: Documentation changes
+- test: Adding missing tests or correcting existing tests
+- build: Changes that affect the build system
+- ci: Changes to our CI configuration files and scripts
+- perf: A code change that improves performance
+- refactor: A code change that neither fixes a bug nor adds a feature
+- style: Changes that do not affect the meaning of the code (linting)
+- vendor: Bumping a dependency like libchromiumcontent or node
 
 Other things to keep in mind when writing a commit message:
 
@@ -257,4 +258,3 @@ failure must be manually inspected to determine the cause.
 CI starts automatically when you open a pull request, but only
 core maintainers can restart a CI run. If you believe CI is giving a
 false negative, ask a maintainer to restart the tests.
-

docs/development/source-code-directory-structure.md

@@ -90,6 +90,7 @@ Electron
 * **out** - Temporary output directory of `ninja`.
 * **script** - Scripts used for development purpose like building, packaging,
   testing, etc.
+
 ```diff
 script/ - The set of all scripts Electron runs for a variety of purposes.
 ├── codesign/ - Fakes codesigning for Electron apps; used for testing.
@@ -98,8 +99,8 @@ script/ - The set of all scripts Electron runs for a variety of purposes.
     ├── notes/ - Generates release notes for new Electron versions.
     └── uploaders/ - Uploads various release-related files during release.
 ```
+
 * **tools** - Helper scripts used by GN files.
   * Scripts put here should never be invoked by users directly, unlike those in `script`.
 * **typings** - TypeScript typings for Electron's internal code.
 * **vendor** - Source code for some third party dependencies.
-

docs/development/testing.md

@@ -56,10 +56,13 @@ would run `npm run test -- -g ipc`.
 
 1. Visual Studio 2019 must be installed.
 2. Node headers have to be compiled for your configuration.
+
    ```powershell
    ninja -C out\Testing third_party\electron_node:headers
    ```
+
 3. The electron.lib has to be copied as node.lib.
+
    ```powershell
    cd out\Testing
    mkdir gen\node_headers\Release
@@ -69,6 +72,7 @@ would run `npm run test -- -g ipc`.
 #### Missing fonts
 
 [Some Windows 10 devices](https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list) do not ship with the Meiryo font installed, which may cause a font fallback test to fail. To install Meiryo:
+
 1. Push the Windows key and search for _Manage optional features_.
 2. Click _Add a feature_.
 3. Select _Japanese Supplemental Fonts_ and click _Install_.
@@ -80,5 +84,6 @@ devices with Hi-DPI screen settings due to floating point precision errors.
 To run these tests correctly, make sure the device is set to 100% scaling.
 
 To configure display scaling:
+
 1. Push the Windows key and search for _Display settings_.
 2. Under _Scale and layout_, make sure that the device is set to 100%.