Migrate spelling-0.0.21 changes from main

# Conflicts:
#	src/cascadia/WindowsTerminal/main.cpp
#	src/renderer/dx/DxRenderer.hpp

NuGet.Config

@@ -1,14 +1,24 @@
 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
     <packageSources>
-        <clear />
-        <!-- Dependencies that we can turn on to force override for testing purposes before uploading. -->
+        <add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />
+        <!-- Add repositories here to the list of available repositories -->
+        
+        <!-- Dependencies that we must carry because they're not on public nuget feeds right now. -->
         <!--<add key="Static Package Dependencies" value="dep\packages" />-->
+        
+        <!-- Use our own NuGet Feed -->
         <add key="TerminalDependencies" value="https://pkgs.dev.azure.com/ms/terminal/_packaging/TerminalDependencies/nuget/v3/index.json" />
+		
+		<!-- Temporarily? use the feeds from our friends in MUX for Helix test stuff -->
+		<add key="dotnetfeed" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" />
+        <add key="dnceng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
+        <add key="MUX-Dependencies" value="https://pkgs.dev.azure.com/ms/microsoft-ui-xaml/_packaging/MUX-Dependencies/nuget/v3/index.json" />
+        
+        <!-- Internal NuGet feeds that may not be accessible outside Microsoft corporate network -->
+        <!--<add key="TAEF - internal" value="https://microsoft.pkgs.visualstudio.com/DefaultCollection/_packaging/Taef/nuget/v3/index.json" />
+        <add key="OpenConsole - Internal" value="https://microsoft.pkgs.visualstudio.com/_packaging/OpenConsole/nuget/v3/index.json" />-->
     </packageSources>
-    <disabledPackageSources>
-        <clear />
-    </disabledPackageSources>
     <config>
         <add key="repositorypath" value=".\packages" />
     </config>

OpenConsole.sln

@@ -313,6 +313,24 @@ Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalTestNetCore", "s
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890} = {84848BFA-931D-42CE-9ADF-01EE54DE7890}
 	EndProjectSection
 EndProject
+Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ScratchWinRTServer", "src\tools\ScratchWinRTServer\ScratchWinRTServer.vcxproj", "{D46D9547-F085-4645-B8F7-E8CD21559AB4}"
+	ProjectSection(ProjectDependencies) = postProject
+		{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
+		{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {CA5CAD1A-ABCD-429C-B551-8562EC954746}
+		{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
+		{48D21369-3D7B-4431-9967-24E81292CF62} = {48D21369-3D7B-4431-9967-24E81292CF62}
+	EndProjectSection
+EndProject
+Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ScratchWinRTClient", "src\tools\ScratchWinRTClient\ScratchWinRTClient.vcxproj", "{06382349-D62A-4C7D-A7D3-9CA817EAE092}"
+	ProjectSection(ProjectDependencies) = postProject
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4} = {D46D9547-F085-4645-B8F7-E8CD21559AB4}
+	EndProjectSection
+EndProject
+Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ScratchIsland", "src\tools\ScratchIsland\ScratchIsland.vcxproj", "{23A1F736-CD19-4196-980F-84BCD50CF783}"
+	ProjectSection(ProjectDependencies) = postProject
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4} = {D46D9547-F085-4645-B8F7-E8CD21559AB4}
+	EndProjectSection
+EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "wt", "src\cascadia\wt\wt.vcxproj", "{506FD703-BAA7-4F6E-9361-64F550EC8FCA}"
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Settings.Model.Lib", "src\cascadia\TerminalSettingsModel\Microsoft.Terminal.Settings.ModelLib.vcxproj", "{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}"
@@ -1985,6 +2003,90 @@ Global
 		{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|DotNet_x86Test.Build.0 = Release|x86
 		{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|x64.ActiveCfg = Release|Any CPU
 		{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|x86.ActiveCfg = Release|Any CPU
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|Any CPU.ActiveCfg = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|Any CPU.Build.0 = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|ARM64.ActiveCfg = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|ARM64.Build.0 = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|DotNet_x64Test.Build.0 = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|DotNet_x86Test.Build.0 = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|x64.ActiveCfg = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|x64.Build.0 = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|x86.ActiveCfg = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.AuditMode|x86.Build.0 = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|Any CPU.ActiveCfg = Debug|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|ARM64.ActiveCfg = Debug|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|x64.ActiveCfg = Debug|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|x64.Build.0 = Debug|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|x86.ActiveCfg = Debug|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Debug|x86.Build.0 = Debug|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|Any CPU.ActiveCfg = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|ARM64.ActiveCfg = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|x64.ActiveCfg = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|x64.Build.0 = Release|x64
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|x86.ActiveCfg = Release|Win32
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4}.Release|x86.Build.0 = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|Any CPU.ActiveCfg = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|Any CPU.Build.0 = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|ARM64.ActiveCfg = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|ARM64.Build.0 = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|DotNet_x64Test.Build.0 = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|DotNet_x86Test.Build.0 = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|x64.ActiveCfg = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|x64.Build.0 = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|x86.ActiveCfg = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.AuditMode|x86.Build.0 = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|Any CPU.ActiveCfg = Debug|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|ARM64.ActiveCfg = Debug|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|x64.ActiveCfg = Debug|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|x64.Build.0 = Debug|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|x86.ActiveCfg = Debug|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Debug|x86.Build.0 = Debug|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|Any CPU.ActiveCfg = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|ARM64.ActiveCfg = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|x64.ActiveCfg = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|x64.Build.0 = Release|x64
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|x86.ActiveCfg = Release|Win32
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092}.Release|x86.Build.0 = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|Any CPU.ActiveCfg = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|Any CPU.Build.0 = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|ARM64.ActiveCfg = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|ARM64.Build.0 = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|DotNet_x64Test.Build.0 = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|DotNet_x86Test.Build.0 = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|x64.ActiveCfg = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|x64.Build.0 = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|x86.ActiveCfg = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.AuditMode|x86.Build.0 = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|Any CPU.ActiveCfg = Debug|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|ARM64.ActiveCfg = Debug|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|x64.ActiveCfg = Debug|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|x64.Build.0 = Debug|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|x86.ActiveCfg = Debug|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Debug|x86.Build.0 = Debug|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|Any CPU.ActiveCfg = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|ARM64.ActiveCfg = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|x64.ActiveCfg = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|x64.Build.0 = Release|x64
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|x86.ActiveCfg = Release|Win32
+		{23A1F736-CD19-4196-980F-84BCD50CF783}.Release|x86.Build.0 = Release|Win32
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
@@ -2169,6 +2271,9 @@ Global
 		{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {59840756-302F-44DF-AA47-441A9D673202}
 		{6BAE5851-50D5-4934-8D5E-30361A8A40F3} = {81C352DB-1818-45B7-A284-18E259F1CC87}
 		{1588FD7C-241E-4E7D-9113-43735F3E6BAD} = {59840756-302F-44DF-AA47-441A9D673202}
+		{D46D9547-F085-4645-B8F7-E8CD21559AB4} = {A10C4720-DCA4-4640-9749-67F4314F527C}
+		{06382349-D62A-4C7D-A7D3-9CA817EAE092} = {A10C4720-DCA4-4640-9749-67F4314F527C}
+		{23A1F736-CD19-4196-980F-84BCD50CF783} = {A10C4720-DCA4-4640-9749-67F4314F527C}
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA} = {59840756-302F-44DF-AA47-441A9D673202}
 		{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {59840756-302F-44DF-AA47-441A9D673202}
 		{CA5CAD1A-082C-4476-9F33-94B339494076} = {59840756-302F-44DF-AA47-441A9D673202}

doc/cascadia/profiles.schema.json

@@ -694,7 +694,7 @@
               "enum": [
                 "mru",
                 "inOrder",
-                "disabled"
+                "disabled",
               ],
               "type": "string"
             }
@@ -702,7 +702,7 @@
           "deprecated": true
         },
         "tabSwitcherMode": {
-          "default": "inOrder",
+          "default": true,
           "description": "When set to \"true\" or \"mru\", the \"nextTab\" and \"prevTab\" commands will use the tab switcher UI, with most-recently-used ordering. When set to \"inOrder\", these actions will switch tabs in their current ordering. Set to \"false\" to disable the tab switcher.",
           "oneOf": [
             {
@@ -712,7 +712,7 @@
               "enum": [
                 "mru",
                 "inOrder",
-                "disabled"
+                "disabled",
               ],
               "type": "string"
             }
@@ -753,16 +753,7 @@
         },
         "backgroundImage": {
           "description": "Sets the file location of the image to draw over the window background.",
-          "oneOf": [
-            {
-              "type": ["string", null]
-            },
-            {
-              "enum": [
-                "desktopWallpaper"
-              ]
-            }
-          ]
+          "type": ["string", "null"]
         },
         "backgroundImageAlignment": {
           "default": "center",

doc/specs/Proto extensions-spec.md

@@ -1,385 +0,0 @@
----
-author: <Pankaj> <Bhojwani> <@PankajBhojwani>
-created on: <2020-9-9>
-last updated: <2020-10-15>
----
-
-# Proto extensions
-
-## Abstract
-
-This spec outlines adding support for proto extensions. This would allow other apps/programs
-to add json snippets to our json files, and will be used when we generate settings for our various profiles.
-
-## Inspiration
-
-### Goal: Allow programs to have a say in the settings for their profiles
-
-Currently, Ubuntu/WSL/Powershell etc are unable to provide any specifications for how they want
-their profiles in Terminal to look - only we and the users can modify the profiles. We want to provide
-these installations with the functionality to have a say in this, allowing them to specify things like
-their icon, their font and so on. However, we want to maintain that the user has final say over all of
-these settings.
-
-## Solution Design
-
-Currently, when we load the settings we perform the following steps (this is a simplified description,
-for the full version see the [spec for cascading default + user settings](https://github.com/microsoft/terminal/blob/master/doc/specs/%23754%20-%20Cascading%20Default%20Settings.md)):
-
-1. Generate profiles from the defaults file
-2. Generate profiles from the dynamic profile generators
-3. Layer the user settings on top of all the profiles created in steps 1 and 2
-4. Validate the settings
-
-To allow for installations to add in their snippets of json, I propose the addition of a new step
-in between 2 and 3:
-
-1. Generate profiles from the defaults file
-2. Generate profiles from the dynamic profile generators
-3. **Incorporate the additional provided json stubs** - these stubs could be:
-   1. modifications to existing profiles
-   2. additions of full profiles
-   3. additions of colour schemes
-4. Layer the user settings on top of all the profiles created in steps 1 through 3 (this includes the user-defined default settings which they wish to apply to all profiles)
-5. Validate the settings
-
-### Specifications of the json stubs
-
-As written above, the json stubs could be modifications to existing profiles, additions to full profiles, or additions of colour schemes.
-
-To allow modifications/additions of several profiles in one file and to allow the addition of several colour schemes in one json file,
-these stubs should be put into lists in the json file: one list named ```profiles``` and the other list named ```schemes```. For example:
-
-```js
-{
-    "profiles": [ modifications and additions of profiles go here ],
-    "schemes": [ additions of colour schemes go here ]
-}
-```
-
-An example of a full json file with these fields filled out is shown at the end of this section.
-
-#### Modifications to existing profiles
-
-The main thing to note for modification of existing profiles is that this will only be used for modifying the
-default profiles (cmd/powershell) or the dynamically generated profiles.
-
-For modifications to existing profiles, the json stub would need to indicate which profile it wishes to modify. It will
-do this by providing the corresponding guid in the `"updates"` field of the json stub. The reason we use an `"updates"`
-field rather than a `"guid"` field (like the way the user settings are eventually layered onto profiles) is because we
-do not want to mistakenly create a new profile when the stub was meant to update a profile that did not exist.
-
-Note that currently, we generate a GUID for dynamic profiles using the "initial" name of the profile (i.e. before
-any user changes are applied). For example, the "initial" name of a WSL profile is the \<name\> argument to
-"wsl.exe -d \<name\>", and the "initial" name of a Powershell profile is something like "Powershell (ARM)" - depending
-on the version. Thus, the stub creator could simply use the same uuidv5 GUID generator we do on that name to obtain the
-GUID. Then, in the stub they provide the GUID can be used to identify which profile to modify.
-
-Naturally, we will have to provide documentation on how they could generate the desired GUID themselves. In that documentation,
-we will also provide examples showing how the current GUIDs are generated for clarity's sake.
-
-We need to inform developers that **we will not** prescribe any ordering to the way in which these modifications will be
-applied - thus, they should not rely on their stub being the first/last to modify a particular profile (in the event that
-there is more than one json stub modifying the same profile).
-
-Here is an example of a json file that modifies an existing profile (specifically the Azure cloud shell profile):
-
-```js
-{
-    "profiles": [
-        {
-            "updates": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
-            "fontSize": 16,
-            "fontWeight": "thin"
-        }
-    ]
-}
-```
-
-**NOTE**: This will *not* change the way the profile looks in the user's settings file. The Azure cloud shell profile
-in their settings file (assuming they have made no changes) will still be as below.
-
-```js
-{
-    "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
-    "hidden": false,
-    "name": "Azure Cloud Shell",
-    "source": "Windows.Terminal.Azure"
-}
-```
-However, the user is free to make changes to it as usual and those changes will have the 'final say'.
-
-#### Full profile stubs
-
-Technically, full profile stubs do not need to contain anything (they could just be '\{\}'). However we should
-have some qualifying minimum criteria before we accept a stub as a full profile. I suggest that we only create
-new profile objects from stubs that contain at least the following
-
-* A name
-
-As in the case of the dynamic profile generator, if we create a profile that did not exist before (i.e. does not
-exist in the user settings), we need to add the profile to the user settings file and re-save that file.
-
-Furthermore, we will add a source field to profiles created this way (again, similar to what we do for dynamic profiles).
-The source field value is dependent on how we obtained this json file, and will be touched on in more detail [later in the spec](#the-source-field).
-
-Here is an example of a json file that contains a full profile:
-
-```js
-{
-    "profiles": [
-        {
-            "guid": "{a821ae62-9d4a-3e34-b989-0a998ec283e6}",
-            "name": "Cool Profile",
-            "commandline": "powershell.exe",
-            "antialiasingMode": "aliased",
-            "fontWeight": "bold",
-            "scrollbarState": "hidden"
-        }
-    ]
-}
-```
-
-When this profile gets added back to the user's settings file, it will look similar to the way we currently add
-new dynamic profiles to the user's settings file. Going along with the example above, the corresponding
-json stub in the user's settings file will be:
-
-```js
-{
-    "guid": "{a821ae62-9d4a-3e34-b989-0a998ec283e6}",
-    "name": "Cool Profile",
-    "hidden": "false",
-    "source": "local"
-}
-```
-Again, the user will be able to make changes to it as they do for all other profiles.
-
-#### Creation of colour schemes
-
-As with full profiles, we will have some qualifying criteria for what we accept as full colour schemes: color schemes
-must have _all_ the fields that define a colour scheme - see the
-[docs](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/color-schemes)
-on creating new colour schemes for what this means.
-
-This may cause the issue of colour schemes being overridden if there are many creations of a colour scheme with the
-same name. Since for now all we have to uniquely identify colour schemes *is* the name, we will just let this be.
-
-Here is an example of a json stub that contains a colour scheme:
-
-```js
-{
-    "schemes": [
-        {
-            "name": "Postmodern Tango Light",
-
-            "cursorColor": "#FFFFFF",
-            "selectionBackground": "#FFFFFF",
-
-            "background": '#61D6D6',
-            "foreground": '#E74856',
-
-            "black" : "#0C0C0C",
-            "blue" : "#0037DA",
-            "cyan" : "#3A96DD",
-            "green" : "#13A10E",
-            "purple" : "#881798",
-            "red" : "#C50F1F",
-            "white" : "#CCCCCC",
-            "yellow" : "#C19C00",
-            "brightBlack" : "#767676",
-            "brightBlue" : "#3B78FF",
-            "brightCyan" : "#61D6D6",
-            "brightGreen" : "#16C60C",
-            "brightPurple" : "#B4009E",
-            "brightRed" : "#E74856",
-            "brightWhite" : "#F2F2F2",
-            "brightYellow" : "#F9F1A5"
-        }
-    ]
-}
-```
-
-This stub will *not* show up in the users settings file, similar to the way our default colour schemes do not show up.
-
-#### Example of a full json file
-This is an example of a json file that combines all the above examples. Thus, this json file modifies the Azure Cloud
-Shell profile, creates a new profile called 'Cool Profile' and creates a new colour scheme called 'Postmodern Tango Light'.
-
-```js
-{
-  "profiles": [
-    {
-      "updates": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
-      "fontSize": 16,
-      "fontWeight": "thin"
-    },
-    {
-      "guid": "{a821ae62-9d4a-3e34-b989-0a998ec283e6}",
-      "name": "Cool Profile",
-      "commandline": "powershell.exe",
-      "antialiasingMode": "aliased",
-      "fontWeight": "bold",
-      "scrollbarState": "hidden"
-    }
-  ],
-  "schemes": [
-    {
-        "name": "Postmodern Tango Light",
-
-        "cursorColor": "#FFFFFF",
-        "selectionBackground": "#FFFFFF",
-
-        "background": '#61D6D6',
-        "foreground": '#E74856',
-
-        "black" : "#0C0C0C",
-        "blue" : "#0037DA",
-        "cyan" : "#3A96DD",
-        "green" : "#13A10E",
-        "purple" : "#881798",
-        "red" : "#C50F1F",
-        "white" : "#CCCCCC",
-        "yellow" : "#C19C00",
-        "brightBlack" : "#767676",
-        "brightBlue" : "#3B78FF",
-        "brightCyan" : "#61D6D6",
-        "brightGreen" : "#16C60C",
-        "brightPurple" : "#B4009E",
-        "brightRed" : "#E74856",
-        "brightWhite" : "#F2F2F2",
-        "brightYellow" : "#F9F1A5"
-    }
-  ]
-}
-```
-
-### Creation and location(s) of the json files
-
-In this section, we cover where an app that wants to use this proto-extension functionality should put the json
-files. Once we implement this feature, we will need to provide documentation on this for app developers.
-
-#### For apps installed through Microsoft store (or similar)
-
-For apps that are installed through something like the Microsoft Store, they will need to declare themselves to
-be an app extension or write a separate app extension. In the app extension, they will need to create a public
-folder, and create a subdirectory within that folder called `Fragments`. The json files should be inserted into the
-`Fragments` subdirectory. The specifics of how they can declare themselves as an app extension are provided in the
-[Microsoft Docs](https://docs.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-an-extension), and I will
-replicate the necessary section here.
-
-In the appxmanifest file of the package:
-
-```js
-<Package
-  ...
-  xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
-  IgnorableNamespaces="uap uap3 mp">
-  ...
-    <Applications>
-      <Application Id="App" ... >
-        ...
-        <Extensions>
-          ...
-          <uap3:Extension Category="windows.appExtension">
-            <uap3:AppExtension Name="com.microsoft.windows.terminal.settings"
-                               Id="<id>"
-                               PublicFolder="Public">
-            </uap3:AppExtension>
-          </uap3:Extension>
-        </Extensions>
-      </Application>
-    </Applications>
-    ...
-</Package>
-```
-
-Note that the name field **must** be `com.microsoft.windows.terminal.settings` for us to detect this extension. The `Id` field
-can be filled out as the app wishes. The `PublicFolder` field should have the name of the folder, relative to
-the package root, where the `json` files they wish to share with us are stored (this folder is typically named
-`Public` but can be renamed as long as it matches the relevant folder).
-
-During our profile generation, we will probe the OS for app extensions with the name `com.microsoft.windows.terminal.settings`
-and obtain the json files stored in the `Fragments` subdirectories of the public folders of those app extensions.
-
-#### For apps installed 'traditionally'
-
-For apps that are installed 'traditionally', there are 2 cases. The first is that this installation is for all
-the users of the system - in this case, the installer should add their json files to the global folder:
-
-```js
-C:\ProgramData\Microsoft\Windows Terminal\Fragments\{app-name}
-```
-
-Note: `C:\ProgramData` is a [known folder](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/bb776911(v=vs.85))
-that apps should be able to access. If the folder `Windows Terminal` in `C:\ProgramData\Microsoft\Windows`
-does not already exist, the installer should create it. **Note:** the installer must create a subdirectory within
-the `Fragments` folder with their app name, we will use that name for the [`source` field](#the-source-field).
-
-In the second case, the installation is only for the current user. For this case, the installer should add the
-json files to the local folder:
-
-```js
-C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments\{app-name}
-```
-
-We will look through both folders mentioned above during profile generation.
-
-#### The source field
-
-Currently, we allow users an easy way to disable/enable profiles that are generated from certain sources. For
-example, a user can easily hide all dynamic profiles with the source `"Windows.Terminal.Wsl"` if they wish to.
-To retain this functionality, we will add source fields to profiles we create through proto-extensions.
-
-For full profiles that came from apps installed 'traditionally', we will use the name of the subdirectory where
-the json file was found to fill out the source field.
-
-For full profiles that came from app extensions, we will use the app package name to fill out the source field.
-
-
-
-## UI/UX Design
-
-This feature will allow other installations a level of control over how their profiles look in Terminal. For example,
-if Ubuntu gets a new icon or a new font they can have those changes be reflected in Terminal users' Ubuntu profiles.
-
-## Capabilities
-
-### Accessibility
-
-This change should not affect accessibility.
-
-### Security
-
-Opening a profile causes its commandline argument to be automatically run. Thus, if malicious modifications are made
-to existing profiles or new profiles with malicious commandline arguments are added, users could be tricked into running
-things they do not want to.
-
-### Reliability
-
-This should not affect reliability - most of what its doing is simply layering json which we already do.
-
-### Compatibility
-
-Again, there should not be any issues here - the user settings can still be layered after this layering for the user
-to have the final say.
-
-### Performance, Power, and Efficiency
-
-Looking through the additional json files could negatively impact startup time.
-
-## Potential Issues
-
-* An installer dumps a _lot_ of json files into the folder which we need to look through.
-* When a `.json` files is deleted, any new profiles that were generated from it remain in the user's settings file (though they no longer appear in the tab dropdown).
-
-## Future considerations
-
-We need to consider how an app extension provides the path to an image (for the icon source or background image of a profile for example)
-
-This will likely be a stepping stone for the theme marketplace.
-
-This will also likely be a stepping stone to allowing users to specify other files to import settings from.
-
-## Resources
-
-N/A

res/README.md

@@ -17,5 +17,5 @@ Please consult the [license](https://raw.githubusercontent.com/microsoft/cascadi
 
 ### Fonts Included
 
-* Cascadia Code, Cascadia Mono (2102.03)
-   * from microsoft/cascadia-code@b358d1ba3d1629c113671312b18eab52797cc055
+* Cascadia Code, Cascadia Mono (2009.21)
+   * from microsoft/cascadia-code@32f84124db1970fa5d032f0fe9019e6922961beb