Add a spellchecking mode for sphinx and fix some typos

* The worst one was Persistant -> Persistent. This involved renaming
  PersistentConfig but the impact of that is considered minimal enough to be
  worth fixing.

docs/window/capture_attach.rst

@@ -18,7 +18,7 @@ The Program section of the dialog prompts for the executable to be launched, the
 
 .. figure:: ../imgs/Screenshots/CapturePathCmdline.png
 
-  Program Capture: Configuring and launching an exe directly from RenderDoc.
+  Program Capture: Configuring and launching an executable directly from RenderDoc.
 
 The :guilabel:`...` buttons next to the executable path and working directory can be used to browse through the file system. If you are working in :doc:`a remote context <../how/how_network_capture_replay>` then the file and directory browser will be replaced by one that browses in the file system of the remote context. By default if the working directory box is left empty then the directory containing the executable will be used as the working directory.
 
@@ -156,7 +156,7 @@ This option is slightly different from the others in that it doesn't change anyt
 
 This option allows you to queue up a precise capture of a given frame number after the program has started.
 
-Queueing up a capture beginning at frame 0 has a special meaning: Frames are defined as the period between two presents of a window. Frame 0 is defined as starting at initialisation and ending at the first presentation.
+Queuing up a capture beginning at frame 0 has a special meaning: Frames are defined as the period between two presents of a window. Frame 0 is defined as starting at initialisation and ending at the first presentation.
 
 The definition of 'initialisation' varies by API, since it can be hard to clearly define initialisation time cleanly:
 
@@ -191,17 +191,17 @@ Global Process Hook
 
 To expose this option you have to enable it in :doc:`the settings <settings_window>`, to prevent it being used accidentally.
 
-When you've entered a path, or filename, in the executable text at the top of the window, this option will then insert a global hook that causes **every** new process created to load a very small shim dll.
+When you've entered a path, or filename, in the executable text at the top of the window, this option will then insert a global hook that causes **every** new process created to load a very small shim DLL.
 
-The shim dll will load, create a thread that checks to see if the process matches the path or filename specified, and then unload. If the process matches it will also inject RenderDoc and capturing will continue as normal. At this point you should *first disable the global hook*, then you can use the 'Attach to running instance' menu option to continue as normal.
+The shim DLL will load, create a thread that checks to see if the process matches the path or filename specified, and then unload. If the process matches it will also inject RenderDoc and capturing will continue as normal. At this point you should *first disable the global hook*, then you can use the 'Attach to running instance' menu option to continue as normal.
 
-RenderDoc implements this behaviour by modifying the `AppInit_DLLs <http://support2.microsoft.com/kb/197571>`_ registry key to reference RenderDoc's dlls. This is not a particularly safe method but it's the only reliable method to do what we want. The shim dll is deliberately made as small and thin as possible, referencing only ``kernel32.dll``, to minimise any risks.
+RenderDoc implements this behaviour by modifying the `AppInit_DLLs <http://support2.microsoft.com/kb/197571>`_ registry key to reference RenderDoc's DLLs. This is not a particularly safe method but it's the only reliable method to do what we want. The shim DLL is deliberately made as small and thin as possible, referencing only ``kernel32.dll``, to minimise any risks.
 
 .. note::
 
   If you have 'secure boot' enabled in Windows, the AppInit_DLLs registry key will not work. To use the global process hook you must disable secure boot.
 
-If RenderDoc crashes or something otherwise goes wrong while these registry keys are modified, the shim dll will continue to be injected into every process which is certainly not desirable. Should anything go wrong, RenderDoc writes a ``.reg`` file that restores the registry to its previous state in ``%TEMP%``.
+If RenderDoc crashes or something otherwise goes wrong while these registry keys are modified, the shim DLL will continue to be injected into every process which is certainly not desirable. Should anything go wrong, RenderDoc writes a ``.reg`` file that restores the registry to its previous state in ``%TEMP%``.
 
 Again, **this method should be a last resort**. Given the risks you should always try to capture directly in some way before trying this.
 

docs/window/capture_connection.rst

@@ -55,7 +55,7 @@ During running or after the application has closed, all captures will appear as
 
 	Connection Window: Viewing multiple captures taken in a program.
 
-In this example we have a connection window open to the debugmarker sample from Sascha Willms' Vulkan examples. Three captures have been made and we can see their thumbnails to help distinguish between them. This is visible at any point, regardless of whether you have close the program or not - you can simply switch back to RenderDoc while it's running.
+In this example we have a connection window open to the ``debugmarker`` sample from `Sascha Willems' Vulkan examples <https://github.com/SaschaWillems/Vulkan>`_. Three captures have been made and we can see their thumbnails to help distinguish between them. This is visible at any point, regardless of whether you have close the program or not - you can simply switch back to RenderDoc while it's running.
 
 .. note::
 

docs/window/event_browser.rst

@@ -116,7 +116,7 @@ The left and right arrows go into and out of hierarchy levels. When within a lev
 
 .. note::
 
-	This window supports copy and paste, so simply select the entries and ctrl-c to copy to the clipboard
+	This window supports copy and paste, so simply select the entries and :kbd:`Ctrl-C` to copy to the clipboard
 
 Bookmarks
 ---------

docs/window/mesh_viewer.rst

@@ -79,11 +79,11 @@ To select which element will be displayed as secondary, simply right click on th
 
 The selection will be remembered as long as the mesh format stays consistent between actions.
 
-You can also use this if the position data isn't detected in your inputs and you'd like to choose which element contains the positions, or if you'd like to visualise some other data such as UV co-ordinates as positional (in effect rendering the mesh in uv-space).
+You can also use this if the position data isn't detected in your inputs and you'd like to choose which element contains the positions, or if you'd like to visualise some other data such as UV co-ordinates as positional (in effect rendering the mesh in UV-space).
 
 .. figure:: ../imgs/Screenshots/SolidPreview.png
 
-	Preview: Previewing the uv co-ordinates as color on the mesh.
+	Preview: Previewing the UV co-ordinates as color on the mesh.
 
 When displaying the post-projection output - typically the VS output, but possibly tessellation/geometry output - you can select how much data to display.
 

docs/window/settings_window.rst

@@ -253,8 +253,8 @@ Other custom tools can be configured, but for those the command line arguments m
 * ``{input_file}`` will be replaced by the input filename.
 * ``{output_file}`` will be replaced by the output filename.
 * ``{entry_point}`` will be replaced by the entry point name, only when compiling a shader.
-* ``{glsl_stage4}`` will be replaced by the glsl stage short-hand, one of: vert, tesc, tese, geom, frag, or comp.
-* ``{hlsl_stage2}`` will be replaced by the hlsl stage short-hand, one of: vs, hs, ds, gs, ps, or cs.
+* ``{glsl_stage4}`` will be replaced by the glsl stage short-hand, one of: ``vert``, ``tesc``, ``tese``, ``geom``, ``frag``, or ``comp``.
+* ``{hlsl_stage2}`` will be replaced by the hlsl stage short-hand, one of: ``vs``, ``hs``, ``ds``, ``gs``, ``ps``, or ``cs``.
 * ``{spirv_ver}`` will be replaced by the SPIR-V version in use, e.g. spirv1.2 or spirv1.6.
 * ``{vulkan_ver}`` will be replaced by the Vulkan-identified SPIR-V version in use, e.g. vulkan1.0 or vulkan1.3. This value may be lossy, and will pick the next *lowest* version that compiles with a given SPIR-V version. E.g. SPIR-V 1.2 was not used by a vulkan version, so will be rounded down to vulkan1.0.
 

docs/window/texture_viewer.rst

@@ -344,7 +344,7 @@ These overlays are only relevant when the currently selected action is a rasteri
 
 * ``Quad Overdraw (Draw)`` will show a similar visualisation to the above option, but limited only to the current drawcall.
 
-* ``Triangle Size (Pass)`` will show a visualisation of how much pixel area triangles in the meshes are covering in the 'pass' up to the selected draw, up to 4x4 pixels (16 square px) at most. If the current API does not have the concept of a pass, it is defined as all the drawcalls with the same set of render targets.
+* ``Triangle Size (Pass)`` will show a visualisation of how much pixel area triangles in the meshes are covering in the 'pass' up to the selected draw, up to 4x4 pixels (16 square pixels) at most. If the current API does not have the concept of a pass, it is defined as all the drawcalls with the same set of render targets.
 
 * ``Triangle Size (Draw)`` will show a similar visualisation to the above option, but limited only to the current drawcall.