minor typo fix (#2863)

doc/cascadia/TerminalSettings-spec.md

@@ -33,7 +33,7 @@ This spec will outline how various terminal frontends will be able to interact w
 5. Visual Studio should be able to persist and edit settings globally, without
    the need for a globals/profiles structure.
 6. The Terminal should be able to read information from a settings structure
-   that's independant of how it's persisted / implemented by the Application
+   that's independent of how it's persisted / implemented by the Application
 7. The Component should be able to have its own settings independent of the
    application that's embedding it, such as font size and face, scrollbar
    visibility, etc. These should be settings that are specific to the component,
@@ -79,7 +79,7 @@ Shell Commandline       |
 
 ### Simple Settings
 
-An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specifc to Project Cascadia.
+An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specific to Project Cascadia.
 
 ### Interface Descriptions
 
@@ -228,6 +228,6 @@ I don't like that - if we change the font size, we should just recalculate how m
 ## Questions / TODO
 * How does this interplay with setting properties of the terminal component in XAML?
     * I would think that the component would load the XAML properties first, and if the controlling application calls `UpdateSettings` on the component, then those in-XAML properties would likely get overwritten.
-    * It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entriely in XAML, go right ahead.
+    * It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entirely in XAML, go right ahead.
     * Any settings that *are* exposed through XAML properties *should* also be exposed in the component's settings implementation as well.
         * Can that be enforced any way? I doubt it.

doc/cascadia/Unittesting-CppWinRT-Xaml.md

@@ -82,7 +82,7 @@ project from our `TerminalAppLib` project:
   <ItemGroup>
     <!-- Manually add references to each of our dependent winmds. Mark them as
     private=false and CopyLocalSatelliteAssemblies=false, so that we don't
-    propogate them upwards (which can make referencing this project result in
+    propagate them upwards (which can make referencing this project result in
     duplicate type definitions)-->
 
     <Reference Include="Microsoft.Terminal.Settings">
@@ -106,7 +106,7 @@ in the dll project's directory.
 
 ### Update the dll project
 
-Now that we havea lib that builds all your code, we can go ahead and tear out
+Now that we have a lib that builds all your code, we can go ahead and tear out
 most of the dead code from the old dll project. Remove all the source files from
 the dll's `.vcxproj` file, save for the `pch.h` and `pch.cpp` files. You _may_
 need to leave the headers for any C++/WinRT types you've authored in this project
@@ -301,7 +301,7 @@ you want to use any XAML types, then you'll have to keep reading.
 
 ### Using Xaml Types (with XAML Islands)
 
-To be able to instatiate XAML types in your unittest, we'll need to make use of
+To be able to instantiate XAML types in your unittest, we'll need to make use of
 the [XAML Hosting
 API](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api)
 (Xaml Islands). This enables you to use XAML APIs from a Win32 context.

doc/specs/#532 - Panes and Split Windows.md

@@ -26,7 +26,7 @@ Windows Terminal.
 Panes within the context of a single terminal window are not a new idea. The
 design of the panes for the Windows Terminal was heavily inspired by the
 application `tmux`, which is a commandline application which acts as a "terminal
-multiplexer", allowing for the easy managment of many terminal sessions from a
+multiplexer", allowing for the easy management of many terminal sessions from a
 single application.
 
 Other applications that include pane-like functionality include (but are not
@@ -115,7 +115,7 @@ We could also split `A` in horizontally, creating a fourth terminal pane `D`.
   +---------------+
 ```
 
-While it may appear that there's a single horizonal separator and a single
+While it may appear that there's a single horizontal separator and a single
 vertical separator here, that's not actually the case. Due to the tree-like
 structure of the pane splitting, the horizontal splits exist only between the
 two panes they're splitting. So, the user could move each of the horizontal
@@ -230,5 +230,5 @@ for swapping the positions of tabs, or a shortcut for both "zooming" a tab
 tab. Additionally, a right-click menu option could be added to do the
 aformentioned actions. Discoverability of these two actions is not as high as
 just dragging a tab from one pane to another; however, it's believed that panes
-are more of a power-user scenario, and power users will not neccessarily be
+are more of a power-user scenario, and power users will not necessarily be
 turned off by the feature's discoverability.

doc/specs/#754 - Cascading Default Settings.md

@@ -36,7 +36,7 @@ Largely inspired by the settings model that both VS Code (and Sublime Text) use.
 ### Goal: Minimize Re-Serializing `profiles.json`
 
 We want to re-serialize the user settings file, `profiles.json`, as little as
-possible. Each time we serialize the file, there's the possiblity that we've
+possible. Each time we serialize the file, there's the possibility that we've
 re-ordered the keys, as `jsoncpp` provides no ordering guarantee of the keys.
 This isn't great, as each write of the file will randomly re-order the file.
 
@@ -241,7 +241,7 @@ Currently, these profiles are only generated when a user first launches the
 Terminal. If they already have a `profiles.json` file, then we won't run the
 auto-generation behavior. This is obviously not great - if any new types of
 dynamic profiles are added, then users that already have the Terminal installed
-won't get any of these dynamic profiles. Furthemore, if any of the sources of
+won't get any of these dynamic profiles. Furthermore, if any of the sources of
 these dynamic profiles are removed, then the app won't auto-remove the
 associated profile.
 
@@ -695,7 +695,7 @@ generators _must_ be enabled to use the dynamic profiles.
   feature spec.
   - We'll also want to make sure that when we're serializing default/dynamic
     profiles, we take into account the state from the global defaults, and we
-    don't duplicate that inormation into the entries for those types of profiles
+    don't duplicate that information into the entries for those types of profiles
     in the user profiles.
 * **Re-ordering profiles** - Under "Solution Design", we provide an algorithm
   for decoding the settings. One of the steps mentioned is parsing the user

doc/specs/#976 - VT52 escape sequences.md

@@ -84,7 +84,7 @@ Key             | Sequence
 
 With <kbd>Num Lock</kbd> disabled, most of the keys on the numeric keypad function the same as cursor keys or editing keys, but with the addition of a center <kbd>5</kbd> key. As a described above, the cursor keys generate a simple ESC prefix instead of CSI or SS3, while the editing keys remain unchanged (with the exception of modifiers).
 
-In V52 mode, most modifiers are ignored, except for <kbd>Shift</kbd>, which is the equivalent of enabling <kbd>Num Lock</kbd> (i.e. the keys just generate their corresponding digit characters or `.`). With <kbd>Num Lock</kbd> enabled, it's the other way arround - the digits are generated by default, while <kbd>Shift</kbd> enables the cursor/editing functionality.
+In V52 mode, most modifiers are ignored, except for <kbd>Shift</kbd>, which is the equivalent of enabling <kbd>Num Lock</kbd> (i.e. the keys just generate their corresponding digit characters or `.`). With <kbd>Num Lock</kbd> enabled, it's the other way around - the digits are generated by default, while <kbd>Shift</kbd> enables the cursor/editing functionality.
 
 Key          | Alias | ANSI mode | VT52 mode
 -------------|-------|-----------|-----------