Improve the VT cursor movement implementation (#3628)

## Summary of the Pull Request

Originally there were 3 different methods for implementing VT cursor movement, and between them they still couldn't handle some of the operations correctly. This PR unifies those operations into a single method that can handle every type of cursor movement, and which fixes some of the issues with the existing implementations. In particular it fixes the `CNL` and `CPL` operations, so they're now correctly constrained by the `DECSTBM` margins.

## References

If this PR is accepted, the method added here should make it trivial to implement the `VPR` and `HPR` commands in issue #3428.

## PR Checklist
* [x] Closes #2926
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

## Detailed Description of the Pull Request / Additional comments

The new [`AdaptDispatch::_CursorMovePosition`](d6c4f35cf6/src/terminal/adapter/adaptDispatch.cpp (L169)) method is based on the proposal I made in issue #3428 for the `VPR` and `HPR` comands. It takes three arguments: a row offset (which can be absolute or relative), a column offset (ditto), and a flag specifying whether the position should be constrained by the `DECSTBM` margins.

To make the code more readable, I've implemented the offsets using [a `struct` with some `constexpr` helper functions for the construction](d6c4f35cf6/src/terminal/adapter/adaptDispatch.hpp (L116-L125)). This lets you specify the parameters with expressions like `Offset::Absolute(col)` or `Offset::Forward(distance)` which I think makes the calling code a little easier to understand.

While implementing this new method, I noticed a couple of issues in the existing movement implementations which I thought would be good to fix at the same time.

1. When cursor movement is constrained horizontally, it should be constrained by the buffer width, and not the horizontal viewport boundaries. This is an issue I've previously corrected in other parts of the codebase, and I think the cursor movement was one of the last areas where it was still a problem.

2. A number of the commands had range and overflow checks for their parameters that were either unnecessary (testing for a condition that could never occur) or incorrect (if an operation overflows, the correct behavior is to clamp it, and not just fail). The new implementation handles legitimate overflows correctly, but doesn't check for impossible ranges.

Because of the change of behavior in point 1, I also had to update the implementations of [the `DECSC` and `CPR` commands](9cf7a9b577) to account for the column offset now being relative to the buffer and not the viewport, otherwise those operations would no longer work correctly.

## Validation Steps Performed

Because of the two changes in behavior mentioned above, there were a number of adapter tests that stopped working and needed to be updated. First off there were those that expected the column offset to be relative to the left viewport position and constrained by the viewport width. These now had to be updated to [use the full buffer width](49887a3589) as the allowed horizontal extent.

Then there were all the overflow and out-of-range tests that were testing conditions that could never occur in practice, or where the expected behavior that was tested was actually incorrect. I did spend some time trying to see if there was value in updating these tests somehow, but in the end I decided it was best to just [drop them](6e80d0de19) altogether.

For the `CNL` and `CPL` operations, there didn't appear to be any existing tests, so I added some [new screen buffer tests](d6c4f35cf6) to check that those operations now work correctly, both with and without margins.

(cherry picked from commit 2fec1787a0)

.github/ISSUE_TEMPLATE/Bug_Report.md

@@ -1,7 +1,7 @@
 ---
-name: Bug report 🐛
+name: "Bug report 🐛"
 about: Report errors or unexpected behavior
-title: "Bug Report (IF I DO NOT CHANGE THIS THE ISSUE WILL BE AUTO-CLOSED)"
+title: ''
 labels: ''
 assignees: ''
 
@@ -35,7 +35,7 @@ Please use this form and describe your issue, concisely but precisely, with as m
 # Environment
 
 ```none
-Windows build number: [run "ver" at a command prompt]
+Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
 Windows Terminal version (if applicable):
 
 Any other software?

.github/ISSUE_TEMPLATE/Documentation_Issue.md

@@ -1,7 +1,7 @@
 ---
-name: Documentation Issue 📚
+name: "Documentation Issue 📚"
 about: Report issues in our documentation
-title: "Documentation Issue"
+title: ''
 labels: Issue-Docs
 assignees: ''
 

.github/ISSUE_TEMPLATE/Feature_Request.md

@@ -1,34 +1,35 @@
----
-name: Feature Request/Idea 🚀
-about: Suggest a new feature or improvement (this does not mean you have to implement it)
-title: "Feature Request"
-labels: Issue-Feature
-assignees: ''
-
----
-
-<!-- 
-🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨
-
-I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
-1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
-2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
-3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
-4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
-5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.
-
-All good? Then proceed!
--->
-
-# Description of the new feature/enhancement
-
-<!-- 
-A clear and concise description of what the problem is that the new feature would solve.
-Describe why and how a user would use this new functionality (if applicable).
--->
-
-# Proposed technical implementation details (optional)
-
-<!-- 
-A clear and concise description of what you want to happen.
--->
+---
+name: "Feature Request/Idea 🚀"
+about: Suggest a new feature or improvement (this does not mean you have to implement
+  it)
+title: ''
+labels: Issue-Feature
+assignees: ''
+
+---
+
+<!-- 
+🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨
+
+I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
+1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
+2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
+3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
+4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
+5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.
+
+All good? Then proceed!
+-->
+
+# Description of the new feature/enhancement
+
+<!-- 
+A clear and concise description of what the problem is that the new feature would solve.
+Describe why and how a user would use this new functionality (if applicable).
+-->
+
+# Proposed technical implementation details (optional)
+
+<!-- 
+A clear and concise description of what you want to happen.
+-->

.github/ISSUE_TEMPLATE/Guidance_Issue.md

@@ -1,10 +0,0 @@
----
-name: Community Guidance Request ✨
-about: Suggest somewhere the Windows Terminal Team needs to provide community guidance through new documentation or process.
-title: "Guidance"
-labels: Issue-Docs
-assignees: 'bitcrazed'
-
----
-
-<!-- What needs to change? Who is responsible for it? Why is it an open question? -->

.gitignore

@@ -261,6 +261,9 @@ build*.rec
 build*.wrn
 build*.metadata
 
+# MS Build binary logs
+*.binlog
+
 # .razzlerc.cmd file - used by dev environment
 tools/.razzlerc.*
 # .PowershellModules - if one needs a powershell module dependency, one

NOTICE.md

@@ -47,3 +47,33 @@ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```
+
+## telnetpp
+
+**Source**: https://github.com/KazDragon/telnetpp
+
+### License 
+
+```
+The MIT License (MIT)
+
+Copyright (c) 2015-2017 Matthew Chaplain a.k.a KazDragon
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

README.md

@@ -1,157 +1,167 @@
-# Welcome\! 
-#### This repository contains the source code for:
+# Welcome to the Windows Terminal, Console and Command-Line repo
 
-  * [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701)
-  * The Windows console host (`conhost.exe`)
-  * Components shared between the two projects
-  * [ColorTool](https://github.com/Microsoft/Terminal/tree/master/src/tools/ColorTool)
-  * [Sample projects](https://github.com/Microsoft/Terminal/tree/master/samples) that show how to consume the Windows Console APIs
-  
-#### Other related repositories include:
-  * [Console API Documentation](https://github.com/MicrosoftDocs/Console-Docs)
+This repository contains the source code for:
 
-## Installation
+* [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701)
+* The Windows console host (`conhost.exe`)
+* Components shared between the two projects
+* [ColorTool](https://github.com/Microsoft/Terminal/tree/master/src/tools/ColorTool)
+* [Sample projects](https://github.com/Microsoft/Terminal/tree/master/samples) that show how to consume the Windows Console APIs
 
-_(Note: in order to run the Windows Terminal, you'll need to be running at least Windows build 18362 or higher.)_
+Related repositories include:
 
-### Microsoft Store
+* [Console API Documentation](https://github.com/MicrosoftDocs/Console-Docs)
+* [Cascadia Code Font](https://github.com/Microsoft/Cascadia-Code)
 
-Download the Microsoft Terminal free from the Microsoft Store and it'll be continuously updated. Or, feel free to side-load [releases](https://github.com/microsoft/terminal/releases) from GitHub, but note they won't auto-update.
+## Installing and running Windows Terminal
 
-<a href='//www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge'><img src='https://assets.windowsphone.com/85864462-9c82-451e-9355-a3d5f874397a/English_get-it-from-MS_InvariantCulture_Default.png' alt='English badge' width="284" height="104" style='width: 284px; height: 104px;'/></a>
+> 👉 Note: Windows Terminal requires Windows 10 1903 (build 18362) or later
 
-### Chocolatey (Unofficial)
+### Manually installing builds from this repository
 
-Download and upgrade the Windows Terminal from [Chocolatey](https://chocolatey.org).
+For users who are unable to install Terminal from the Microsoft Store, Terminal builds can be manually downloaded from this repository's [Releases page](https://github.com/microsoft/terminal/releases).
+
+> ⚠ Note: If you install Terminal manually:
+>
+> * Be sure to install the [Desktop Bridge VC++ v14 Redistributable Package](https://www.microsoft.com/en-us/download/details.aspx?id=53175) otherwise Terminal may not install and/or run and may crash at startup
+> * Terminal will not auto-update when new builds are released so you will need to regularly install the latest Terminal release to receive all the latest fixes and improvements!
+
+### Install via Chocolatey (unofficial)
+
+[Chocolatey](https://chocolatey.org) users can download and install the latest Terminal release by installing the `microsoft-windows-terminal` package:
 
-To install Windows Terminal, run the following command from the command line or from PowerShell:
 ```powershell
 choco install microsoft-windows-terminal
 ```
 
-To upgrade Windows Terminal, run the following command from the command line or from PowerShell:
+To upgrade Windows Terminal using Chocolatey, run the following:
+
 ```powershell
 choco upgrade microsoft-windows-terminal
 ```
 
-If you have any issues when installing/upgrading the package please go to the [package page](https://chocolatey.org/packages/microsoft-windows-terminal) and follow the [Chocolatey triage process](https://chocolatey.org/docs/package-triage-process)
+If you have any issues when installing/upgrading the package please go to the [Windows Terminal package page](https://chocolatey.org/packages/microsoft-windows-terminal) and follow the [Chocolatey triage process](https://chocolatey.org/docs/package-triage-process)
 
-### Build Status
+---
+
+## Project Build Status
 
 Project|Build Status
 ---|---
 Terminal|[![Build Status](https://dev.azure.com/ms/Terminal/_apis/build/status/Terminal%20CI?branchName=master)](https://dev.azure.com/ms/Terminal/_build?definitionId=136)
 ColorTool|![](https://microsoft.visualstudio.com/_apis/public/build/definitions/c93e867a-8815-43c1-92c4-e7dd5404f1e1/17023/badge)
 
-# Terminal & Console Overview
+---
+
+## Windows Terminal v1.0 Roadmap
+
+The plan for delivering Windows Terminal v1.0 [is described here](/doc/terminal-v1-roadmap.md), and will be updated as the project proceeds.
+
+---
+
+## Terminal & Console Overview
 
 Please take a few minutes to review the overview below before diving into the code:
 
-## Windows Terminal
+### Windows Terminal
 
 Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more.
 
-The Terminal will also need to meet our goals and measures to ensure it remains fast, and efficient, and doesn't consume vast amounts of memory or power.
+The Terminal will also need to meet our goals and measures to ensure it remains fast and efficient, and doesn't consume vast amounts of memory or power.
 
-## The Windows console host
+### The Windows Console Host
 
-The Windows console host, `conhost.exe`, is Windows' original command-line user experience. It implements Windows' command-line infrastructure, and is responsible for hosting the Windows Console API, input engine, rendering engine, and user preferences. The console host code in this repository is the actual source from which the `conhost.exe` in Windows itself is built.
+The Windows Console host, `conhost.exe`, is Windows' original command-line user experience. It also hosts Windows' command-line infrastructure and the Windows Console API server, input engine, rendering engine, user preferences, etc. The console host code in this repository is the actual source from which the `conhost.exe` in Windows itself is built.
 
-Console's primary goal is to remain backwards-compatible with existing console subsystem applications.
+Since taking ownership of the Windows command-line in 2014, the team added several new features to the Console, including background transparency, line-based selection, support for [ANSI / Virtual Terminal sequences](https://en.wikipedia.org/wiki/ANSI_escape_code), [24-bit color](https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/), a [Pseudoconsole ("ConPTY")](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/), and more.
 
-Since assuming ownership of the Windows command-line in 2014, the team has added several new features to the Console, including window transparency, line-based selection, support for [ANSI / Virtual Terminal sequences](https://en.wikipedia.org/wiki/ANSI_escape_code), [24-bit color](https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/), a [Pseudoconsole ("ConPTY")](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/), and more.
-
-However, because the Console's primary goal is to maintain backward compatibility, we've been unable to add many of the features the community has been asking for, and which we've been wanting to add for the last several years--like tabs!
+However, because Windows Console's primary goal is to maintain backward compatibility, we have been unable to add many of the features the community (and the team) have been wanting for the last several years including tabs, unicode text, and emoji.
 
 These limitations led us to create the new Windows Terminal.
 
-## Shared Components
+> You can read more about the evolution of the command-line in general, and the Windows command-line specifically in [this accompanying series of blog posts](https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/) on the Command-Line team's blog.
 
-While overhauling the Console, we've modernized its codebase considerably. We've cleanly separated logical entities into modules and classes, introduced some key extensibility points, replaced several old, home-grown collections and containers with safer, more efficient [STL containers](https://docs.microsoft.com/en-us/cpp/standard-library/stl-containers?view=vs-2019), and made the code simpler and safer by using Microsoft's [WIL](https://github.com/Microsoft/wil) header library.
+### Shared Components
 
-This overhaul work resulted in the creation of several key components that would be useful for any terminal implementation on Windows, including a new DirectWrite-based text layout and rendering engine, a text buffer capable of storing both UTF-16 and UTF-8, and a VT parser/emitter.
+While overhauling Windows Console, we modernized its codebase considerably, cleanly separating logical entities into modules and classes, introduced some key extensibility points, replaced several old, home-grown collections and containers with safer, more efficient [STL containers](https://docs.microsoft.com/en-us/cpp/standard-library/stl-containers?view=vs-2019), and made the code simpler and safer by using Microsoft's [Windows Implementation Libraries - WIL](https://github.com/Microsoft/wil).
 
-## Building a new terminal
+This overhaul resulted in several of Console's key components being available for re-use in any terminal implementation on Windows. These components include a new DirectWrite-based text layout and rendering engine, a text buffer capable of storing both UTF-16 and UTF-8, a VT parser/emitter, and more.
 
-When we started building the new terminal application, we explored and evaluated several approaches and technology stacks. We ultimately decided that our goals would be best met by sticking with C++ and sharing the aforementioned modernized components, placing them atop the modern Windows application platform and UI framework.
+### Creating the new Windows Terminal
 
-Further, we realized that this would allow us to build the terminal's renderer and input stack as a reusable Windows UI control that others can incorporate into their applications.
+When we started planning the new Windows Terminal application, we explored and evaluated several approaches and technology stacks. We ultimately decided that our goals would be best met by continuing our investment in our C++ codebase, which would allow us to reuse several of the aforementioned modernized components in both the existing Console and the new Terminal. Further, we realized that this would allow us to build much of the Terminal's core itself as a reusable UI control that others can incorporate into their own applications.
 
-# FAQ
+The result of this work is contained within this repo and delivered as the Windows Terminal application you can download from the Microsoft Store, or [directly from this repo's releases](https://github.com/microsoft/terminal/releases).
 
-## Where can I download Windows Terminal?
+---
 
-### The Windows Terminal preview can be downloaded from the Microsoft Store.
+## Resources
 
-[https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701)
+For more information about Windows Terminal, you may find some of these resources useful and interesting:
 
-## I built and ran the new Terminal, but I just get a blank window app!
+* [Command-Line Blog](https://devblogs.microsoft.com/commandline)
+* [Command-Line Backgrounder Blog Series](https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/)
+* Windows Terminal Launch: [Terminal "Sizzle Video"](https://www.youtube.com/watch?v=8gw0rXPMMPE&list=PLEHMQNlPj-Jzh9DkNpqipDGCZZuOwrQwR&index=2&t=0s)
+* Windows Terminal Launch: [Build 2019 Session](https://www.youtube.com/watch?v=KMudkRcwjCw)
+* Run As Radio: [Show 645 - Windows Terminal with Richard Turner](http://www.runasradio.com/Shows/Show/645)
+* Azure Devops Podcast: [Episode 54 - Kayla Cinnamon and Rich Turner on DevOps on the Windows Terminal](http://azuredevopspodcast.clear-measure.com/kayla-cinnamon-and-rich-turner-on-devops-on-the-windows-terminal-team-episode-54)
+* Microsoft Ignite 2019 Session: [The Modern Windows Command Line: Windows Terminal - BRK3321](https://myignite.techcommunity.microsoft.com/sessions/81329?source=sessions)
 
-Make sure you are building for your computer's architecture. If your box has a 64-bit Windows, change your Solution Platform to x64.  
-To check your OS architecture go to Settings -> System -> About (or Win+X -> System) and under `Device specifications` check for the  `System type`.
+---
 
-## I built and ran the new Terminal, but it looks just like the old console! What gives?
+## FAQ
 
-Firstly, make sure you're building & deploying `CascadiaPackage` in Visual Studio, _NOT_ `Host.EXE`. `OpenConsole.exe` is just `conhost.exe`, the same old console you know and love. `opencon.cmd` will launch `openconsole.exe`, and unfortunately, `openterm.cmd` is currently broken.
+### I built and ran the new Terminal, but it looks just like the old console
 
-Secondly, try pressing <kbd>Ctrl</kbd> + <kbd>T</kbd>. The tabs are hidden when you only have one tab by default. In the future, the UI will be dramatically different, but for now, the defaults are _supposed_ to look like the console defaults.
+Cause: You're launching the incorrect solution in Visual Studio.
 
-## I tried running WindowsTerminal.exe and it crashes!
+Solution: Make sure you're building & deploying the `CascadiaPackage` project in Visual Studio.
 
-* Don't try to run it unpackaged. Make sure to build & deploy `CascadiaPackage` from Visual Studio, and run the Windows Terminal (Dev Build) app.
-* Make sure you're on the right version of Windows. You'll need to be on Insider's builds, or wait for the 1903 release, as the Windows Terminal **REQUIRES** features from the latest Windows release.
+> ⚠ Note: `OpenConsole.exe` is just a locally-built `conhost.exe`, the classic Windows Console that hosts Windows' command-line infrastructure. OpenConsole is used by Windows Terminal to connect to and communicate with command-line applications (via [ConPty](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/)).
 
-# Getting Started
+---
 
-## Debugging
+## Documentation
 
-* To debug in VS, right click on CascadiaPackage (from VS Solution Explorer) and go to properties, in the Debug menu, change "Application process" and "Background task process" to "Native Only".
+All project documentation is located in the `./doc` folder. If you would like to contribute to the documentation, please submit a pull request.
+
+---
 
 ## Contributing
 
 We are excited to work alongside you, our amazing community, to build and enhance Windows Terminal\!
 
-We ask that **before you start work on a feature that you would like to contribute**, please read our [Contributor's Guide](https://github.com/microsoft/terminal/blob/master/doc/contributing.md). We will be happy to work with you to figure out the best approach, provide guidance and mentorship throughout feature development, and help avoid any wasted or duplicate effort.
-
-> 👉 **Remember\!** Your contributions may be incorporated into future versions of Windows\! Because of this, all pull requests will be subject to the same level of scrutiny for quality, coding standards, performance, globalization, accessibility, and compatibility as those of our internal contributors.
-
-> ⚠ **Note**: The Command-Line Team is actively working out of this repository and will be periodically re-structuring the code to make it easier to comprehend, navigate, build, test, and contribute to, so **DO expect significant changes to code layout on a regular basis**.
-
-## Documentation
-
-All documentation is located in the `./doc` folder. If you would like to contribute to the documentation, please submit a pull request.
+***BEFORE you start work on a feature/fix***, please read & follow our [Contributor's Guide](https://github.com/microsoft/terminal/blob/master/contributing.md) to help avoid any wasted or duplicate effort.
 
 ## Communicating with the Team
 
-The easiest way to communicate with the team is via GitHub issues. Please file new issues, feature requests and suggestions, but **DO search for similar open/closed pre-existing issues before you do**.
+The easiest way to communicate with the team is via GitHub issues.
 
-Please help us keep this repository clean, inclusive, and fun\! We will not tolerate any abusive, rude, disrespectful or inappropriate behavior. Read our [Code of Conduct](https://opensource.microsoft.com/codeofconduct/) for more details.
+Please file new issues, feature requests and suggestions, but **DO search for similar open/closed pre-existing issues before creating a new issue.**
 
 If you would like to ask a question that you feel doesn't warrant an issue (yet), please reach out to us via Twitter:
 
-  * Rich Turner, Program Manager: [@richturn\_ms](https://twitter.com/richturn_ms)
+* Kayla Cinnamon, Program Manager: [@cinnamon\_msft](https://twitter.com/cinnamon_msft)
+* Rich Turner, Program Manager: [@richturn\_ms](https://twitter.com/richturn_ms)
+* Dustin Howett, Engineering Lead: [@dhowett](https://twitter.com/DHowett)
+* Michael Niksa, Senior Developer: [@michaelniksa](https://twitter.com/MichaelNiksa)
+* Mike Griese, Developer: [@zadjii](https://twitter.com/zadjii)
+* Carlos Zamora, Developer: [@cazamor_msft](https://twitter.com/cazamor_msft)
+* Leon Liang, Developer: [@leonmsft](https://twitter.com/leonmsft)
 
-  * Dustin Howett, Engineering Lead: [@dhowett](https://twitter.com/DHowett)
-  
-  * Michael Niksa, Senior Developer: [@michaelniksa](https://twitter.com/MichaelNiksa)
+## Developer Guidance
 
-  * Kayla Cinnamon, Program Manager (especially for UX issues): [@cinnamon\_msft](https://twitter.com/cinnamon_msft)
-
-# Developer Guidance
-
-## Build Prerequisites
-
-* You must be running Windows 1903 (build >= 10.0.18362.0) or above in order to run Windows Terminal.
-* You must have the [1903 SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk) (build 10.0.18362.0) installed.
-* You must have at least [VS 2019](https://visualstudio.microsoft.com/downloads/) installed.
-* You must install the following Workloads via the VS Installer. Opening the solution will [prompt you to install missing components automatically](https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/).
-  - Desktop Development with C++
-  - Universal Windows Platform Development
-  - **The following Individual Components**
-     - C++ (v142) Universal Windows Platform Tools
-
-* You must also [enable Developer Mode in the Windows Settings app](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development) to locally install and run the Terminal app.
+## Prerequisites
 
+* You must be running Windows 1903 (build >= 10.0.18362.0) or later to run Windows Terminal
+* You must [enable Developer Mode in the Windows Settings app](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development) to locally install and run Windows Terminal
+* You must have the [Windows 10 1903 SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk) installed
+* You must have at least [VS 2019](https://visualstudio.microsoft.com/downloads/) installed
+* You must install the following Workloads via the VS Installer. Note: Opening the solution in VS 2019 will [prompt you to install missing components automatically](https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/):
+  * Desktop Development with C++
+  * Universal Windows Platform Development
+  * **The following Individual Components**
+    * C++ (v142) Universal Windows Platform Tools
 
 ## Building the Code
 
@@ -161,9 +171,9 @@ This repository uses [git submodules](https://git-scm.com/book/en/v2/Git-Tools-S
 git submodule update --init --recursive
 ```
 
-OpenConsole.sln may be built from within Visual Studio or from the command-line using MSBuild. To build from the command line, find your shell below.
+OpenConsole.sln may be built from within Visual Studio or from the command-line using a set of convenience scripts & tools in the **/tools** directory:
 
-### PowerShell
+### Building in PowerShell
 
 ```powershell
 Import-Module .\tools\OpenConsole.psm1
@@ -171,27 +181,35 @@ Set-MsBuildDevEnvironment
 Invoke-OpenConsoleBuild
 ```
 
-### CMD
+### Building in Cmd
 
 ```shell
 .\tools\razzle.cmd
 bcz
 ```
 
-We've provided a set of convenience scripts as well as [README](./tools/README.md) in the **/tools** directory to help automate the process of building and running tests.
+## Running & Debugging
 
-## Coding Guidance
+To debug the Windows Terminal in VS, right click on `CascadiaPackage` (in the Solution Explorer) and go to properties. In the Debug menu, change "Application process" and "Background task process" to "Native Only".
 
-Please review these brief docs below relating to our coding standards etc.
+You should then be able to build & debug the Terminal project by hitting <kbd>F5</kbd>.
 
-> 👉 If you find something missing from these docs, feel free to contribute to any of our documentation files anywhere in the repository (or make some new ones\!)
+> 👉 You will _not_ be able to launch the Terminal directly by running the WindowsTerminal.exe. For more details on why, see [#926](https://github.com/microsoft/terminal/issues/926), [#4043](https://github.com/microsoft/terminal/issues/4043)
+
+### Coding Guidance
+
+Please review these brief docs below about our coding practices.
+
+> 👉 If you find something missing from these docs, feel free to contribute to any of our documentation files anywhere in the repository (or write some new ones!)
 
 This is a work in progress as we learn what we'll need to provide people in order to be effective contributors to our project.
 
-  - [Coding Style](https://github.com/Microsoft/Terminal/blob/master/doc/STYLE.md)
-  - [Code Organization](https://github.com/Microsoft/Terminal/blob/master/doc/ORGANIZATION.md)
-  - [Exceptions in our legacy codebase](https://github.com/Microsoft/Terminal/blob/master/doc/EXCEPTIONS.md)
-  - [Helpful smart pointers and macros for interfacing with Windows in WIL](https://github.com/Microsoft/Terminal/blob/master/doc/WIL.md)
+* [Coding Style](https://github.com/Microsoft/Terminal/blob/master/doc/STYLE.md)
+* [Code Organization](https://github.com/Microsoft/Terminal/blob/master/doc/ORGANIZATION.md)
+* [Exceptions in our legacy codebase](https://github.com/Microsoft/Terminal/blob/master/doc/EXCEPTIONS.md)
+* [Helpful smart pointers and macros for interfacing with Windows in WIL](https://github.com/Microsoft/Terminal/blob/master/doc/WIL.md)
+
+---
 
 # Code of Conduct
 

SECURITY.md

@@ -0,0 +1,41 @@
+<!-- BEGIN MICROSOFT SECURITY.MD V0.0.2 BLOCK -->
+
+## Security
+
+Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [many more](https://opensource.microsoft.com/).
+
+If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft's [definition](https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc751383(v=technet.10)) of a security vulnerability, please report it to us as described below.
+
+## Reporting Security Issues
+
+**Please do not report security vulnerabilities through public GitHub issues.**
+
+Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://msrc.microsoft.com/create-report).
+
+If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com).  If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://www.microsoft.com/en-us/msrc/pgp-key-msrc).
+
+You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://www.microsoft.com/msrc). 
+
+Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
+
+  * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
+  * Full paths of source file(s) related to the manifestation of the issue
+  * The location of the affected source code (tag/branch/commit or direct URL)
+  * Any special configuration required to reproduce the issue
+  * Step-by-step instructions to reproduce the issue
+  * Proof-of-concept or exploit code (if possible)
+  * Impact of the issue, including how an attacker might exploit the issue
+
+This information will help us triage your report more quickly.
+
+If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://microsoft.com/msrc/bounty) page for more details about our active programs.
+
+## Preferred Languages
+
+We prefer all communications to be in English.
+
+## Policy
+
+Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://www.microsoft.com/en-us/msrc/cvd).
+
+<!-- END MICROSOFT SECURITY.MD BLOCK -->

build/config/SignConfig.NuGet.xml

@@ -0,0 +1,5 @@
+<SignConfigXML>
+  <job platform="" configuration="" dest="__INPATHROOT__" jobname="EngFunSimpleSign" approvers="">
+   <file src="__INPATHROOT__\Microsoft.Terminal*.nupkg" signType="NuGet" /> 
+  </job>
+</SignConfigXML>

build/config/SignConfig.WindowsTerminal.xml

@@ -1,5 +1,6 @@
 <SignConfigXML>
   <job platform="" configuration="" certSubject="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" jobname="EngFunSimpleSign" approvers="">
    <file src="__INPATHROOT__\Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle" signType="136020001" dest="__OUTPATHROOT__\Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle" /> 
+   <file src="__INPATHROOT__\Microsoft.WindowsTerminalUniversal_8wekyb3d8bbwe.msixbundle" signType="136020001" dest="__OUTPATHROOT__\Microsoft.WindowsTerminalUniversal_8wekyb3d8bbwe.msixbundle" /> 
   </job>
 </SignConfigXML>

build/pipelines/templates/build-console-steps.yml

@@ -42,7 +42,7 @@ steps:
     vsVersion: 16.0
     platform: '$(BuildPlatform)'
     configuration: '$(BuildConfiguration)'
-    msbuildArgs: ${{ parameters.additionalBuildArguments }}
+    msbuildArgs: "${{ parameters.additionalBuildArguments }}"
     clean: true
     maximumCpuCount: true
 
@@ -54,6 +54,14 @@ steps:
       $Package = Get-ChildItem -Recurse -Filter "CascadiaPackage_*.msix"
       .\build\scripts\Test-WindowsTerminalPackage.ps1 -Verbose -Path $Package.FullName
 
+- task: powershell@2
+  displayName: 'Source Index PDBs'
+  inputs:
+    targetType: filePath
+    filePath: build\scripts\Index-Pdbs.ps1
+    arguments: -SearchDir '$(Build.SourcesDirectory)' -SourceRoot '$(Build.SourcesDirectory)' -recursive -Verbose -CommitId $(Build.SourceVersion)
+    errorActionPreference: silentlyContinue
+
 - task: VSTest@2
   displayName: 'Run Unit Tests'
   inputs:

build/rules/GenerateSxsManifestsFromWinmds.targets

@@ -10,7 +10,7 @@
   <Target Name="_ConsoleMapWinmdsToManifestFiles" DependsOnTargets="ResolveAssemblyReferences">
     <ItemGroup>
       <!-- For each non-system .winmd file in References, generate a .manifest in IntDir for it. -->
-      <_ConsoleWinmdManifest Include="@(ReferencePath->'$(IntDir)\%(FileName).manifest')" Condition="'%(ReferencePath.IsSystemReference)' != 'true' and '%(ReferencePath.WinMDFile)' == 'true' and '%(ReferencePath.ReferenceSourceTarget)' == 'ResolveAssemblyReference'">
+      <_ConsoleWinmdManifest Include="@(ReferencePath->'$(IntDir)\%(FileName).manifest')" Condition="'%(ReferencePath.IsSystemReference)' != 'true' and '%(ReferencePath.WinMDFile)' == 'true' and '%(ReferencePath.ReferenceSourceTarget)' == 'ResolveAssemblyReference' and '%(ReferencePath.Implementation)' != ''">
         <WinMDPath>%(ReferencePath.FullPath)</WinMDPath>
         <Implementation>%(ReferencePath.Implementation)</Implementation>
       </_ConsoleWinmdManifest>

build/scripts/Index-Pdbs.ps1

@@ -0,0 +1,85 @@
+[CmdLetBinding()]
+Param(
+    [Parameter(Mandatory=$true, Position=0)][string]$SearchDir,
+    [Parameter(Mandatory=$true, Position=1)][string]$SourceRoot,
+    [Parameter(Mandatory=$true, Position=2)][string]$CommitId,
+    [string]$Organization = "microsoft",
+    [string]$Repo = "terminal",
+    [switch]$recursive
+)
+
+$debuggerPath = (Get-ItemProperty -path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots" -name WindowsDebuggersRoot10).WindowsDebuggersRoot10
+$srcsrvPath = Join-Path $debuggerPath "x64\srcsrv"
+$srctoolExe = Join-Path $srcsrvPath "srctool.exe"
+$pdbstrExe = Join-Path $srcsrvPath "pdbstr.exe"
+
+$fileTable = @{}
+foreach ($gitFile in & git ls-files)
+{
+    $fileTable[$gitFile] = $gitFile
+}
+
+$mappedFiles = New-Object System.Collections.ArrayList
+
+foreach ($file in (Get-ChildItem -r:$recursive "$SearchDir\*.pdb"))
+{
+    Write-Verbose "Found $file"
+
+    $ErrorActionPreference = "Continue" # Azure Pipelines defaults to "Stop", continue past errors in this script.
+    
+    $allFiles = & $srctoolExe -r "$file"
+
+    # If the pdb didn't have enough files then skip it (the srctool output has a blank line even when there's no info
+    # so check for less than 2 lines)
+    if ($allFiles.Length -lt 2)
+    {
+        continue
+    }
+
+    for ($i = 0; $i -lt $allFiles.Length; $i++)
+    {
+        if ($allFiles[$i].StartsWith($SourceRoot, [StringComparison]::OrdinalIgnoreCase))
+        {
+            $relative = $allFiles[$i].Substring($SourceRoot.Length).TrimStart("\")
+            $relative = $relative.Replace("\", "/")
+
+            # Git urls are case-sensitive but the PDB might contain a lowercased version of the file path.
+            # Look up the relative url in the output of "ls-files". If it's not there then it's not something
+            # in git, so don't index it.
+            $relative = $fileTable[$relative]
+            if ($relative)
+            {
+                $mapping = $allFiles[$i] + "*$relative"
+                $mappedFiles.Add($mapping)
+
+                Write-Verbose "Mapped path $($i): $mapping"
+            }
+        }
+    }
+
+    $pdbstrFile = Join-Path "$env:TEMP" "pdbstr.txt"
+
+    Write-Verbose "pdbstr.txt = $pdbstrFile"
+
+    @"
+SRCSRV: ini ------------------------------------------------
+VERSION=2
+VERCTRL=http
+SRCSRV: variables ------------------------------------------
+ORGANIZATION=$Organization
+REPO=$Repo
+COMMITID=$CommitId
+HTTP_ALIAS=https://raw.githubusercontent.com/%ORGANIZATION%/%REPO%/%COMMITID%/
+HTTP_EXTRACT_TARGET=%HTTP_ALIAS%%var2%
+SRCSRVTRG=%HTTP_EXTRACT_TARGET%
+SRC_INDEX=public
+SRCSRV: source files ---------------------------------------
+$($mappedFiles -join "`r`n")
+SRCSRV: end ------------------------------------------------
+"@ | Set-Content $pdbstrFile
+
+    & $pdbstrExe -p:"$file" -w -s:srcsrv -i:$pdbstrFile
+}
+
+# Return with exit 0 to override any weird error code from other tools
+Exit 0

build/scripts/Test-WindowsTerminalPackage.ps1

@@ -74,6 +74,12 @@ Try {
     If ($null -eq $AppXbf) {
         Throw "Failed to find App.xbf (TerminalApp project) in resources.pri"
     }
+
+    If (($null -eq (Get-Item "$AppxPackageRootPath\cpprest142_2_10.dll" -EA:Ignore)) -And
+        ($null -eq (Get-Item "$AppxPackageRootPath\cpprest142_2_10d.dll" -EA:Ignore))) {
+        Throw "Failed to find cpprest142_2_10.dll -- check the WAP packaging project"
+    }
+
 } Finally {
     Remove-Item -Recurse -Force $AppxPackageRootPath
 }

consolegit2gitfilters.json

@@ -14,6 +14,7 @@
     "/.vs/",
     "/build/",
     "/src/cascadia/",
+    "/src/winconpty/",
     "/.nuget/",
     "/.github/",
     "/samples/"

contributing.md

@@ -21,6 +21,9 @@ We drive the bot by tagging issues with specific labels which cause the bot engi
 Therefore, if you do file issues, or create PRs, please keep an eye on your GitHub notifications. If you do not respond to requests for information, your issues/PRs may be closed automatically.
 
 ---
+## Reporting Security Issues
+
+**Please do not report security vulnerabilities through public GitHub issues.** Instead, please report them to the Microsoft Security Response Center (MSRC). See [Security.md](../SECURITY.md) for more information.
 
 ## Before you start, file an issue
 

custom.props

@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="utf-8"?>
+<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <!-- This file is read by XES, which we use in our Release builds. -->
+  <PropertyGroup Label="Version">
+    <XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
+    <XesBaseYearForStoreVersion>2019</XesBaseYearForStoreVersion>
+    <VersionMajor>0</VersionMajor>
+    <VersionMinor>8</VersionMinor>
+    <VersionInfoProductName>Windows Terminal</VersionInfoProductName>
+  </PropertyGroup>
+</Project>

doc/Niksa.md

@@ -8,6 +8,7 @@ This document serves as a storage point for those posts.
 - [How are the Windows graphics/messaging stack assembled?](#gfxMsgStack)
 - [Output Processing between "Far East" and "Western"](#fesb)
 - [Why do we not backport things?](#backport)
+- [Why can't we have mixed elevated and non-elevated tabs in the Terminal?](#elevation)
 
 ## <a name="cmd"></a>Why do we avoid changing CMD.exe?
 `setlocal` doesn't behave the same way as an environment variable. It's a thing that would have to be put in at the top of the batch script that is `somefile.cmd` as one of its first commands to adjust the way that one specific batch file is processed by the `cmd.exe` engine. That's probably not suitable for your needs, but that's the way we have to go.
@@ -145,3 +146,36 @@ It's also costly in terms of time, effort, and testing for us to validate a modi
 So from our little team working hard to make developers happy, we virtually never make the cut for servicing. We're sorry, but we hope you can understand. It's just the reality of the situation to say "nope" when people ask for a backport. In our team's ideal world, you would all be running the latest console bits everywhere everytime we make a change. But that's just not how it is today.
 
 Original Source: https://github.com/microsoft/terminal/issues/279#issuecomment-439179675
+
+## <a name="elevation"></a>Why can't we have mixed elevated and non-elevated tabs in the Terminal?
+
+_guest speaker @DHowett-MSFT_
+
+[1] It is trivial when you are _hosting traditional windows_ with traditional window handles. That works very well in the conemu case, or in the tabbed shell case, where you can take over a window in an elevated session and re-parent it under a window in a non-elevated session.
+
+When you do that, there's a few security features that I'll touch on in [2]. Because of those, you can parent it but you can't really force it to do anything.
+
+There's a problem, though. The Terminal isn't architected as a collection of re-parentable windows. For example, it's not running a console host and moving its window into a tab. It was designed to support a "connection" -- something that can read and write text. It's a lower-level primitive than a window. We realized the error of our ways and decided that the UNIX model was right the entire time, and pipes and text and streams are _where it's at._
+
+Given that we're using Xaml islands to host a modern UI and stitching a DirectX surface into it, we're far beyond the world of standard window handles anyway. Xaml islands are fully composed into a single HWND, much like Chrome and Firefox and the gamut of DirectX/OpenGL/SDL games. We don't **have** components that can be run in one process (elevated) and hosted in another (non-elevated) that aren't the aforementioned "connections".
+
+Now, the obvious followup question is _"why can't you have one elevated connection in a tab next to a non-elevated connection?"_ This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.
+
+[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.
+
+Running a process elevated _severs_ that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.
+
+That "security" feature (call it what you like, it was probably intended to be a security feature at one point) only exists for a few session-global object types. Windows are one of them. Pipes aren't really one of them.
+
+Because of that, it's trivial to break that security. Take the terminal as an example of that. If we start an elevated connection and host it in a _non-elevated_ window, we've suddenly created a conduit through that security boundary. The elevated thing on the other end isn't a window, it's just a text-mode application. It immediately does the bidding of the non-elevated host.
+
+Anybody that can _control_ the non-elevated host (like `WScript.Shell::SendKeys`) _also_ gets an instant conduit through the elevation boundary. Suddenly, any medium integrity application on your system can control a high-integrity process. This could be your browser, or the bitcoin miner that got installed with the `left-pad` package from NPM, or really any number of things.
+
+It's a small risk, but it _is_ a risk.
+
+---
+
+Other platforms have accepted that risk in preference for user convenience. They aren't wrong to do so, but I think Microsoft gets less of a "pass" on things like "accepting risk for user convenience". Windows 9x was an unmitigated security disaster, and limited user accounts and elevation prompts and kernel-level security for window management were the answer to those things. They're not locks to be loosened lightly.
+
+Original Source: https://github.com/microsoft/terminal/issues/632#issuecomment-519375707
+

doc/ORGANIZATION.md

@@ -24,6 +24,16 @@
 * `/ipch` – not checked in is where intellisense data will be generated if you use Visual Studio 2015
 * `/obj` – not checked in is where objects will be generated by the MSBuild system
 * `/src` – This is the fun one. In the root is common build system data.
+	* `/src/cascadia` - This directory contains all the code specific to the Windows Terminal
+		* `/src/cascadia/TerminalConnection` - This DLL is responsible for the various different ways a terminal instance can communicate with different terminal backends. Examples include the `ConptyConnection` (for communicating with Windows Console processes), or the `AzureCloudShellConnection` for communicating with Azure.
+		* `/src/cascadia/TerminalSettings` - This is the DLL responsible for abstracting the settings for both the TerminalCore and the TerminalControl. This provides consumers of the TerminalControl a common interface for supplying settings to the Terminal.
+		* `/src/cascadia/TerminalCore` - This LIB is responsible for the core implementation of a terminal instance. This defines one important class `Terminal` which is a complete terminal instance, with buffer, colors table, VT parsing, input handling, etc. It does _not_ prescribe any sort of UI implementation - it should be connected to code that can handle rendering its contents, and provide input to it.
+		* `/src/cascadia/TerminalControl` - This DLL provides the UWP-XAML implementation of a `TermControl`, which can be embedded within an application to provide a terminal instance within the application. It contains a DX renderer for drawing text to the screen, and translates input to send to the core Terminal. It also recieves settings to apply to both itself and the core Terminal.
+		* `/src/cascadia/TerminalApp` - This DLL represents the implementation of the Windows Terminal application. This includes parsing settings, hosting tabs & panes with Terminals in them, and displaying other UI elements. This DLL is almost entirely UWP-like code, and shouldn't be doing any Win32-like UI work.
+		* `/src/cascadia/WindowsTerminal` - This EXE provides Win32 hosting for the TerminalApp. It will set up XAML islands, and is responsible for drawing the window, either as a standard window or with content in the titlebar (non-client area).
+		* `/src/cascadia/CasadiaPackage` - This is a project for packaging the Windows Terminal and its dependencies into an .appx/.msix for deploying to the machine.
+		* `/src/cascadia/PublicTerminalCore` - This is a DLL wrapper for the TerminalCore and Renderer, similar to `TermControl`, which exposes some exported functions that so the Terminal can be used from C#.
+		* `/src/cascadia/WpfTerminalControl` - A DLL implementing a WPF version of the Terminal Control.
 	* `/src/host` – The meat of the windows console host. This includes buffer, input, output, windowing, server management, clipboard, and most interactions with the console host window that aren’t stated anywhere else. We’re trying to pull things out that are reusable into other libraries, but it’s a work in progress
 		* `/src/host/lib` – Builds the reusable LIB copy of the host
 		* `/src/host/dll` – Packages LIB into conhostv2.dll to be put into the OS C:\windows\system32\
@@ -42,7 +52,7 @@
 		* `/src/renderer/base` – Base interface layer providing non-engine-specific rendering things like choosing the data from the console buffer, deciding how to lay out or transform that data, then dispatching commands to a specific final display engine
 		* `/src/renderer/gdi` – The GDI implementation of rendering to the screen. Takes commands to “draw a line” or “fill the background” or “select a region” from the base and turns them into GDI calls to the screen. Extracted from original console host code.
 		* `/src/renderer/inc` – Interface definitions for all renderer communication
-	* `/src/terminal` – Virtual terminal support for the console. This is the sequences that are found in-band with other text on STDIN/STDOUT that command the display to do things. This is the *nix way of controlling a console.
+	* `/src/terminal` – Virtual terminal support for the console. This is the sequences that are found in-band with other text on STDIN/STDOUT that command the display to do things. This is the \*nix way of controlling a console.
 		* `/src/terminal/parser` – This contains a state machine and sorting engine for feeding in individual characters from STDOUT or STDIN and decoding them into the appropriate verbs that should be performed
 		* `/src/terminal/adapter` – This converts the verbs from the interface into calls on the console API. It doesn’t actually call through the API (for performance reasons since it lives inside the same binary), but it tries to remain as close to an API call as possible. There are some private extensions to the API for behaviors that didn’t exist before this was written that we’ve not made public. We don’t know if we will yet or force people to use VT to get at them.
 	* `/src/tsf` – Text Services Foundation. This provides IME input services to the console. This was historically used for only Chinese, Japanese, and Korean IMEs specifically on OS installations with those as the primary language. It was in the summer of 2016 unrestricted to be able to be used on any OS installation with any IME (whether or not it will display correctly is a different story). It also was unrestricted to allow things like Pen and Touch input (which are routed via IME messages) to display properly inside the console from the TabTip window (the little popup that helps you insert pen/touch writing/keyboard candidates into an application)
@@ -90,7 +100,7 @@
 * Assorted utilities and stuff
 	* `Misc.cpp` (left for us by previous eras of random console devs)
 	* `Util.cpp` (created in our era)
-* Custom zeroing and non-throwing allocator 
+* Custom zeroing and non-throwing allocator
 	* `Newdelete.cpp`
 * Related to inserting text into the TextInfo buffer
 	* `Output.cpp`

doc/bot.md

@@ -8,7 +8,7 @@ We'll be using tags, primarily, to help us understand what needs attention, what
 ### Quick-Guidance to Core Contributors
 1. Look at `Needs-Attention` as top priority
 1. Look at `Needs-Triage` during triage meetings to get a handle on what's new and sort it out
-1. Look at `Needs-Tag-Fix` when you have a few minutes to fix up things tagged impoperly
+1. Look at `Needs-Tag-Fix` when you have a few minutes to fix up things tagged improperly
 1. Manually add `Needs-Author-Feedback` when there's something we need the author to follow up on and want attention if they return it or an auto-close for inactivity if it goes stale.
 
 ### Tagging/Process Details
@@ -33,6 +33,17 @@ We'll be using tags, primarily, to help us understand what needs attention, what
 
 ## Rules
 
+### Triage Shorthand
+- All rules in this category apply to triaging issues. They're shorthand comments that the triage team can use in order to complete the triage process faster. 
+- Only individuals with `Write` or `Admin` privileges on the repository can use these responses.
+
+#### Duplicate Issues
+- When a comment on the thread says `/dup #<issue ID>`...
+1. Reply with a comment explaining that the issue is a duplicate and recommend that the opener and interested parties follow the issue on the listed ID number.
+1. Close the issue
+1. Remove all `Needs-*` tags
+1. Add `Resolution-Duplicate`
+
 ### Issue Management
 
 #### Mark as Triage Needed
@@ -65,10 +76,12 @@ We'll be using tags, primarily, to help us understand what needs attention, what
 - Then close the issue automatically informing the opener that they can resolve the problem and reopen the issue. (See Bug/Feature templates for example situations.)
 
 #### Help ask for Feedback Hub
-- If an issue is tagged `Needs-Feedback-Hub`
-- Then reply to the issue with a bit of text on asking the author to send us data with Feedback Hub and give us the link.
-- And remove the `Needs-Feedback-Hub` tag
-- And add the `Needs-Author-Feedback` tag
+- When a comment on the thread says `/feedback`...
+1. Then reply to the issue with a bit of text on asking the author to send us data with Feedback Hub and give us the link.
+1. And add the `Needs-Author-Feedback` tag
+
+#### Remove Help Wanted from In PR issues
+- If an issue gets the `In-PR` tag when a new PR is created, we will remove the `Help-Wanted` tag to avoid someone trying to work on an issue where another person has already submitted a proposed fix.
 
 ### PR Management
 

doc/building.md

@@ -1,7 +1,7 @@
 
 # How to build Openconsole
 
-Openconsole can be built with Visual Studio or from the command line. There are build scripts for both cmd and powershell in /tools.
+Openconsole can be built with Visual Studio or from the command line. There are build scripts for both cmd and PowerShell in /tools.
 
 When using Visual Studio, be sure to set up the path for code formatting. This can be done in Visual Studio by going to Tools > Options > Text Editor > C++ > Formatting and checking "Use custom clang-format.exe file" and choosing the clang-format.exe in the repository at /dep/llvm/clang-format.exe by clicking "browse" right under the check box.
 
@@ -33,4 +33,4 @@ Openconsole has three configuration types:
 - Release
 - AuditMode
 
-AuditMode is an experimental mode that enables some additional static analyis from CppCoreCheck.
+AuditMode is an experimental mode that enables some additional static analysis from CppCoreCheck.

doc/cascadia/Keybindings-spec.md

@@ -6,7 +6,7 @@
 ## Abstract
 It should be possible to configure the terminal so that it doesn't send certain keystrokes as input to the terminal, and instead triggers certain actions. Examples of these actions could be copy/pasting text, opening a new tab, or changing the font size.
 
-This spec describes a mechanism by which we could provide a common implementation of handling keyboard shortcuts like these. This common implementation could then be leveraged and extended by the UX implementation as to handle certain callbacks in the UX layer. For example, The TerminalCore doesn't have a concept of what a tab is, but the keymap abstraction could raise an event such that a WPF app could implement creating a new tab in its idomatic way, and UWP could implement them in their own way.
+This spec describes a mechanism by which we could provide a common implementation of handling keyboard shortcuts like these. This common implementation could then be leveraged and extended by the UX implementation as to handle certain callbacks in the UX layer. For example, The TerminalCore doesn't have a concept of what a tab is, but the keymap abstraction could raise an event such that a WPF app could implement creating a new tab in its idiomatic way, and UWP could implement them in their own way.
 
 ## Terminology
 * **Key Chord**: This is any possible keystroke that a user can input

doc/cascadia/SettingsSchema.md

@@ -1,80 +1,197 @@
-# Profiles.json Documentation
-
-## Globals
-Properties listed below affect the entire window, regardless of the profile settings.
-
-| Property | Necessity | Type | Default | Description |
-| -------- | --------- | ---- | ------- | ----------- |
-| `alwaysShowTabs` | _Required_ | Boolean | `true` | When set to `true`, tabs are always displayed. When set to `false` and `showTabsInTitlebar` is set to `false`, tabs only appear after typing <kbd>Ctrl</kbd> + <kbd>T</kbd>. |
-| `defaultProfile` | _Required_ | String | PowerShell guid | Sets the default profile. Opens by typing <kbd>Ctrl</kbd> + <kbd>T</kbd> or by clicking the '+' icon. The guid of the desired default profile is used as the value. |
-| `initialCols` | _Required_ | Integer | `120` | The number of columns displayed in the window upon first load. |
-| `initialRows` | _Required_ | Integer | `30` | The number of rows displayed in the window upon first load. |
-| `requestedTheme` | _Required_ | String | `system` | Sets the theme of the application. Possible values: `"light"`, `"dark"`, `"system"` |
-| `showTerminalTitleInTitlebar` | _Required_ | Boolean | `true` | When set to `true`, titlebar displays the title of the selected tab. When set to `false`, titlebar displays "Windows Terminal". |
-| `showTabsInTitlebar` | Optional | Boolean | `true` | When set to `true`, the tabs are moved into the titlebar and the titlebar disappears. When set to `false`, the titlebar sits above the tabs. |
-| `wordDelimiters` | Optional | String | <code>&nbsp;&#x2f;&#x5c;&#x28;&#x29;&#x22;&#x27;&#x2d;&#x3a;&#x2c;&#x2e;&#x3b;&#x3c;&#x3e;&#x7e;&#x21;&#x40;&#x23;&#x24;&#x25;&#x5e;&#x26;&#x2a;&#x7c;&#x2b;&#x3d;&#x5b;&#x5d;&#x7b;&#x7d;&#x7e;&#x3f;│</code><br>_(`│` is `U+2502 BOX DRAWINGS LIGHT VERTICAL`)_ | Determines the delimiters used in a double click selection. |
-
-## Profiles
-Properties listed below are specific to each unique profile.
-
-| Property | Necessity | Type | Default | Description |
-| -------- | --------- | ---- | ------- | ----------- |
-| `acrylicOpacity` | _Required_ | Number | `0.5` | When `useAcrylic` is set to `true`, it sets the transparency of the window for the profile. Accepts floating point values from 0-1. |
-| `closeOnExit` | _Required_ | Boolean | `true` | When set to `true`, the selected tab closes when `exit` is typed. When set to `false`, the tab will remain open when `exit` is typed. |
-| `colorScheme` | _Required_ | String | `Campbell` | Name of the terminal color scheme to use. Color schemes are defined under `schemes`. |
-| `commandline` | _Required_ | String | `powershell.exe` | Executable used in the profile. |
-| `cursorColor` | _Required_ | String | `#FFFFFF` | Sets the cursor color for the profile. Uses hex color format: `"#rrggbb"`. |
-| `cursorShape` | _Required_ | String | `bar` | Sets the cursor shape for the profile. Possible values: `"vintage"` ( &#x2583; ), `"bar"` ( &#x2503; ), `"underscore"` ( &#x2581; ), `"filledBox"` ( &#x2588; ), `"emptyBox"` ( &#x25AF; ) |
-| `fontFace` | _Required_ | String | `Consolas` | Name of the font face used in the profile. We will try to fallback to Consolas if this can't be found or is invalid. |
-| `fontSize` | _Required_ | Integer | `10` | Sets the font size. |
-| `guid` | _Required_ | String | | Unique identifier of the profile. Written in registry format: `"{00000000-0000-0000-0000-000000000000}"`. |
-| `historySize` | _Required_ | Integer | `9001` | The number of lines above the ones displayed in the window you can scroll back to. |
-| `name` | _Required_ | String | `PowerShell Core` | Name of the profile. Displays in the dropdown menu. |
-| `padding` | _Required_ | String | `0, 0, 0, 0` | Sets the padding around the text within the window. Can have three different formats: `"#"` sets the same padding for all sides, `"#, #"` sets the same padding for left-right and top-bottom, and `"#, #, #, #"` sets the padding individually for left, top, right, and bottom. |
-| `snapOnInput` | _Required_ | Boolean | `true` | When set to `true`, the window will scroll to the command input line when typing. When set to `false`, the window will not scroll when you start typing. |
-| `startingDirectory` | _Required_ | String | `%USERPROFILE%` | The directory the shell starts in when it is loaded. |
-| `useAcrylic` | _Required_ | Boolean | `false` | When set to `true`, the window will have an acrylic background. When set to `false`, the window will have a plain, untextured background. |
-| `background` | Optional | String | | Sets the background color of the profile. Overrides `background` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
-| `backgroundImage` | Optional | String | | Sets the file location of the Image to draw over the window background. |
-| `backgroundImageAlignment` | Optional | String | `center` | Sets how the background image aligns to the boundaries of the window. Possible values: `"center"`, `"left"`, `"top"`, `"right"`, `"bottom"`, `"topLeft"`, `"topRight"`, `"bottomLeft"`, `"bottomRight"` |
-| `backgroundImageOpacity` | Optional | Number | `1.0` | Sets the transparency of the background image. Accepts floating point values from 0-1. |
-| `backgroundImageStretchMode` | Optional | String | `uniformToFill` | Sets how the background image is resized to fill the window. Possible values: `"none"`, `"fill"`, `"uniform"`, `"uniformToFill"` |
-| `colorTable` | Optional | Array[String] | | Array of colors used in the profile if `colorscheme` is not set. Colors use hex color format: `"#rrggbb"`. Ordering is as follows: `[black, red, green, yellow, blue, magenta, cyan, white, bright black, bright red, bright green, bright yellow, bright blue, bright magenta, bright cyan, bright white]` |
-| `cursorHeight` | Optional | Integer | | Sets the percentage height of the cursor starting from the bottom. Only works when `cursorShape` is set to `"vintage"`. Accepts values from 25-100. |
-| `foreground` | Optional | String | | Sets the foreground color of the profile. Overrides `foreground` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
-| `icon` | Optional | String | | Image file location of the icon used in the profile. Displays within the tab and the dropdown menu. |
-| `scrollbarState` | Optional | String | | Defines the visibility of the scrollbar. Possible values: `"visible"`, `"hidden"` |
-| `tabTitle` | Optional | String | | Overrides default title of the tab. |
-
-## Schemes
-Properties listed below are specific to each color scheme. [ColorTool](https://github.com/microsoft/terminal/tree/master/src/tools/ColorTool) is a great tool you can use to create and explore new color schemes. All colors use hex color format.
-
-| Property | Necessity | Type | Description |
-| -------- | ---- | ----------- | ----------- |
-| `name` | _Required_ | String | Name of the color scheme. |
-| `foreground` | _Required_ | String | Sets the foreground color of the color scheme. |
-| `background` | _Required_ | String | Sets the background color of the color scheme. |
-| `black` | _Required_ | String | Sets the color used as ANSI black. |
-| `blue` | _Required_ | String | Sets the color used as ANSI blue. |
-| `brightBlack` | _Required_ | String | Sets the color used as ANSI bright black. |
-| `brightBlue` | _Required_ | String | Sets the color used as ANSI bright blue. |
-| `brightCyan` | _Required_ | String | Sets the color used as ANSI bright cyan. |
-| `brightGreen` | _Required_ | String | Sets the color used as ANSI bright green. |
-| `brightPurple` | _Required_ | String | Sets the color used as ANSI bright purple. |
-| `brightRed` | _Required_ | String | Sets the color used as ANSI bright red. |
-| `brightWhite` | _Required_ | String | Sets the color used as ANSI bright white. |
-| `brightYellow` | _Required_ | String | Sets the color used as ANSI bright yellow. |
-| `cyan` | _Required_ | String | Sets the color used as ANSI cyan. |
-| `green` | _Required_ | String | Sets the color used as ANSI green. |
-| `purple` | _Required_ | String | Sets the color used as ANSI purple. |
-| `red` | _Required_ | String | Sets the color used as ANSI red. |
-| `white` | _Required_ | String | Sets the color used as ANSI white. |
-| `yellow` | _Required_ | String | Sets the color used as ANSI yellow. |
-
-## Keybindings
-Properties listed below are specific to each custom key binding.
-
-| Property | Necessity | Type | Description |
-| -------- | ---- | ----------- | ----------- |
-| `command` | _Required_ | String | The command executed when the associated key bindings are pressed. |
-| `keys` | _Required_ | Array[String] | Defines the key combinations used to call the command. |
+# Profiles.json Documentation
+
+## Globals
+Properties listed below affect the entire window, regardless of the profile settings.
+
+| Property | Necessity | Type | Default | Description |
+| -------- | --------- | ---- | ------- | ----------- |
+| `alwaysShowTabs` | _Required_ | Boolean | `true` | When set to `true`, tabs are always displayed. When set to `false` and `showTabsInTitlebar` is set to `false`, tabs only appear after typing <kbd>Ctrl</kbd> + <kbd>T</kbd>. |
+| `copyOnSelect` | Optional | Boolean | `false` | When set to `true`, a selection is immediately copied to your clipboard upon creation. When set to `false`, the selection persists and awaits further action. |
+| `defaultProfile` | _Required_ | String | PowerShell guid | Sets the default profile. Opens by typing <kbd>Ctrl</kbd> + <kbd>T</kbd> or by clicking the '+' icon. The guid of the desired default profile is used as the value. |
+| `initialCols` | _Required_ | Integer | `120` | The number of columns displayed in the window upon first load. |
+| `initialRows` | _Required_ | Integer | `30` | The number of rows displayed in the window upon first load. |
+| `rowsToScroll` | Optional | Integer | `system` | The number of rows to scroll at a time with the mouse wheel. This will override the system setting if the value is not zero or "system". |
+| `requestedTheme` | _Required_ | String | `system` | Sets the theme of the application. Possible values: `"light"`, `"dark"`, `"system"` |
+| `showTerminalTitleInTitlebar` | _Required_ | Boolean | `true` | When set to `true`, titlebar displays the title of the selected tab. When set to `false`, titlebar displays "Windows Terminal". |
+| `showTabsInTitlebar` | Optional | Boolean | `true` | When set to `true`, the tabs are moved into the titlebar and the titlebar disappears. When set to `false`, the titlebar sits above the tabs. |
+| `snapToGridOnResize` | Optional | Boolean | `false` | When set to `true`, the window will snap to the nearest character boundary on resize. When `false`, the window will resize "smoothly" |
+| `tabWidthMode` | Optional | String | `equal` | Sets the width of the tabs. Possible values: `"equal"`, `"titleLength"` |
+| `wordDelimiters` | Optional | String | <code>&nbsp;&#x2f;&#x5c;&#x28;&#x29;&#x22;&#x27;&#x2d;&#x3a;&#x2c;&#x2e;&#x3b;&#x3c;&#x3e;&#x7e;&#x21;&#x40;&#x23;&#x24;&#x25;&#x5e;&#x26;&#x2a;&#x7c;&#x2b;&#x3d;&#x5b;&#x5d;&#x7b;&#x7d;&#x7e;&#x3f;│</code><br>_(`│` is `U+2502 BOX DRAWINGS LIGHT VERTICAL`)_ | Determines the delimiters used in a double click selection. |
+
+## Profiles
+Properties listed below are specific to each unique profile.
+
+| Property | Necessity | Type | Default | Description |
+| -------- | --------- | ---- | ------- | ----------- |
+| `guid` | _Required_ | String | | Unique identifier of the profile. Written in registry format: `"{00000000-0000-0000-0000-000000000000}"`. |
+| `name` | _Required_ | String | | Name of the profile. Displays in the dropdown menu. <br>Additionally, this value will be used as the "title" to pass to the shell on startup. Some shells (like `bash`) may choose to ignore this initial value, while others (`cmd`, `powershell`) may use this value over the lifetime of the application. This "title" behavior can be overriden by using `tabTitle`. |
+| `acrylicOpacity` | Optional | Number | `0.5` | When `useAcrylic` is set to `true`, it sets the transparency of the window for the profile. Accepts floating point values from 0-1. |
+| `background` | Optional | String | | Sets the background color of the profile. Overrides `background` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
+| `backgroundImage` | Optional | String | | Sets the file location of the Image to draw over the window background. |
+| `backgroundImageAlignment` | Optional | String | `center` | Sets how the background image aligns to the boundaries of the window. Possible values: `"center"`, `"left"`, `"top"`, `"right"`, `"bottom"`, `"topLeft"`, `"topRight"`, `"bottomLeft"`, `"bottomRight"` |
+| `backgroundImageOpacity` | Optional | Number | `1.0` | Sets the transparency of the background image. Accepts floating point values from 0-1. |
+| `backgroundImageStretchMode` | Optional | String | `uniformToFill` | Sets how the background image is resized to fill the window. Possible values: `"none"`, `"fill"`, `"uniform"`, `"uniformToFill"` |
+| `closeOnExit` | Optional | String | `graceful` | Sets how the profile reacts to termination or failure to launch. Possible values: `"graceful"` (close when `exit` is typed or the process exits normally), `"always"` (always close) and `"never"` (never close). `true` and `false` are accepted as synonyms for `"graceful"` and `"never"` respectively. |
+| `colorScheme` | Optional | String | `Campbell` | Name of the terminal color scheme to use. Color schemes are defined under `schemes`. |
+| `colorTable` | Optional | Array[String] | | Array of colors used in the profile if `colorscheme` is not set. Array follows the format defined in `schemes`. |
+| `commandline` | Optional | String | | Executable used in the profile. |
+| `cursorColor` | Optional | String | `#FFFFFF` | Sets the cursor color for the profile. Uses hex color format: `"#rrggbb"`. |
+| `cursorHeight` | Optional | Integer | | Sets the percentage height of the cursor starting from the bottom. Only works when `cursorShape` is set to `"vintage"`. Accepts values from 25-100. |
+| `cursorShape` | Optional | String | `bar` | Sets the cursor shape for the profile. Possible values: `"vintage"` ( &#x2583; ), `"bar"` ( &#x2503; ), `"underscore"` ( &#x2581; ), `"filledBox"` ( &#x2588; ), `"emptyBox"` ( &#x25AF; ) |
+| `fontFace` | Optional | String | `Consolas` | Name of the font face used in the profile. We will try to fallback to Consolas if this can't be found or is invalid. |
+| `fontSize` | Optional | Integer | `12` | Sets the font size. |
+| `foreground` | Optional | String | | Sets the foreground color of the profile. Overrides `foreground` set in color scheme if `colorscheme` is set. Uses hex color format: `#rgb` or `"#rrggbb"`. |
+| `hidden` | Optional | Boolean | `false` | If set to true, the profile will not appear in the list of profiles. This can be used to hide default profiles and dynamicially generated profiles, while leaving them in your settings file. |
+| `historySize` | Optional | Integer | `9001` | The number of lines above the ones displayed in the window you can scroll back to. |
+| `icon` | Optional | String | | Image file location of the icon used in the profile. Displays within the tab and the dropdown menu. |
+| `padding` | Optional | String | `8, 8, 8, 8` | Sets the padding around the text within the window. Can have three different formats: `"#"` sets the same padding for all sides, `"#, #"` sets the same padding for left-right and top-bottom, and `"#, #, #, #"` sets the padding individually for left, top, right, and bottom. |
+| `scrollbarState` | Optional | String | | Defines the visibility of the scrollbar. Possible values: `"visible"`, `"hidden"` |
+| `selectionBackground` | Optional | String | | Sets the selection background color of the profile. Overrides `selectionBackground` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
+| `snapOnInput` | Optional | Boolean | `true` | When set to `true`, the window will scroll to the command input line when typing. When set to `false`, the window will not scroll when you start typing. |
+| `source` | Optional | String | | Stores the name of the profile generator that originated this profile. _There are no discoverable values for this field._ |
+| `startingDirectory` | Optional | String | `%USERPROFILE%` | The directory the shell starts in when it is loaded. |
+| `suppressApplicationTitle` | Optional | Boolean | | When set to `true`, `tabTitle` overrides the default title of the tab and any title change messages from the application will be suppressed. When set to `false`, `tabTitle` behaves as normal. |
+| `tabTitle` | Optional | String | | If set, will replace the `name` as the title to pass to the shell on startup. Some shells (like `bash`) may choose to ignore this initial value, while others (`cmd`, `powershell`) may use this value over the lifetime of the application.  |
+| `useAcrylic` | Optional | Boolean | `false` | When set to `true`, the window will have an acrylic background. When set to `false`, the window will have a plain, untextured background. |
+| `experimental.retroTerminalEffect` | Optional | Boolean | `false` | When set to `true`, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed. |
+
+## Schemes
+Properties listed below are specific to each color scheme. [ColorTool](https://github.com/microsoft/terminal/tree/master/src/tools/ColorTool) is a great tool you can use to create and explore new color schemes. All colors use hex color format.
+
+| Property | Necessity | Type | Description |
+| -------- | ---- | ----------- | ----------- |
+| `name` | _Required_ | String | Name of the color scheme. |
+| `foreground` | _Required_ | String | Sets the foreground color of the color scheme. |
+| `background` | _Required_ | String | Sets the background color of the color scheme. |
+| `selectionBackground` | Optional | String | Sets the selection background color of the color scheme. |
+| `black` | _Required_ | String | Sets the color used as ANSI black. |
+| `blue` | _Required_ | String | Sets the color used as ANSI blue. |
+| `brightBlack` | _Required_ | String | Sets the color used as ANSI bright black. |
+| `brightBlue` | _Required_ | String | Sets the color used as ANSI bright blue. |
+| `brightCyan` | _Required_ | String | Sets the color used as ANSI bright cyan. |
+| `brightGreen` | _Required_ | String | Sets the color used as ANSI bright green. |
+| `brightPurple` | _Required_ | String | Sets the color used as ANSI bright purple. |
+| `brightRed` | _Required_ | String | Sets the color used as ANSI bright red. |
+| `brightWhite` | _Required_ | String | Sets the color used as ANSI bright white. |
+| `brightYellow` | _Required_ | String | Sets the color used as ANSI bright yellow. |
+| `cyan` | _Required_ | String | Sets the color used as ANSI cyan. |
+| `green` | _Required_ | String | Sets the color used as ANSI green. |
+| `purple` | _Required_ | String | Sets the color used as ANSI purple. |
+| `red` | _Required_ | String | Sets the color used as ANSI red. |
+| `white` | _Required_ | String | Sets the color used as ANSI white. |
+| `yellow` | _Required_ | String | Sets the color used as ANSI yellow. |
+
+## Keybindings
+Properties listed below are specific to each custom key binding.
+
+| Property | Necessity | Type | Description |
+| -------- | ---- | ----------- | ----------- |
+| `command` | _Required_ | String | The command executed when the associated key bindings are pressed. |
+| `keys` | _Required_ | Array[String] | Defines the key combinations used to call the command. |
+
+### Implemented Commands
+
+Commands listed below are per the implementation in [`src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp`](https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp)
+
+- copy
+- copyTextWithoutNewlines
+- paste
+- newTab
+- openNewTabDropdown
+- duplicateTab
+- newTabProfile0
+- newTabProfile1
+- newTabProfile2
+- newTabProfile3
+- newTabProfile4
+- newTabProfile5
+- newTabProfile6
+- newTabProfile7
+- newTabProfile8
+- closeWindow
+- closeTab
+- closePane
+- switchToTab
+- nextTab
+- prevTab
+- increaseFontSize
+- decreaseFontSize
+- resetFontSize
+- scrollUp
+- scrollDown
+- scrollUpPage
+- scrollDownPage
+- switchToTab0
+- switchToTab1
+- switchToTab2
+- switchToTab3
+- switchToTab4
+- switchToTab5
+- switchToTab6
+- switchToTab7
+- switchToTab8
+- openSettings
+- splitPane
+- resizePaneLeft
+- resizePaneRight
+- resizePaneUp
+- resizePaneDown
+- moveFocusLeft
+- moveFocusRight
+- moveFocusUp
+- moveFocusDown
+- toggleFullscreen
+- find
+
+## Example Keys
+- ctrl+1
+- ctrl+plus
+- alt+-
+- shift+numpad_1
+- ctrL+shift+numpad_plus
+- ctrl+pgdn
+- ctrl+alt+shift+pgup
+
+## Background Images and Icons
+Some Terminal settings allow you to specify custom background images and icons. It is recommended that custom images and icons are stored in system-provided folders and are referred to using the correct [URI Schemes](https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes). URI Schemes provide a way to reference files independent of their physical paths (which may change in the future).
+
+The most useful URI schemes to remember when customizing background images and icons are:
+
+| URI Scheme | Corresponding Physical Path | Use / description |
+| --- | --- | ---|
+| `ms-appdata:///Local/` | `%localappdata%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\` | Per-machine files |
+| `ms-appdata:///Roaming/` | `%localappdata%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\RoamingState\` | Common files |
+
+> ⚠ Note: Do not rely on file references using the `ms-appx` URI Scheme (i.e. icons). These files are considered an internal implementation detail and may change name/location or may be omitted in the future.
+
+### Icons
+Terminal displays icons for each of your profiles which Terminal generates for any built-in shells - PowerShell Core, PowerShell, and any installed Linux/WSL distros. Each profile refers to a stock icon via the `ms-appx` URI Scheme.
+
+> ⚠ Note: Do not rely on the files referenced by the `ms-appx` URI Scheme - they are considered an internal implementation detail and may change name/location or may be omitted in the future.
+
+You can refer to you own icons if you wish, e.g.:
+
+```json
+    "icon" : "C:\\Users\\richturn\\OneDrive\\WindowsTerminal\\icon-ubuntu-32.png",
+```
+
+> 👉 Tip: Icons should be sized to 32x32px in an appropriate raster image format (e.g. .PNG, .GIF, or .ICO) to avoid having to scale your icons during runtime (causing a noticeable delay and loss of quality.)
+
+### Custom Background Images
+You can apply a background image to each of your profiles, allowing you to configure/brand/style each of your profiles independently from one another if you wish.
+
+To do so, specify your preferred `backgroundImage`, position it using `backgroundImageAlignment`, set its opacity with `backgroundImageOpacity`, and/or specify how your image fill the available space using `backgroundImageStretchMode`.
+
+For example:
+```json
+    "backgroundImage": "C:\\Users\\richturn\\OneDrive\\WindowsTerminal\\bg-ubuntu-256.png",
+    "backgroundImageAlignment": "bottomRight",
+    "backgroundImageOpacity": 0.1,
+    "backgroundImageStretchMode": "none"
+```
+
+> 👉 Tip: You can easily roam your collection of images and icons across all your machines by storing your icons and images in OneDrive (as shown above).
+
+With these settings, your Terminal's Ubuntu profile would look similar to this:
+
+![Custom icon and background image](../images/custom-icon-and-background-image.jpg)

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/cascadia/profiles.schema.json

@@ -0,0 +1,783 @@
+{
+  "$id": "https://github.com/microsoft/terminal/blob/master/doc/cascadia/profiles.schema.json",
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Microsoft's Windows Terminal Settings Profile Schema'",
+  "definitions": {
+    "Color": {
+      "default": "#",
+      "pattern": "^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$",
+      "type": "string",
+      "format": "color"
+    },
+    "ProfileGuid": {
+      "default": "{}",
+      "pattern": "^\\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}\\}$",
+      "type": "string"
+    },
+    "ShortcutActionName": {
+      "enum": [
+        "closePane",
+        "closeTab",
+        "closeWindow",
+        "copy",
+        "copyTextWithoutNewlines",
+        "decreaseFontSize",
+        "duplicateTab",
+        "increaseFontSize",
+        "moveFocus",
+        "moveFocusDown",
+        "moveFocusLeft",
+        "moveFocusRight",
+        "moveFocusUp",
+        "newTab",
+        "newTabProfile0",
+        "newTabProfile1",
+        "newTabProfile2",
+        "newTabProfile3",
+        "newTabProfile4",
+        "newTabProfile5",
+        "newTabProfile6",
+        "newTabProfile7",
+        "newTabProfile8",
+        "nextTab",
+        "openNewTabDropdown",
+        "openSettings",
+        "paste",
+        "prevTab",
+        "resetFontSize",
+        "resizePane",
+        "resizePaneDown",
+        "resizePaneLeft",
+        "resizePaneRight",
+        "resizePaneUp",
+        "scrollDown",
+        "scrollDownPage",
+        "scrollUp",
+        "scrollUpPage",
+        "splitHorizontal",
+        "splitVertical",
+        "splitPane",
+        "switchToTab",
+        "switchToTab0",
+        "switchToTab1",
+        "switchToTab2",
+        "switchToTab3",
+        "switchToTab4",
+        "switchToTab5",
+        "switchToTab6",
+        "switchToTab7",
+        "switchToTab8",
+        "toggleFullscreen"
+      ],
+      "type": "string"
+    },
+    "Direction": {
+      "enum": [
+        "left",
+        "right",
+        "up",
+        "down"
+      ],
+      "type": "string"
+    },
+    "SplitState": {
+      "enum": [
+        "vertical",
+        "horizontal"
+      ],
+      "type": "string"
+    },
+    "NewTerminalArgs": {
+      "properties": {
+        "commandline": {
+          "description": "A commandline to use instead of the profile's",
+          "type": "string"
+        },
+        "tabTitle": {
+          "description": "An initial tabTitle to use instead of the profile's",
+          "type": "string"
+        },
+        "startingDirectory": {
+          "description": "A startingDirectory to use instead of the profile's",
+          "type": "string"
+        },
+        "profile": {
+          "description": "Either the GUID or name of a profile to use, instead of launching the default",
+          "type": "string"
+        },
+        "index": {
+          "type": "integer",
+          "description": "The index of the profile in the new tab dropdown to open"
+        }
+      },
+      "type": "object"
+    },
+    "ShortcutAction": {
+      "properties": {
+        "action": {
+          "description": "The action to execute",
+          "$ref": "#/definitions/ShortcutActionName"
+        }
+      },
+      "required": [
+        "action"
+      ],
+      "type": "object"
+    },
+    "CopyAction": {
+      "description": "Arguments corresponding to a Copy Text Action",
+      "allOf": [
+        { "$ref": "#/definitions/ShortcutAction" },
+        {
+          "properties": {
+            "action": { "type": "string", "pattern": "copy" },
+            "trimWhitespace": {
+              "type": "boolean",
+              "default": true,
+              "description": "If true, whitespace is removed and newlines are maintained. If false, newlines are removed and whitespace is maintained."
+            }
+          }
+        }
+      ]
+    },
+    "NewTabAction": {
+      "description": "Arguments corresponding to a New Tab Action",
+      "allOf": [
+        { "$ref": "#/definitions/ShortcutAction" },
+        { "$ref": "#/definitions/NewTerminalArgs" },
+        {
+          "properties": {
+            "action": { "type":"string", "pattern": "newTab" }
+          }
+        }
+      ]
+    },
+    "SwitchToTabAction": {
+      "description": "Arguments corresponding to a Switch To Tab Action",
+      "allOf": [
+        { "$ref": "#/definitions/ShortcutAction" },
+        {
+          "properties": {
+            "action": { "type": "string", "pattern": "switchToTab" },
+            "index": {
+              "type": "integer",
+              "default": 0,
+              "description": "Which tab to switch to, with the first being 0"
+            }
+          }
+        }
+      ],
+      "required": [ "index" ]
+    },
+    "MoveFocusAction": {
+      "description": "Arguments corresponding to a Move Focus Action",
+      "allOf": [
+        { "$ref": "#/definitions/ShortcutAction" },
+        {
+          "properties": {
+            "action": { "type": "string", "pattern": "moveFocus" },
+            "direction": {
+              "$ref": "#/definitions/Direction",
+              "default": "left",
+              "description": "The direction to move focus in, between panes"
+            }
+          }
+        }
+      ],
+      "required": [ "direction" ]
+    },
+    "ResizePaneAction": {
+      "description": "Arguments corresponding to a Resize Pane Action",
+      "allOf": [
+        { "$ref": "#/definitions/ShortcutAction" },
+        {
+          "properties": {
+            "action": { "type": "string", "pattern": "resizePane" },
+            "direction": {
+              "$ref": "#/definitions/Direction",
+              "default": "left",
+              "description": "The direction to move the pane separator in"
+            }
+          }
+        }
+      ],
+      "required": [ "direction" ]
+    },
+    "SplitPaneAction": {
+      "description": "Arguments corresponding to a Split Pane Action",
+      "allOf": [
+        { "$ref": "#/definitions/ShortcutAction" },
+        { "$ref": "#/definitions/NewTerminalArgs" },
+        {
+          "properties": {
+            "action": { "type": "string", "pattern": "splitPane" },
+            "split": {
+              "$ref": "#/definitions/SplitState",
+              "default": "vertical",
+              "description": "The orientation to split the pane in, either vertical (think [|]) or horizontal (think [-])"
+            }
+          }
+        }
+      ],
+      "required": [ "split" ]
+    },
+    "Keybinding": {
+      "additionalProperties": false,
+      "properties": {
+        "command": {
+          "description": "The action executed when the associated key bindings are pressed.",
+            "oneOf": [
+              { "$ref": "#/definitions/CopyAction" },
+              { "$ref": "#/definitions/ShortcutActionName" },
+              { "$ref": "#/definitions/NewTabAction" },
+              { "$ref": "#/definitions/SwitchToTabAction" },
+              { "$ref": "#/definitions/MoveFocusAction" },
+              { "$ref": "#/definitions/ResizePaneAction" },
+              { "$ref": "#/definitions/SplitPaneAction" }
+            ]
+        },
+        "keys": {
+          "description": "Defines the key combinations used to call the command.",
+          "items": {
+            "pattern": "^(?<modifier>(ctrl|alt|shift)\\+?((ctrl|alt|shift)(?<!\\2)\\+?)?((ctrl|alt|shift)(?<!\\2|\\4))?\\+?)?(?<key>[^+\\s]+?)?(?<=[^+\\s])$",
+            "type": "string"
+          },
+          "minItems": 1,
+          "type": "array"
+        }
+      },
+      "required": [
+        "command",
+        "keys"
+      ],
+      "type": "object"
+    },
+    "Globals": {
+      "additionalProperties": true,
+      "description": "Properties that affect the entire window, regardless of the profile settings.",
+      "properties": {
+        "alwaysShowTabs": {
+          "default": true,
+          "description": "When set to true, tabs are always displayed. When set to false and showTabsInTitlebar is set to false, tabs only appear after opening a new tab.",
+          "type": "boolean"
+        },
+        "copyOnSelect": {
+          "default": false,
+          "description": "When set to true, a selection is immediately copied to your clipboard upon creation. When set to false, the selection persists and awaits further action.",
+          "type": "boolean"
+        },
+        "defaultProfile": {
+          "$ref": "#/definitions/ProfileGuid",
+          "description": "Sets the default profile. Opens by clicking the '+' icon or typing the key binding assigned to 'newTab'. The guid of the desired default profile is used as the value."
+        },
+        "initialCols": {
+          "default": 120,
+          "description": "The number of columns displayed in the window upon first load.",
+          "maximum": 999,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "initialRows": {
+          "default": 30,
+          "description": "The number of rows displayed in the window upon first load.",
+          "maximum": 999,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "rowsToScroll": {
+          "default": "system",
+          "description": "The number of rows to scroll at a time with the mouse wheel. This will override the system setting if the value is not zero or 'system'.",
+          "maximum": 999,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "keybindings": {
+          "description": "Properties are specific to each custom key binding.",
+          "items": {
+            "$ref": "#/definitions/Keybinding"
+          },
+          "type": "array"
+        },
+        "requestedTheme": {
+          "default": "system",
+          "description": "Sets the theme of the application.",
+          "enum": [
+            "light",
+            "dark",
+            "system"
+          ],
+          "type": "string"
+        },
+        "showTabsInTitlebar": {
+          "default": true,
+          "description": "When set to true, the tabs are moved into the titlebar and the titlebar disappears. When set to false, the titlebar sits above the tabs.",
+          "type": "boolean"
+        },
+        "showTerminalTitleInTitlebar": {
+          "default": true,
+          "description": "When set to true, titlebar displays the title of the selected tab. When set to false, titlebar displays 'Windows Terminal'.",
+          "type": "boolean"
+        },
+        "snapToGridOnResize": {
+          "default": false,
+          "description": "When set to `true`, the window will snap to the nearest character boundary on resize. When `false`, the window will resize 'smoothly'",
+          "type": "boolean"
+        },
+        "tabWidthMode": {
+          "default": "equal",
+          "description": "Sets the width of the tabs.",
+          "enum": [
+            "equal",
+            "titleLength"
+          ],
+          "type": "string"
+        },
+        "wordDelimiters": {
+          "default": " ./\\()\"'-:,.;<>~!@#$%^&*|+=[]{}~?│",
+          "description": "Determines the delimiters used in a double click selection.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "defaultProfile"
+      ],
+      "type": "object"
+    },
+    "Profile": {
+      "description": "Properties specific to a unique profile.",
+      "additionalProperties": false,
+      "properties": {
+        "acrylicOpacity": {
+          "default": 0.5,
+          "description": "When useAcrylic is set to true, it sets the transparency of the window for the profile. Accepts floating point values from 0-1 (default 0.5).",
+          "maximum": 1,
+          "minimum": 0,
+          "type": "number"
+        },
+        "background": {
+          "$ref": "#/definitions/Color",
+          "description": "Sets the background color of the profile. Overrides background set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\". Default \"#000000\" (black).",
+          "type": ["string", "null"]
+        },
+        "backgroundImage": {
+          "description": "Sets the file location of the Image to draw over the window background.",
+          "type": "string"
+        },
+        "backgroundImageAlignment": {
+          "default": "center",
+          "enum": [
+            "bottom",
+            "bottomLeft",
+            "bottomRight",
+            "center",
+            "left",
+            "right",
+            "top",
+            "topLeft",
+            "topRight"
+          ],
+          "type": "string"
+        },
+        "backgroundImageOpacity": {
+          "description": "(Not in SettingsSchema.md)",
+          "maximum": 1,
+          "minimum": 0,
+          "type": "number"
+        },
+        "backgroundImageStretchMode": {
+          "default": "uniformToFill",
+          "description": "Sets how the background image is resized to fill the window.",
+          "enum": [
+            "fill",
+            "none",
+            "uniform",
+            "uniformToFill"
+          ],
+          "type": "string"
+        },
+        "closeOnExit": {
+          "default": "graceful",
+          "description": "Sets how the profile reacts to termination or failure to launch. Possible values: \"graceful\" (close when exit is typed or the process exits normally), \"always\" (always close) and \"never\" (never close). true and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
+          "oneOf": [
+            {
+              "enum": [
+                "never",
+                "graceful",
+                "always"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "boolean"
+            }
+          ]
+        },
+        "colorScheme": {
+          "default": "Campbell",
+          "description": "Name of the terminal color scheme to use. Color schemes are defined under \"schemes\".",
+          "type": "string"
+        },
+        "colorTable": {
+          "description": "Array of colors used in the profile if colorscheme is not set. Colors use hex color format: \"#rrggbb\". Ordering is as follows: [black, red, green, yellow, blue, magenta, cyan, white, bright black, bright red, bright green, bright yellow, bright blue, bright magenta, bright cyan, bright white]",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "background": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the background color of the color table."
+              },
+              "black": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI black."
+              },
+              "blue": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI blue."
+              },
+              "brightBlack": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright black."
+              },
+              "brightBlue": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright blue."
+              },
+              "brightCyan": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright cyan."
+              },
+              "brightGreen": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright green."
+              },
+              "brightPurple": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright purple."
+              },
+              "brightRed": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright red."
+              },
+              "brightWhite": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright white."
+              },
+              "brightYellow": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI bright yellow."
+              },
+              "cyan": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI cyan."
+              },
+              "foreground": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the foreground color of the color table."
+              },
+              "green": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI green."
+              },
+              "purple": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI purple."
+              },
+              "red": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI red."
+              },
+              "white": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI white."
+              },
+              "yellow": {
+                "$ref": "#/definitions/Color",
+                "description": "Sets the color used as ANSI yellow."
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "commandline": {
+          "description": "Executable used in the profile.",
+          "type": "string"
+        },
+        "connectionType": {
+          "$ref": "#/definitions/ProfileGuid",
+          "description": "A GUID reference to a connection type. Currently undocumented as of 0.3, this is used for Azure Cloud Shell"
+        },
+        "cursorColor": {
+          "$ref": "#/definitions/Color",
+          "default": "#FFFFFF",
+          "description": "Sets the cursor color for the profile. Uses hex color format: \"#rrggbb\"."
+        },
+        "cursorHeight": {
+          "description": "Sets the percentage height of the cursor starting from the bottom. Only works when cursorShape is set to \"vintage\". Accepts values from 25-100.",
+          "maximum": 100,
+          "minimum": 25,
+          "type": "integer"
+        },
+        "cursorShape": {
+          "default": "bar",
+          "description": "Sets the cursor shape for the profile. Possible values: \"vintage\" ( ▃ ), \"bar\" ( ┃, default ), \"underscore\" ( ▁ ), \"filledBox\" ( █ ), \"emptyBox\" ( ▯ )",
+          "enum": [
+            "bar",
+            "emptyBox",
+            "filledBox",
+            "underscore",
+            "vintage"
+          ],
+          "type": "string"
+        },
+        "experimental.retroTerminalEffect": {
+          "description": "When set to true, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed.",
+          "type": "boolean"
+        },
+        "fontFace": {
+          "default": "Consolas",
+          "description": "Name of the font face used in the profile.",
+          "type": "string"
+        },
+        "fontSize": {
+          "default": 12,
+          "description": "Sets the font size.",
+          "minimum": 1,
+          "type": "integer"
+        },
+        "foreground": {
+          "$ref": "#/definitions/Color",
+          "description": "Sets the foreground color of the profile. Overrides foreground set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\". Default \"#ffffff\" (white).",
+          "type": ["string", "null"]
+        },
+        "guid": {
+          "$ref": "#/definitions/ProfileGuid",
+          "description": "Unique identifier of the profile. Written in registry format: \"{00000000-0000-0000-0000-000000000000}\"."
+        },
+        "hidden": {
+          "default": false,
+          "description": "If set to true, the profile will not appear in the list of profiles. This can be used to hide default profiles and dynamicially generated profiles, while leaving them in your settings file.",
+          "type": "boolean"
+        },
+        "historySize": {
+          "default": 9001,
+          "description": "The number of lines above the ones displayed in the window you can scroll back to.",
+          "minimum": -1,
+          "type": "integer"
+        },
+        "icon": {
+          "description": "Image file location of the icon used in the profile. Displays within the tab and the dropdown menu.",
+          "type": "string"
+        },
+        "name": {
+          "description": "Name of the profile. Displays in the dropdown menu.",
+          "minLength": 1,
+          "type": "string"
+        },
+        "padding": {
+          "default": "8, 8, 8, 8",
+          "description": "Sets the padding around the text within the window. Can have three different formats: \"#\" sets the same padding for all sides, \"#, #\" sets the same padding for left-right and top-bottom, and \"#, #, #, #\" sets the padding individually for left, top, right, and bottom.",
+          "pattern": "^-?[0-9]+(\\.[0-9]+)?( *, *-?[0-9]+(\\.[0-9]+)?|( *, *-?[0-9]+(\\.[0-9]+)?){3})?$",
+          "type": "string"
+        },
+        "scrollbarState": {
+          "default": "visible",
+          "description": "Defines the visibility of the scrollbar.",
+          "enum": [
+            "visible",
+            "hidden"
+          ],
+          "type": "string"
+        },
+        "selectionBackground": {
+          "$ref": "#/definitions/Color",
+          "description": "Sets the selection background color of the profile. Overrides selection background set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\"."
+        },
+        "snapOnInput": {
+          "default": true,
+          "description": "When set to true, the window will scroll to the command input line when typing. When set to false, the window will not scroll when you start typing.",
+          "type": "boolean"
+        },
+        "source": {
+          "description": "Stores the name of the profile generator that originated this profile.",
+          "type": "string"
+        },
+        "startingDirectory": {
+          "description": "The directory the shell starts in when it is loaded.",
+          "type": "string"
+        },
+        "suppressApplicationTitle": {
+          "description": "When set to `true`, `tabTitle` overrides the default title of the tab and any title change messages from the application will be suppressed. When set to `false`, `tabTitle` behaves as normal.",
+          "type": "boolean"
+        },
+        "tabTitle": {
+          "description": "If set, will replace the name as the title to pass to the shell on startup. Some shells (like bash) may choose to ignore this initial value, while others (cmd, powershell) may use this value over the lifetime of the application.",
+          "type": "string"
+        },
+        "useAcrylic": {
+          "default": false,
+          "description": "When set to true, the window will have an acrylic background. When set to false, the window will have a plain, untextured background.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "ProfileList": {
+      "description": "A list of profiles and the properties specific to each.",
+      "items": {
+        "$ref": "#/definitions/Profile",
+        "required": [
+          "guid",
+          "name"
+        ]
+      },
+      "type": "array"
+    },
+    "ProfilesObject": {
+      "description": "A list of profiles and default settings that apply to all of them",
+      "properties": {
+        "list": {
+          "$ref": "#/definitions/ProfileList"
+        },
+        "defaults": {
+          "description": "The default settings that apply to every profile.",
+          "$ref": "#/definitions/Profile"
+        }
+      },
+      "type": "object"
+    },
+    "SchemeList": {
+      "description": "Properties are specific to each color scheme. ColorTool is a great tool you can use to create and explore new color schemes. All colors use hex color format.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "name": {
+            "description": "Name of the color scheme.",
+            "minLength": 1,
+            "type": "string"
+          },
+          "background": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the background color of the color scheme."
+          },
+          "black": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI black."
+          },
+          "blue": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI blue."
+          },
+          "brightBlack": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright black."
+          },
+          "brightBlue": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright blue."
+          },
+          "brightCyan": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright cyan."
+          },
+          "brightGreen": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright green."
+          },
+          "brightPurple": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright purple."
+          },
+          "brightRed": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright red."
+          },
+          "brightWhite": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright white."
+          },
+          "brightYellow": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI bright yellow."
+          },
+          "cyan": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI cyan."
+          },
+          "foreground": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the foreground color of the color scheme."
+          },
+          "green": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI green."
+          },
+          "purple": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI purple."
+          },
+          "red": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI red."
+          },
+          "selectionBackground": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the selection background color of the color scheme."
+          },
+          "white": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI white."
+          },
+          "yellow": {
+            "$ref": "#/definitions/Color",
+            "description": "Sets the color used as ANSI yellow."
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "oneOf": [
+    {
+      "allOf": [
+        { "$ref": "#/definitions/Globals" },
+        {
+          "additionalItems": true,
+          "properties": {
+            "profiles": {
+              "oneOf": [
+              { "$ref": "#/definitions/ProfileList" },
+              { "$ref": "#/definitions/ProfilesObject" }
+              ]
+            },
+            "schemes": { "$ref": "#/definitions/SchemeList" }
+          },
+          "required": [
+            "profiles",
+            "schemes",
+            "defaultProfile"
+          ]
+        }
+      ]
+    },
+    {
+      "additionalItems": false,
+      "properties": {
+        "globals": { "$ref": "#/definitions/Globals" },
+        "profiles": {
+          "oneOf": [
+          { "$ref": "#/definitions/ProfileList" },
+          { "$ref": "#/definitions/ProfilesObject" }
+          ]
+        },
+        "schemes": { "$ref": "#/definitions/SchemeList" }
+      },
+      "required": [
+        "profiles",
+        "schemes",
+        "globals"
+      ]
+    }
+  ]
+}

doc/specs/#1043 - Set the initial position of the Terminal/spec.md

@@ -0,0 +1,100 @@
+---
+author: Kaiyu Wang KaiyuWang16/kawa@microsoft.com
+created on: 2019-09-03
+last updated: 2020-01-02
+issue id: #1043
+---
+
+# Set the initial position for terminal
+
+## Abstract
+
+This spec is for task #1043 “Be able to set an initial position for the terminal”. It goes over the details of a new feature that allows users to set the initial position and size of the terminal. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.
+
+## Inspiration
+
+The idea is to allow users to set the initial position of the Terminal when they launch it, prevent the Terminal from appearing on unexpected position (e.g. outside of the screen bounds). We are also going to let users choose to maximize the window when they launch it.
+
+## Solution Design
+
+For now, the Terminal window is put on a default initial position. The program uses CW_USEDEFAULT in the screen coordinates for top-left corner. We have two different types of window – client window and non-client window. However, code path for window creation (WM_CREATE message is shared by the two types of windows) are almost the same for the two types of windows, except that there are some differences in calculation of the width and height of the window.
+
+Two new properties should be added in the json settings file:
+
+**initialPosition**: string. This sets the initial horizontal and vertical position of the top-left corner of the window. This property follows a structure: "X value, Y value" and has following rules:
+
+1. All spaces will be ignored.
+
+2. Both X value and Y values are optional. If anyone of them is missing, or the value is invalid, system default value will be used. Examples:
+
+       ", 1000" equals to (default, 1000)
+       "1000, " equals to (1000, default)
+       "," equals to (default, default)
+       "abc, 1000" equals to (default, 1000)
+
+**launchMode**: string. Determine the launch mode. There are two modes for now
+
+1. maximize: the window will be maximized when launch.
+2. default: the window will be initialized with system default size.
+
+The steps of this process:
+
+1. Set the top-left origin, width and height to CW_USEDEFAULT.
+2. Get the dpi of the nearest monitor; Load settings.
+3. From settings, find the user-defined initial position and launch mode. 
+4. If the user sets custom initial position, calculate the new position considering the current dpi and monitor. If not, use system default value.
+5. If the user set launch mode as "maximize", calculate the new height and width. If the user choose "default", use system default size.
+6. SetWindowPos with the new position and dimension of the window. 
+
+Step 2 to 6 should be done in `AppHost::_HandleCreateWindow`, which is consistent to the current code.
+
+In step 4, we may need to consider the dpi of the current monitor and multi-monitor scenario when calculating the initial position of the window.
+
+Edge cases:
+
+1. Multiple monitors. The user should be able to set the initial position to any monitors attached. For the monitors on the left side of the major monitor, the initial position values are negative. 
+2. If the initial position is larger than the screen resolution and the window top left corner is off-screen, we should let user be able to see and drag the window back on screen. One solution is to set the initial position to the top left corner of the nearest monitor if the top left is off-screen.
+3. If the user wants to launch maximized and provides an initial position, we should launch the maximized window on the top left corner of the monitor where the position is located.
+4. Launch the Terminal on a monitor with custom dpi. Changing the dpi of the monitor will not affect the initial position of the top left corner. So we do not need to handle this case. 
+5. Launch the Terminal on a monitor with custom resolution. Changing the resolution will change the available point for the initial position. (2) already covers this case. 
+
+## UI/UX Design
+
+Upon successful implementation, the user is able to add new properties to the json profile file, which is illustrated in the code block below:
+```json
+"initialPosition": "500,500",
+"launchMode": "default"
+```
+The rest of the UI will be the same of the current Terminal experience, except that the initial position may be different.
+
+### Accessibility
+
+Users can only set the initial position and launch mode in the Json file with keyboard. Thus, this will not affect accessibility. 
+
+### Reliability
+We need to make sure that whatever the initial position is set, the user can access the Terminal window. This is guaranteed because if the top left corner position of the Terminal Window is out of screen, we put it on the top left corner of the screen. 
+
+### Performance, Power, and Efficiency
+
+More data reading and calculation will be included in Terminal Launch process, which may inversely influence the launch time. However, the impact is trivial. 
+
+## Potential Issues
+
+We need to consider multi-monitor scenario. If the user has multiple monitors, we must guarantee that the Terminal could be iniitalized as expected. We can keep an eye on the feedbacks of this feature from the community.
+
+## Future considerations
+
+For now, this feature only allows the user to set initial positon and choose whether to maximize the window when launch. In the future, we may consider follow-up features like:
+
+1. Save the position of the Terminal on exit, and restore the position on the next launch. This could be a true/false feature that users could choose to set.
+
+2. We may need to consider multiple Terminal windows scenario. If the user opens multiple Terminal windows, then we need to consider how to save and restore the position. 
+
+3. We may also consider more launch modes. Like full screen mode and minimized mode. 
+
+Github issue for future follow-ups: https://github.com/microsoft/terminal/issues/766
+
+## Resources
+
+Github issue:
+https://github.com/microsoft/terminal/issues/1043

doc/specs/#1142 - Keybinding Arguments.md

@@ -0,0 +1,362 @@
+---
+author: Mike Griese @zadjii-msft
+created on: 2019-06-19
+last updated: 2019-07-14
+issue id: 1142
+---
+
+# Arbitrary Keybindings Arguments
+
+## Abstract
+
+The goal of this change is to both simplify the keybindings, and also enable far
+more flexibility when editing a user's keybindings.
+
+Currently, we have many actions that are very similar in implementation - for
+example, `newTabProfile0`, `newTabProfile1`, `newTabProfile2`, etc. All these
+actions are _fundamentally_ the same function. However, we've needed to define 9
+different actions to enable the user to provide different values to the `newTab`
+function.
+
+With this change, we'll be able to remove these _essentially_ duplicated events,
+and allow the user to specify arbitrary arguments to these functions.
+
+## Inspiration
+
+Largely inspired by the keybindings in VsCode and Sublime Text. Additionally,
+much of the content regarding keybinding events being "handled" was designed as
+a solution for [#2285].
+
+## Solution Design
+
+We'll need to introduce args to some actions that we already have defined. These
+are the actions I'm thinking about when writing this spec:
+
+```csharp
+    // These events already exist like this:
+    delegate void NewTabWithProfileEventArgs(Int32 profileIndex);
+    delegate void SwitchToTabEventArgs(Int32 profileIndex);
+    delegate void ResizePaneEventArgs(Direction direction);
+    delegate void MoveFocusEventArgs(Direction direction);
+
+    // These events either exist in another form or don't exist.
+    delegate void CopyTextEventArgs(Boolean copyWhitespace);
+    delegate void ScrollEventArgs(Int32 numLines);
+    delegate void SplitProfileEventArgs(Orientation splitOrientation, Int32 profileIndex);
+```
+
+Ideally, after this change, the bindings for these actions would look something
+like the following:
+
+```js
+{ "keys": ["ctrl+shift+1"], "command": "newTabProfile", "args": { "profileIndex":0 } },
+{ "keys": ["ctrl+shift+2"], "command": "newTabProfile", "args": { "profileIndex":1 } },
+// etc...
+
+{ "keys": ["alt+1"], "command": "switchToTab", "args": { "index":0 } },
+{ "keys": ["alt+2"], "command": "switchToTab", "args": { "index":1 } },
+// etc...
+
+{ "keys": ["alt+shift+down"], "command": "resizePane", "args": { "direction":"down" } },
+{ "keys": ["alt+shift+up"], "command": "resizePane", "args": { "direction":"up" } },
+// etc...
+
+{ "keys": ["alt+down"], "command": "moveFocus", "args": { "direction":"down" } },
+{ "keys": ["alt+up"], "command": "moveFocus", "args": { "direction":"up" } },
+// etc...
+
+{ "keys": ["ctrl+c"], "command": "copy", "args": { "copyWhitespace":true } },
+{ "keys": ["ctrl+shift+c"], "command": "copy", "args": { "copyWhitespace":false } },
+
+{ "keys": ["ctrl+shift+down"], "command": "scroll", "args": { "numLines":1 } },
+{ "keys": ["ctrl+shift+up"], "command": "scroll", "args": { "numLines":-1 } },
+
+{ "keys": ["ctrl+alt+1"], "command": "splitProfile", "args": { "orientation":"vertical", "profileIndex": 0 } },
+{ "keys": ["ctrl+alt+shift+1"], "command": "splitProfile", "args": { "orientation":"horizontal", "profileIndex": 0 } },
+{ "keys": ["ctrl+alt+2"], "command": "splitProfile", "args": { "orientation":"vertical", "profileIndex": 1 } },
+{ "keys": ["ctrl+alt+shift+2"], "command": "splitProfile", "args": { "orientation":"horizontal", "profileIndex": 1 } },
+// etc...
+```
+
+Note that instead of having 9 different `newTabProfile<N>` actions, we have a
+singular `newTabProfile` action, and that action requires a `profileIndex` in
+the `args` object.
+
+Also, pay attention to the last set of keybindings, the `splitProfile` ones.
+This is a function that requires two arguments, both an `orientation` and a
+`profileIndex`. Before this change we would have needed to create 20 separate
+actions (10 profile indices * 2 directions) to handle these cases. Now it can
+be done with a single action that can be much more flexible in its
+implementation.
+
+### Parsing KeyBinding Arguments
+
+We'll add two new interfaces: `IActionArgs` and `IActionEventArgs`. Classes that
+implement `IActionArgs` will contain all the per-action args, like
+`CopyWhitespace` or `ProfileIndex`. `IActionArgs` by itself will be an empty
+interface, but all other arguments will derive from it. `IActionEventArgs` will
+have a single property `Handled`, which will be used for indicating if a
+particular event was processed or not. When parsing args, we'll build
+`IActionArgs` to contain all the parameters. When dispatching events, we'll
+build `IActionEventArgs` using the `IActionArgs` to set all the parameter values.
+
+All current keybinding events will be changed from their current types to
+`TypedEventHandler`s. These `TypedEventHandler`s second param will always be an
+instance of `IActionEventArgs`. So, for example:
+
+```csharp
+
+delegate void CopyTextEventArgs();
+delegate void NewTabEventArgs();
+delegate void NewTabWithProfileEventArgs(Int32 profileIndex);
+// ...
+
+[default_interface]
+runtimeclass AppKeyBindings : Microsoft.Terminal.Settings.IKeyBindings
+{
+    event CopyTextEventArgs CopyText;
+    event NewTabEventArgs NewTab;
+    event NewTabWithProfileEventArgs NewTabWithProfile;
+```
+
+Becomes:
+
+```csharp
+interface IActionArgs { /* Empty */ }
+
+runtimeclass ActionEventArgs
+{
+    Boolean Handled;
+    ActionArgs Args;
+}
+
+runtimeclass CopyTextArgs : IActionArgs
+{
+    Boolean CopyWhitespace;
+}
+
+runtimeclass NewTabWithProfileArgs : IActionArgs
+{
+    Int32 ProfileIndex;
+}
+runtimeclass NewTabWithProfileEventArgs : NewTabWithProfileArgs, IActionArgs { }
+
+[default_interface]
+runtimeclass AppKeyBindings : Microsoft.Terminal.Settings.IKeyBindings
+{
+    event Windows.Foundation.TypedEventHandler<AppKeyBindings, ActionEventArgs> CopyText;
+    event Windows.Foundation.TypedEventHandler<AppKeyBindings, ActionEventArgs> NewTab;
+    event Windows.Foundation.TypedEventHandler<AppKeyBindings, ActionEventArgs> NewTabWithProfile;
+```
+
+In this above example, the `CopyTextArgs` class actually contains all the
+potential arguments to the Copy action. `ActionEventArgs` is the class that
+holds any `ActionArgs`. When we parse the arguments, we'll build a
+`CopyTextArgs`, and when we're dispatching the event, we'll build a
+`ActionEventArgs` that holds a `CopyTextArgs` as its `Args` value, and dispatch
+the `ActionEventArgs` object.
+
+
+We'll also change our existing map in the `AppKeyBindings` implementation.
+Currently, it's a `std::unordered_map<KeyChord, ShortcutAction, ...>`, which
+uses the `KeyChord` to lookup the `ShortcutAction`. We'll need to introduce a
+new type `ActionAndArgs`:
+
+```csharp
+runtimeclass ActionAndArgs
+{
+    ShortcutAction Action;
+    IActionArgs Args;
+}
+```
+
+and we'll change the map in `AppKeyBindings` to a `std::unordered_map<KeyChord,
+ActionAndArgs, ...>`.
+
+When we're parsing keybindings, we'll need to construct args for each of the
+events to go with each binding. When we find some key chord bound to a given
+Action, we'll construct the `IActionArgs` for that action. For many actions,
+these args will be an empty class. However, when we do find an action that needs
+additional parsing, `AppKeyBindingsSerialization` will do the extra work to
+parse the args for that action.
+
+We'll keep a collection of functions that can be used for quickly determining
+how to parse the args for an action if necessary. This map will be a
+`std::unordered_map<ShortcutAction, function<IActionArgs(Json::Value)>>`. For
+most actions which don't require args, the function in this map will be set to
+nullptr, and we'll know that the action doesn't need to parse any more args.
+However, for actions that _do_ require args, we'll set up a global function that
+can be used to parse a json blob into an `IActionArgs`.
+
+Once the `IActionArgs` is built for the keybinding, we'll set it in
+`AppKeyBindings` with a updated `AppKeyBindings::SetKeyBinding` call.
+`SetKeyBinding`'s signature will be updated to take a `ActionAndArgs` instead.
+Should an action not need arguments, the `Args` member can be left `null` in the
+`ActionAndArgs`.
+
+### Executing KeyBinding Actions with Arguments
+
+When we're handling a keybinding in `AppKeyBindings::_DoAction`, we'll trigger
+the event handlers with the `IActionArgs` we've stored in the map with the
+`ShortcutAction`.
+
+Then, in `App`, we'll handle each of these events. We set up lambdas as event
+handlers for each event in `App::_HookupKeyBindings`. In each of those
+functions, we'll inspect the `IActionArgs` parameter, and use args from its
+implementation to call callbacks in the `App` class. We will update `App` to
+have methods defined with the actual keybinding function signatures.
+
+Instead of:
+
+```c++
+    void App::_HookupKeyBindings(TerminalApp::AppKeyBindings bindings) noexcept
+    {
+        // ...
+        bindings.NewTabWithProfile([this](const auto index) { _OpenNewTab({ index }); });
+    }
+```
+
+The code will look like:
+
+```c++
+    void App::_HookupKeyBindings(TerminalApp::AppKeyBindings bindings) noexcept
+    {
+        // ...
+        bindings.NewTabWithProfile({ this, &App::_OpenNewTab });
+    }
+    // ...
+    void App::_OpenNewTab(const TerminalApp::AppKeyBindings& sender, const NewTabEventArgs& args)
+    {
+        auto profileIndex = args.ProfileIndex();
+        args.Handled(true);
+        // ...
+    }
+```
+
+### Handling Keybinding Events
+
+Common to all implementations of `IActionArgs` is the `Handled` property. This
+will let the app indicate if it was able to actually process a keybinding event
+or not. While in the large majority of cases, the events will all be marked
+handled, there are some scenarios where the Terminal will need to know if the
+event could not be performed. For example, in the case of the `copy` event, the
+Terminal is only capable of copying text if there's actually a selection active.
+If there isn't a selection active, the `App` should make sure to not mark the
+event as not handled (it will leave `args.Handled(false)`). The App should only
+mark an event handled if it has actually dispatched the event.
+
+When an event is handled, we'll make sure to return `true` from
+`AppKeyBindings::TryKeyChord`, so that the terminal does not actually process
+that keypress. For events that were not handled by the application, the terminal
+will get another chance to dispatch the keypress.
+
+### Serializing KeyBinding Arguments
+
+Similar to how we parse arguments from the json, we'll need to update the
+`AppKeyBindingsSerialization` code to be able to serialize the arguments from a
+particular `IActionArgs`.
+
+## UI/UX Design
+
+### Keybindings in the New Tab Dropdown
+
+Small modifications will need to be made to the code responsible for the new tab
+dropdown. The new tab dropdown currently also displays the keybindings for each
+profile in the new tab dropdown. It does this by querying for the keybinding
+associated with each action. As we'll be removing the old `ShortcutAction`s that
+this dropdown uses, we'll need a new way to find which key chord corresponds to
+opening a given profile.
+
+We'll need to be able to not only lookup a keybinding by `ShortcutAction`, but
+also by a `ShortcutAction` and `IActionArgs`. We'll need to update the
+`AppKeyBindings::GetKeyBinding` method to also accept a `IActionArgs`. We'll
+also probably want each `IActionArgs` implementation to define an
+`Equals(IActionArgs)` method, so that we can easily check if two different
+`IActionArgs` are the same in this method.
+
+## Capabilities
+### Accessibility
+
+N/A
+
+### Security
+
+This should not introduce any _new_ security concerns. We're relying on the
+security of jsoncpp for parsing json. Adding new keys to the settings file
+will rely on jsoncpp's ability to securely parse those json values.
+
+### Reliability
+
+We'll need to make sure that invalid keybindings are ignored. Currently, we
+already gracefully ignore keybindings that have invalid `keys` or invalid
+`commands`. We'll need to add additional validation on invalid sets of `args`.
+When we're parsing the args from a Json blob, we'll make sure to only ever look
+for keys we're expecting and ignore everything else.
+
+If a keybinding requires certain args, but those args are not provided, we'll
+need to make sure those args each have reasonable default values to use. If for
+any reason a reasonable default can't be used for a keybinding argument, then
+we'll need to make sure to display an error dialog to the user for that
+scenario.
+
+When we're re-serializing settings, we'll only know about the keybinding arg
+keys that were successfully parsed. Other keys will be lost on re-serialization.
+
+### Compatibility
+
+This change will need to carefully be crafted to enable upgrading the legacy
+keybindings seamlessly. For most actions, the upgrade should be seamless. Since
+they already don't have args, their serializations will remain exactly the same.
+
+However, for the following actions that we'll be removing in favor of actions
+with arguments, we'll need to leave legacy deserialization in place to be able
+to find these old actions, and automatically build the correct `IActionArgs`
+for them:
+
+* `newTabProfile<n>`
+    - We'll need to make sure to build args with the right `profileIndex`
+      corresponding to the old action.
+* `switchToTab<n>`
+    - We'll need to make sure to build args with the right `index` corresponding
+      to the old action.
+* `resizePane<direction>` and `moveFocus<direction>`
+    - We'll need to make sure to build args with the right `direction`
+      corresponding to the old action.
+* `scroll<direction>`
+    - We'll need to make sure to build args with the right `amount` value
+      corresponding to the old action. `Up` will be -1, and `Down` will be 1.
+
+### Performance, Power, and Efficiency
+
+N/A
+
+## Potential Issues
+
+N/A
+
+## Future considerations
+
+* Should we support some sort of conversion from num keys to an automatic arg?
+  For example, by default, <kbd>Alt+&lt;N&gt;</kbd> to focuses the
+  Nth tab. Currently, those are 8 separate entries in the keybindings. Should we
+  enable some way for them be combined into a single binding entry, where the
+  binding automatically recieves the number pressed as an arg? I couldn't find
+  any prior art of this, so it doesn't seem worth it to try and invent
+  currently. This might be something that we want to loop back on, but for the
+  time being, it remains out of scope of this PR.
+* When we inevitable support extensions, we'll need to allow extensions to also
+  be able to support their own custom keybindings and args. We'll probably want
+  to pass the settings to the extension to have the extension parse its own
+  settings. We'll want to be able to ask the extension for its own set of
+  `ActionAndArgs`<sup>[1]</sup> that it builds from the `keybindings`.  Once we
+  have that set of actions, we'll be able to store them locally, and dispatch
+  them quickly.
+  - [1] We probably won't be able to use the `ActionAndArgs` class directly,
+    since that class is specific to the actions we define. We'll need another
+    way for extensions to be able to uniquely identify their own actions.
+
+## Resources
+
+N/A
+
+[#2285]: https://github.com/microsoft/terminal/issues/2285

doc/specs/#2325 - Default Profile Settings.md

@@ -0,0 +1,346 @@
+---
+author: Mike Griese @zadjii-msft
+created on: 2019-11-13
+last updated: 2019-12-05
+issue id: #2325
+---
+
+# Default Profile Settings
+
+## Abstract
+
+Oftentimes, users have some common settings that they'd like applied to all of
+their profiles, without needing to manually edit the settings of each of them.
+This doc will cover some of the many proposals on how to expose that
+functionality to the user in our JSON settings model. In this first document,
+we'll examine a number of proposed solutions, as well as state our finalized
+design.
+
+## Inspiration
+
+During the course of the pull request review on [#3369], the original pull
+request for this feature's implementation, it became apparent that the entire
+team has differing opinions on how this feature should be exposed to the user.
+This doc is born from that discussion.
+
+## Solution Proposals
+
+The following are a number of different proposals of different ways to achieve
+the proposed functionality:
+
+1. [`defaultSettings` Profile object in the global settings](#proposal-1-defaultsettings-profile-object-in-the-global-settings)
+2. [`__default__` Profile object in the user's profiles](#proposal-2-__default__-profile-object-in-the-users-profiles)
+3. [Change `profiles` to an object with a `list` of profiles and a `defaults`](#proposal-3-change-profiles-to-an-object-with-a-list-of-profiles-and-a-defaults-object)
+   object
+4. [`inheritFrom` in profiles](#proposal-4-inheritfrom-in-profiles)
+
+### Proposal 1: `defaultSettings` Profile object in the global settings
+
+```json
+{
+    "$schema": "https://aka.ms/terminal-profiles-schema",
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "defaultSettings":
+    {
+        "useAcrylic": true,
+        "acrylicOpacity": 0.1,
+        "fontFace": "Cascadia Code",
+        "fontSize": 10
+    },
+    "requestedTheme" : "dark",
+    "showTabsInTitlebar" : true,
+    "profiles":
+    [
+        {
+            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+            "name": "Windows PowerShell",
+            "commandline": "powershell.exe",
+            "hidden": false
+        },
+        {
+            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+            "name": "cmd",
+            "commandline": "cmd.exe",
+            "hidden": false
+        }
+    ],
+    "schemes": [],
+    "keybindings": []
+}
+```
+#### Benefits
+
+##### Clearly encapsulates the default profile settings
+Puts all the default profiles settings in one object. It's immediately obvious
+when scanning the file where the defaults are.
+
+##### Simple to understand
+There's one object that applies to all the subsequent profiles, and that
+object is the `defaultSettings` object.
+
+#### Concerns
+
+##### What do we name this setting?
+People were concerned about the naming of this property. No one has a name that
+we're quite happy with:
+
+* `defaultSettings`: This kinda seems to conflict conceptually with
+  "defaults.json". It's different, but is that obvious?
+* `defaultProfileSettings`: Implies "settings of the default profile"
+* `defaults`: This kinda seems to conflict conceptually with "defaults.json"
+* `baseProfileSettings`: not the worst, but not terribly intuitive
+* Others considered with less enthusiasm
+    - `profiles.defaults`: people don't love the idea of a `.`, but hey, VsCode does it.
+    - `inheritedSettings`
+    - `rootSettings`
+    - `globalSettings`: again maybe conflicts a bit with other concepts/properties
+    - `profileSettings`
+    - `profilePrototype`
+
+##### Why is there this random floating profile in the global settings?
+
+Users may be confused about the purpose of this random `Profile` that's in the
+globals. What's that profile doing there? Is _it_ the default profile?
+
+### Proposal 2: `__default__` Profile object in the user's profiles
+```json
+{
+    "$schema": "https://aka.ms/terminal-profiles-schema",
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "requestedTheme" : "dark",
+    "showTabsInTitlebar" : true,
+    "profiles":
+    [
+        {
+            "guid": "__default__",
+            "useAcrylic": true,
+            "acrylicOpacity": 0.1,
+            "fontFace": "Cascadia Code",
+            "fontSize": 10
+        },
+        {
+            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+            "name": "Windows PowerShell",
+            "commandline": "powershell.exe",
+            "hidden": false
+        },
+        {
+            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+            "name": "cmd",
+            "commandline": "cmd.exe",
+            "hidden": false
+        }
+    ],
+    "schemes": [],
+    "keybindings": []
+}
+```
+
+#### Benefits
+##### Encapsulates the default profile settings
+Puts all the default profiles settings in one object. Probably not as clear as
+proposal 1, since it could be _anywhere_ in the list of profiles.
+
+##### Groups default profile settings with profiles
+In this proposal, the default profile is grouped into the same list of objects
+as the other profiles. All the profiles, and the defaults are all under the
+`"profiles"` object. Makes sense.
+
+#### Concerns
+##### Mysterious `__defaults__` GUID
+The only way to _definitively_ identify that this profile is special is by
+giving it a constant string. This string is _not_ a guid, which again, would be
+obvious.
+
+##### Unintuitive
+Adding a profile that has a mysterious `guid` value use that profile as the
+"defaults" is _very_ unintuitive. Nothing aside from documentation would
+indicate to the user "hey, add this magic profile blob to use as defaults across
+all your profiles".
+
+##### Why does this one profile object apply to all the others
+It might be unintuitive that one profile from the list of profiles affects all
+the others.
+
+### Proposal 3: Change `profiles` to an object with a `list` of profiles and a `defaults` object
+
+```json
+{
+    "$schema": "https://aka.ms/terminal-profiles-schema",
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "requestedTheme" : "dark",
+    "showTabsInTitlebar" : true,
+    "profiles":
+    {
+        "defaults": {
+            "useAcrylic": true,
+            "acrylicOpacity": 0.1,
+            "fontFace": "Cascadia Code",
+            "fontSize": 10
+        },
+        "list":[
+            {
+                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+                "name": "Windows PowerShell",
+                "commandline": "powershell.exe",
+                "hidden": false
+            },
+            {
+                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+                "name": "cmd",
+                "commandline": "cmd.exe",
+                "hidden": false
+            }
+        ]
+    },
+    "schemes": [],
+    "keybindings": []
+}
+```
+
+#### Benefits
+##### Groups default profile settings with profiles
+In this proposal, the default profile is grouped into the same object as the
+list of profiles. All the profiles, and the defaults are all under the
+`"profiles"` object. Makes sense.
+
+##### Backwards compatible
+Fortunately, we can add this functionality _without breaking the existing
+schema_. With Jsoncpp, we can determine at runtime if an object is an _array_ or
+an _object_. If it's an array, we can fall back to the current behavior, safe in
+our knowledge that there's no defaults object. If the object is an array
+however, we can then dig into the object to find the default profile and the
+list of profiles.
+
+#### Concerns
+##### Substantial schema change
+This is a pretty big delta to the settings schema. Instead of using `profiles`
+as a list of `Profile` objects, it instead becomes an object, with a list inside
+it.
+
+As noted above, we could gracefully upgrade this. If the `profiles` object is a
+list, then we can assume there's no `defaults`. This ensures that user's current
+settings files don't break. This is not a major problem.
+
+##### Adds another level of indentation to all profiles
+Some people just hate having things indented this much. 4 layers of indentation
+is quite a lot.
+
+### Proposal 4: `inheritFrom` in profiles
+
+```json
+{
+    "$schema": "https://aka.ms/terminal-profiles-schema",
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "requestedTheme" : "dark",
+    "showTabsInTitlebar" : true,
+    "profiles":
+    [
+        {
+            "guid": "{11111111-1111-1111-1111-111111111111}",
+            "hidden": true,
+            "useAcrylic": true,
+            "acrylicOpacity": 0.1,
+            "fontFace": "Cascadia Code",
+            "fontSize": 10
+        },
+        {
+            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+            "inheritFrom": "{11111111-1111-1111-1111-111111111111}",
+            "name": "Windows PowerShell",
+            "commandline": "powershell.exe",
+            "hidden": false
+        },
+        {
+            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+            "inheritFrom": "{11111111-1111-1111-1111-111111111111}",
+            "name": "cmd",
+            "commandline": "cmd.exe",
+            "hidden": false
+        },
+        {
+            "guid": "{0caa0dad-ffff-5f56-a8ff-afceeeaa6101}",
+            "inheritFrom": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+            "name": "This is another CMD",
+            "commandline": "cmd.exe /c myCoolScript.bat",
+            "hidden": false
+        }
+    ],
+    "schemes": [],
+    "keybindings": []
+}
+```
+
+#### Benefits
+
+##### Matches the existing settings model without major refactoring
+Simply adding a new property to `Profile` would not majorly alter the structure
+of the file.
+
+##### Property name is unique
+`inheritFrom` is very unique relative to other keys we already have.
+
+##### Powerful
+This lets the user have potentially many layers of settings grouping. hese
+layers would let the user seperate out common settings however they like,
+without forcing them to a single "default" profile. They could potentially have
+many "default" profiles, e.g.
+* one that's used for all their WSL profiles, with `startingDirectory` set to
+  `~` and `fontFace` set to "Ubuntu Mono"
+* One that's used for all their powershell profiles
+
+etc.
+
+#### Concerns
+
+##### GUIDs are not human friendly
+
+Using the guid in the `inheritFrom` field is the only way to be sure we're
+uniquely identifying profiles. However, guids are notoriously un-friendly. The
+above example manually uses `"{11111111-1111-1111-1111-111111111111}"` as the
+guid of the "default" profile, but inheriting from other profiles with "real"
+GUIDs would be less understandable. Consider the "This is another CMD" case,
+where it's inheriting from the "cmd" profile. That `"inheritFrom"` value does
+not mean at a quick glance "cmd".
+
+##### We have to make sure that there are no cycles as we're layering
+
+This is mostly a technical challenge, but this does make the implementation a
+bit trickier.
+
+##### How does this work with the settings UI?
+
+When the user edits settings for a profile with the UI, do we only place the
+changes in the top-most profile?
+
+How do we communicate in the UI that a profile is inheriting settings from other
+profiles?
+
+##### Harder to mentally parse
+Maybe not as easy to mentally picture how one profile inherits from another. The
+user would probably need to manually build the tree of profile inheritance in
+their own head to understand how a profile gets its settings.
+
+## Conclusions
+
+After discussion the available options, the team has settled on proposal 3. The
+major selling points being:
+* It groups the new "default profile settings" with the rest of the profile
+  settings
+* While being a schema change, it's not a _breaking_ schema change.
+* When looking at the settings, it's easy to understand how they're related
+
+We also like the idea of proposal 4, but felt that it was too heavy-handed of an
+approach for this relatively simple feature. It's been added to the backlog of
+terminal features, tracked in [#3818].
+
+## Resources
+
+* Default Profile for Common Profile Settings (the original issue) [#2325]
+* Add support for "User Default" settings (the original PR) [#3369]
+* Add support for inheriting and overriding another profile's settings [#3818]
+
+<!-- Footnotes -->
+[#2325]: https://github.com/microsoft/terminal/issues/2325
+[#3369]: https://github.com/microsoft/terminal/pull/3369
+[#3818]: https://github.com/microsoft/terminal/issues/3818

doc/specs/#2563 - closeOnExit and TerminalConnection evolution.md

@@ -0,0 +1,107 @@
+---
+author: Dustin Howett @DHowett-MSFT
+created on: 2019-07-19
+last updated: 2019-11-05
+issue id: "#2563"
+---
+
+# Improvements to CloseOnExit
+
+## Abstract
+
+This specification describes an improvement to the `closeOnExit` profile feature and the `ITerminalConnection` interface that will offer greater flexibility and allow us to provide saner defaults in the face of unreliable software.
+
+### Conventions and Terminology
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+
+## Inspiration
+
+Other terminal emulators like ConEmu have a similar feature.
+
+## Solution Design
+
+### `ITerminalConnection` Changes
+
+* The `TerminalConnection` interface will be augmented with an enumerator and a set of events regarding connection state transitions.
+    * enum `TerminalConnection::ConnectionState`
+        * This enum attempts to encompass all potential connection states, even those which do not make sense for a local terminal.
+        * The wide variety of values will be useful to indicate state changes in a user interface.
+        * `NotConnected`: All new connections will start out in this state
+        * `Connecting`: The connection has been initated, but has not yet completed connecting.
+        * `Connected`: The connection is active.
+        * `Closing`: The connection is being closed (usually by request).
+        * `Closed`: The connection has been closed, either by request or from the remote end terminating successfully.
+        * `Failed`: The connection was unexpectedly terminated.
+    * event `StateChanged(ITerminalConnection, IInspectable)`
+        * (the `IInspectable` argument is recommended and required for a typed event handler, but it will bear no payload.)
+    * event `TerminalDisconnected` will be removed, as it is replaced by `StateChanged`
+    * **NOTE**: A conforming implementation MUST treat states as a directed acyclic graph. States MUST NOT be transitioned in reverse.
+* A helper class may be provided for managing state transitions.
+
+### `TerminalControl` Changes
+
+* As the decision as to whether to close a terminal control hosting a connection that has transitioned into a terminal state will be made by the application, the unexpressive `Close` event will be removed and replaced with a `ConnectionStateChanged` event.
+* `event ConnectionStateChanged(TerminalControl, IInspectable)` event will project its connection's `StateChanged` event.
+* TerminalControl's new `ConnectionState` will project its connection's `State`.
+    * (this is indicated for an eventual data binding; see Future Considerations.)
+
+### Application and Settings
+
+1. The existing `closeOnExit` profile key will be replaced with an enumerated string key supporting the following values (behaviours):
+    * `always` - a tab or pane hosting this profile will always be closed when the launched connection reaches a terminal state.
+    * `graceful` - a tab or pane hosting this profile will be closed if and only if the launched connection reaches the `Closed` terminal state.
+    * `never` - a tab or pane hosting this profile will not automatically close.
+    * See the Compatibility section for information on the legacy settings transition. 
+    * **The new default value for `closeOnExit` will be `graceful`.**
+2. `Pane` will remain responsible for making the final determination as to whether it is closed based on the settings of the profile it is hosting.
+
+## UI/UX Design
+
+* The existing `ITerminalConnection` implementations will be augmented to print out interesting and useful status information when they transition into a `Closed` or `Failed` state.
+    * Example (ConPTY connection)
+        * The pseudoconsole cannot be opened, or the process fails to launch.<br>`[failed to spawn 'thing': 0x80070002]`, transition to `Failed`.
+        * The process exited unexpectedly.<br>`[process exited with code 300]`, transition to `Failed`.
+        * The process exited normally.<br>`[process exited with code 0]`, transition to `Closed`.
+* _The final message will always be printed_ regardless of user configuration.
+* If the user's settings specify `closeOnExit: never/false`, the terminal hosting the connection will never be automatically closed. The message will remain on-screen.
+* If the user's settings specify `closeOnExit: graceful/true`, the terminal hosting the connection _will_ automatically be closed if the connection's state is `Closed`. A connection in the `Failed` state will not be closed, and the message will remain on-screen.
+* If the user's settings specify `closeOnExit: always`, the terminal hosting the connection will be closed. The message will not be seen.
+
+## Capabilities
+
+### Accessibility
+
+This will give users of all technologies a way to know when their shell has failed to launch or has exited with an unexpected status code.
+
+### Security
+
+There will be no impact to security.
+
+### Reliability
+
+Windows Terminal will no longer immediately terminate on startup if the user's shell doesn't exist.
+
+### Compatibility
+
+There is an existing `closeOnExit` _boolean_ key that a user may have configured in profiles.json. The boolean values should map as follows:
+
+* `true` -> `graceful`
+* `false` -> `never`
+
+This will make for a clean transition to Windows Terminal's sane new defaults.
+
+### Performance, Power, and Efficiency
+
+## Potential Issues
+
+There will be no impact to Performance, Power or Efficiency.
+
+## Future considerations
+
+* Eventually, we may want to implement a feature like "only close on graceful exit if the shell was running for more than X seconds". This puts us in a better position to do that, as we can detect graceful and clumsy exits more readily.
+    * (potential suggestion: `{ "closeOnExit": "10s" }`
+* The enumerator values for transitioning connection states will be useful for connections that require internet access.
+* Since the connection states are exposed through `TerminalControl`, they should be able to be data-bound to other Xaml elements. This can be used to provide discrete UI states for terminal controls, panes or tabs _hosting_ terminal controls.
+    * Example: a tab hosting a terminal control whose connection has been broken MAY display a red border.
+    * Example: an inactive tab that reaches the `Connected` state MAY flash to indicate that it is ready.

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

@@ -1,6 +1,8 @@
 ---
 author: "Mike Griese @zadjii-msft"
-created on: 2019-May-16
+created on: 2019-05-16
+last updated: 2019-07-07
+issue id: 523
 ---
 
 # Panes in the Windows Terminal
@@ -24,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
@@ -113,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
@@ -228,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/#605 - Search/spec.md

@@ -0,0 +1,126 @@
+---
+author: Kaiyu Wang KaiyuWang16
+created on: 2019-12-10
+last updated: 2019-12-10
+issue id: #605
+---
+
+# Search in Terminal
+
+## Abstract
+
+This spec is for feature request #605 "Search". It goes over the details of a new feature that allows users to search text in Terminal, within one tab or from all tabs. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed. 
+
+## Inspiration
+
+One of the superior features of iTerm2 is it's content search. The search comes in two variants: search from active tab and search from all tabs. In almost any editor, there is an roughly equivalent string search. We also want to realize search experience in Terminal. There will be two variants, search within one tab or from multiple tabs. We will start with one-tab search implementation. 
+
+## Solution Design
+
+Our ultimate goal is to provide both search within one tab and search from all tabs experiences. But we can start with one-tab search. The search experience should have following features:
+
+1. The search is triggered by KeyBindings. A new setting property named "find" will be enabled in the Json file. The user can set their own key bindings for search. The default is <kbd>ctrl+shift+f</kbd>. 
+2. The user search in a XAML TextBox, which is contained in a custom `SearchBoxControl`. The default position of the search box is the top right corner.
+3. We can have multiple search methods. The simplest one is exact text match. Other match methods include case-sensitive exact match and regex match. In the first phase, we will focus on case sensitive/insensitive text exact match. 
+4. If currently there is no active selection, the search starts from the last line of the mutableViewport. If there is an active selection, we start from the previous or the next text of the selected text. We automatically go around if we reach the start point of the search.
+5. The user should be able to fully interact with the terminal when the search box is on screen. 
+6. For accessibility concerns, the user should be able to navigate all the interactive elements on the search box using keyboard tab if the search box is focused. Searchbox could be created and closed with keyboard bindings. Close is usually bound to Esc.
+
+Conhost already has a module for search. It implements case sensitive or insensitive exact text match search, and it provides methods to select the found word. However, we want to make search as a shared component between Terminal and Console host. Now search module is part of Conhost, and its dependencies include BufferOut and some other types in ConHost such as SCREEN_INFORMATION. In order to make Search a shared component, we need to remove its dependency on ConHost types. BufferOut is already a shared component, but we need to make sure there is no other Conhost dependency.
+
+We will create a `SearchBoxControl` Xaml `UserControl` element. When a search process begins, a `SearchBoxControl` object will be created and attached to `TermControl` root grid. In other words, one SearchBox is added for each `TermControl`. The reasons for this design is:
+
+1. Each `TermControl` object is a Terminal Window and has a individual text buffer. In phase 1 we are going to search witin the current terminal text buffer. 
+2. If we put the search box under TerminalApp, then the search can only happen on the current focused Terminal. 
+3. If the community does not like the current design, we can lift SearchBox to a higher level. 
+
+### Search process implementation
+1. Once the user press <kbd>ctrl+shift+f</kbd> (or user's custom key binding), a new `SearchBoxControl` object will be created and attached as a child of `TermControl`. Focus will move to the TextBox within the `SearchBoxControl`. 
+2. Search is performed on a XAML TextBox. Once the user presses Enter or click up/down arrow button, we start to search from the last line of the current viewport or the current selection, and try to find the exact text in the text buffer. The nearest searched one will be selected. Then the search start point will be set to the selected text. The next search will start before or after the previous searched text.
+3. We re-use the Search module in conhost. It performs the search in a brute-force approach. Starting from every position in the text buffer, the search algorithm compares the span of the searched string with buffer characters, and if the current buffer text matches the whole string, it will return store the position of the text in the buffer and return. The stored position information will be used for selection. 
+3. The user can choose to search up or down. Search module realizes this, we just need to set a boolean flag. Default is search up. 
+4. The user can choose to do case sensitive or insensitive match. This also realized by Search module by setting a boolean flag. Default is search case-insensitively. 
+5. Tab navigation is realized by XAML. We just need to set TabNavigation="Cycle" in `SearchBoxControl`. 
+6. If the user clicks on the "X" button or press <kbd>Esc</kbd>, the search box will disappear and the object will be destructed and detached from the `TermControl` XAML tree. In phase one we do not store any state. 
+7. We need to guarantee full interaction with the terminal when the search box is open. To achieve this, search box and terminal input should be separated. If the current keyboard focus is on the search box, then keydown events will be handled on "search box level". 
+
+## UI/UX Design
+
+![SearchBox mockup](images/SearchBoxControl.png)
+
+Above is the `SearchBoxControl` in dark theme and light theme.
+  - The two buttons with up/down arrows controls the search direction, Each button will be styled to indicate which search direction is currently selected. 
+  - The button with a "Aa" icon, if pressed, means that we are searching case-sensitivily. 
+  - The current style puts all elements - the `X` button, the text box and the search pattern control buttons on one single line. This ensures that the `SearchBoxControl` won't be too high and block terminal text. This is similar with VSCode. Another possible layout style is to put elements in multiple layers. This will occupy more lines, but the search dialog will narrower. Considering that there is not many elements, we do not need multiple layers. 
+
+![SearchBox mockup, arrow button clicked](images/SearchBoxUpSelected.png)
+
+The search box defaults to be on the top right corner of the Terminal window. If the current tab is split into panes, each pane will have a individual searchbox. 
+
+#### Search process
+1. The user presses <kbd>ctrl+shift+f</kbd> (or user's custom key binding) to open the search box. Focus will move to the TextBox. 
+2. Search is performed on a XAML TextBox. Once the user presses Enter or click up/down arrow button, the search starts and searched text will be selected. Next search will be performed beginning from the current selection and go towards up/down. 
+3. The user can choose to search up or down by selecting up arrow or down arrow buttons. The chosen button will be styled to indicate it is selected. If the user does not click the arrows buttons, the default direction is up. 
+4. The user can choose to do case sensitive or insensitive match by checking a check box. The default is case insensitive. 
+5. If the search box is focused, the user can navigate all the elements on the search box using tab. When selected, press Enter equals to click. 
+6. If the user click the "X" button or press <kbd>Esc</kbd>, the search stopped and the search box disappears and focus will move back to Terminal.
+7. Once the search box is closed (exiting search mode), the selection will still be there. This coincides with the current VS Code and cmd experience. To get rid of the selection, the user can just click other area of the window.
+8. If the user clicks on the terminal when the search box is open, it will draw focus back to the terminal from the search box. The search box will still stay open. 
+9. The user can interact with the terminal when the search box is open, which means that the user can scroll the terminal content, or input text when the focus is on the terminal control. 
+10. If the user switches tabs while the search box is open, the focus will be moved back to the terminal. 
+
+## Capabilities
+
+1. The user can search exact matched text in the text buffer of the Terminal Screen. 
+2. The user can choose to search case sensitively and insensitively. 
+3. The user can search up or down. 
+4. Found text will be selected. 
+5. The search will start from the active selected text (inclusive) if there is one, or the end of the written text. 
+6. The search will automatically go around when it reaches the starting point.
+7. The user can use Tab to navigate all the elements in the search box. 
+8. The user can search in the opposite direction with <kbd>Shift + Enter</kbd> 
+
+### Accessibility
+
+The user should be able to use search by keyboard only.
+Once the searchbox is focused, the user can navigate between elements in the search box using Tab. And "click" using Enter. 
+
+### Security
+
+This feature should not introduce any new security issues.
+
+### Reliability
+
+1. The key input of Terminal command line and the search box should be separated. Search box should not block interaction with the command line when it is open. 
+2. The search box should not block too much text. The search box only occupies one line, so it won't have big impact on the readibility of the terminal output. 
+
+### Compatibility
+
+This feature won't break existing features of Terminal.
+
+### Performance, Power, and Efficiency
+
+This feature only launches in need. It does not impact the performance of Terminal. 
+
+## Potential Issues
+                                                              
+1. If the terminal window is not wide enough for the search box to be visible, the buttons on the right of the `TextBox` will become invisible, but the `TextBox` is still visible and the window could not be narrower than the `TextBox`. This is similar to the behavior of other editors. Please see the image below:
+   ![SearchBox width not enough](images/SearchBoxControlNoEnoughWidth.png)
+2. If the terminal window is not high enough for the search box to be visible, the whole terminal screen, inlcuding the `SearchBoxControl` can disappear. This is similar to the behavior of other editors.
+
+## Future considerations
+
+In version 1, we want realize a case sensitive/insensitive exact text match. But we may consider the following features in version 2:
+
+1. Add "Find" button in dropdown menu to trigger search. This enables the search feature to be operated with mouse only. However, this is not required by Accessibility so we do not cover this in phase one. 
+2. Search from all tabs. For Version 1 we just want to realize search within one tab. However, the community also requests search from all tabs. This may require a big change to the search algorithm, but it is not seen as a popular use scenario, so we put it future phase. To implement multi-tab search, we can let TerminalPage or App own a `SearchBoxControl` object, and provide the text buffer of the current focused terminal. We need to change the search algorithm.  
+3. Regular expression match. This is a useful search pattern and is implemented in some editors. However, this use scenario is not used as much as exact text search, thus, we put it in future phase.
+4. Search history. Sometimes users would do the same search for several times, thus, storing the search history is useful. This is not realized by VSCode so it would be a good highlighting point in the future. 
+5. High-light while you type. Emphasizing all the other matches in the buffer with an outline or selection with another color. This provides a clearer view of searched text. But we need to change the search and selection algorithm, so we put it in the future phase. 
+6. Add size handle. Some text editors let the user resize the search box, and there is a size handle on the left side of the search box. This helps user when they search for long text. If the community desires it we may add a similar feature.
+
+This open issue tracks the phase features of Search: https://github.com/microsoft/terminal/issues/3920
+
+## Resources
+
+Github Issue: https://github.com/microsoft/terminal/issues/605

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

@@ -0,0 +1,717 @@
+---
+author: Mike Griese @zadjii-msft
+created on: 2019-05-31
+last updated: 2019-07-31
+issue id: 754
+---
+
+# Cascading Default + User Settings
+
+## Abstract
+
+This spec outlines adding support for a cascading settings model. In this model,
+there are two settings files, instead of one.
+
+1. The default settings file
+2. The user's settings file
+
+The default settings file would be a static, read-only file shipped with the
+terminal. The user settings file would then contain all the user's chosen
+customizations to the settings. These two files would then be composed together
+when the app is launched, so that the runtime settings are the union of both the
+defaults and whatever modifications the user has chosen. This will enable the
+app to always use a default schema that it knows will be valid, and minimize the
+settings that the user needs to customize.
+
+Should the settings schema ever change, the defaults file will change, without
+needing to re-write the user's settings file.
+
+It also outlines a mechanism by which profiles could be dynamically added or
+hidden from the profiles list, based on some external source.
+
+## Inspiration
+
+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 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.
+
+One of our overarching goals with this change should be to re-serialize the user
+settings file as little as possible.
+
+### Goal: Minimize Content in `profiles.json`
+
+We want the user to only have to make the minimal number of changes possible to
+the user settings file. Additionally, the user should only have to have the
+settings that they've changed in that file. If the user wants to change only the
+`cursorColor` of a profile, they should only need to set that property in the
+user settings file, and not need an entire copy of the `Profile` object in their
+user settings file. That would create additional noise that's not relevant to
+the user.
+
+### Goal: Remove the Need to Reset Settings Entirely to get New Settings
+One problem with the current settings design is that we only generate "default"
+settings for the user when there's no settings file present at all. So, when we
+want to do things like update the default profiles to have an icon, or add
+support for generating WSL profiles, it will only apply to users for fresh
+installs. Otherwise, a user needs to completely delete the settings file to have
+the terminal re-generate the default settings.
+
+This is fairly annoying to the end-user, so ideally we'll find a way to be able
+to prevent this scenario.
+
+### Goal: Prevent Roaming Settings from Failing
+Another problem currently is that when settings roam to another machine, it's
+possible that the second machine doesn't have the same applications installed as
+the first, and some profiles might be totally invalid on the second machine.
+Take for example, profiles for WSL distros. If you have and Ubuntu profile on
+your first machine, and roam that profile to a second machine without Ubuntu
+installed, then the Ubuntu profile would be totally broken on the second
+machine.
+
+While we won't be able to non-destructively prevent all failures of this case,
+we should be able to catch it in certain scenarios.
+
+## Solution Design
+
+The settings are now composed from two files: a "Default" settings file, and a
+"User" settings file.
+
+When we load the settings, we'll perform the following steps, each mentioned in
+greater detail below:
+1. Load from disk the `defaults.json` (the default settings) -> DefaultsJson
+1. Load from disk the `profiles.json` (the user settings) -> UserJson
+1. Parse DefaultsJson to create all the default profiles, schemes, keybindings.
+1. [Not covered in this spec] Check the UserJson to find the list of dynamic
+   profile sources that should run.
+1. Run all the _enabled_ dynamic profile generators. Those profiles will be
+   added to the set of profiles.
+   - During this step, check if any of the profiles added here don't exist in
+     UserJson. If they _don't_, the generator created a profile that didn't
+     exist before. Return a value indicating the user settings should be
+     re-saved (with the new profiles added).
+1. [Not covered in this spec] Layer the UserJson.globals.defaults settings to
+   every profile in the set, both the defaults, and generated profiles.
+1. Apply the user settings from UserJson. Layer the profiles on top of the
+   existing profiles if possible (if both `guid` and `source` match). If a
+   profile from the user settings does not already exist, make sure to apply the
+   UserJson.globals.defaults settings first. Also layer Color schemes and
+   keybindings.
+   - If a profile has a `source` key, but there is not an existing profile with
+     a matching `guid` and `source`, don't create a new Profile object for it.
+     Either that generator didn't run, or the generator wanted to delete that
+     profile, so we'll effectively hide the profile.
+1. Re-order the list of profiles, to match the ordering in the UserJson. If a
+   profile doesn't exist in UserJson, it should follow all the profiles in the
+   UserJson. If a profile listed in UserJson doesn't exist, we can skip it
+   safely in this step (the profile will be a dynamic profile that didn't get
+   populated.)
+1. Validate the settings.
+1. If requested in step 5, write the modified settings back to `profiles.json`.
+
+### Default Settings
+
+We'll have a static version of the "Default" file **hardcoded within the
+application package**. This `defaults.json` file will live within the
+application's package, which will prevent users from being able to edit it.
+
+```json
+// This is an auto-generated file. Place any modifications to your settings in "profiles.json"
+```
+
+This disclaimer will help identify that the file shouldn't be modified. The file
+won't actually be generated, but because it's shipped with our app, it'll be
+overridden each time the app is updated. "Auto-generated" should be good enough
+to indicate to users that it should not be modified.
+
+Because the `defaults.json` file is hardcoded within our application, we can use
+its text directly, without loading the file from disk. This should help save
+some startup time, as we'll only need to load the user settings from disk.
+
+When we make changes to the default settings, or we make changes to the settings
+schema, we should make sure that we update the hardcoded `defaults.json` with
+the new values. That way, the `defaults.json` file will always have the complete
+set of settings in it.
+
+### Layering settings
+
+When we load the settings, we'll do it in three stages. First, we'll deserialize
+the default settings that we've hardcoded. We'll then generate any profiles that
+might come from dynamic profile sources. Then, we'll intelligently layer the
+user's setting upon those we've already loaded. If a user wants to make changes
+to some objects, like the default profiles, we'll need to make sure to load from
+the user settings into the existing objects we created from the default
+settings.
+
+* We'll need to make sure that any profile in the user settings that has a GUID
+  matching a default profile loads the user settings into the object created
+  from the defaults.
+* We'll need to make sure that there's only one action bound to each key chord
+  for a keybinding. If there are any key chords in the user settings that match
+  a default key chord, we should bind them to the action from the user settings
+  instead.
+* For any color schemes whose name matches the name of a default color scheme,
+  we'll need to apply the user settings to the existing color scheme. For
+  example, a user could override the `red` entry of the "Campbell" scheme to be
+  `#ff9900` if they want. This would then apply to all profiles using the
+  "Campbell" scheme.
+* For profiles that were created from a dynamic profile source, they'll have
+  both a `guid` and `source` guid that must _both_ match. If a user profile with
+  a `source` set does not find a matching profile at load time, the profile will
+  be ignored. See more details in the [Dynamic Profiles](#dynamic-profiles)
+  section.
+
+### Hiding Default Profiles
+
+What if a user doesn't want to see one of the profiles that we've included in
+the default profiles?
+
+We will add a `hidden` key to each profile, which defaults to false. When we
+want to mark a profile as hidden, we'd just set that value to `true`, instead of
+trying to look up the profile's guid.
+
+So, if someone wanted to hide the default cmd.exe profile, all they'd have to do
+is add `"hidden": true` to the cmd.exe entry in their user settings, like so:
+
+```js
+{
+    "profiles": [
+        {
+            // Make changes here to the cmd.exe profile
+            "guid": "{6239a42c-1de4-49a3-80bd-e8fdd045185c}",
+            "hidden": true
+        }
+    ],
+```
+
+#### Hidden Profiles and the Open New Tab shortcuts
+
+Currently, there are keyboard shortcuts for "Open New Tab With Profile
+<N>". These shortcuts will open up the Nth profile in the new tab
+dropdown. Considering we're adding the ability to remove profiles from that
+list, but keep them in the overall list of profiles, we'll need to make sure
+that the handler for that event still opens the Nth _visible_ profile.
+
+### Serializing User Settings
+
+How can we tell that a setting should be written back to the user settings file?
+
+If the value of the setting isn't the same as the defaults, then it could easily
+be added to the user's `profiles.json`. We'll have to do a smart serialization
+of the various settings models. We'll pass in the default version **of that
+model** during the serialization. If that object finds that a particular setting
+is the same as a default setting, then we'll skip serializing it.
+
+What happens if a user has chosen to set the value to _coincidentally_ the same
+value as the default value? We should keep that key in the user's settings file,
+even though it is the same.
+
+In order to facilitate this, we'll need to keep the originally parsed user
+settings around in memory. When we go to serialize the settings, we'll check if
+either the setting exists already in the user settings file, or the setting has
+changed. If either is true, then we'll make sure to write that setting back out.
+
+For serializing settings for the default profiles, we'll check if the setting is
+in the user settings file, or if the value of the setting is different from the
+version of that `Profile` from the default settings. For user-created profiles,
+we'll compare the value of the setting with the value of the _default
+constructed_ `Profile` object. This will help ensure that each profile in the
+user's settings file maintains the minimal amount of info necessary.
+
+When we're adding profiles due to their generation in a dynamic profile
+generator, we'll need to serialize them, then insert them back into the
+originally parsed json object to be serialized. We don't want the automatic
+creation of a new profile to automatically trigger re-writing the entire user
+settings file, but we do want newly created dynamic profiles to have an entry
+the user can easily edit.
+
+### Dynamic Profiles
+
+Sometimes, we may want to auto-generate a profile on the user's behalf. Consider
+the case of WSL distros on their machine, or VMs running in Azure they may want
+to auto-connect to. These _dynamic_ profiles have a source that might be added
+or removed after the app is installed, and they will be different from user to
+user.
+
+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. Furthermore, if any of the sources of
+these dynamic profiles are removed, then the app won't auto-remove the
+associated profile.
+
+In the new model, with a combined defaults & user settings, how should these
+dynamic profiles work?
+
+I propose we add functionality to automatically search for these profile sources
+and add/remove them on _every_ Terminal launch. To make this functionality work
+appropriately, we'll need to introduce a constraint on dynamic profiles.
+
+**For any dynamic profiles, they must be able to be generated using a stable
+GUID**. For example, any time we try adding the "Ubuntu" profile, we must be
+able to generate the same GUID every time. This way, when a dynamic profile
+generator runs, it can check if that profile source already has a profile
+associated with it, and do nothing (as to not create many duplicate "Ubuntu"
+profiles, for example).
+
+Additionally, each dynamic profile generator **must have a unique source guid**
+to associate with the profile. When a dynamic profile is generated, the source's
+guid will be added to the profile, to make sure the profile is correlated with
+the source it came from.
+
+We'll generate these dynamic profiles immediately after parsing the default
+profiles and settings. When a generator runs, it'll be able to create unique
+profile GUIDs for each source it wants to generate a profile for. It'll hand
+back a list of Profile objects, with settings set up how the generator likes,
+with GUIDs set.
+
+After a dynamic profile generator runs, we will determine what new profiles need
+to be added to the user settings, so we can append those to the list of
+profiles. The deserializer will look at the list of generated profiles and check
+if each and every one already has a entry in the user settings. The generator
+will just blind hand back a list of profiles, and the deserializer will figure
+out if any of them need to be added to the user settings. We'll store some sort
+of result indicating that we want a save operation to occur. After the rest of
+the deserializing is done, the app will then save the `profiles.json` file,
+including these new profiles.
+
+When we're serializing the settings, instead of comparing a dynamic profile to
+the default-constructed `Profile`, we'll compare it to the state of the
+`Profile` after the dynamic profile generator created it. It'd then only
+serialize settings that are different from the auto-generated version. It will
+also always make sure that the `guid` of the dynamic profile is included in the
+user settings file, as a point for the user to add customizations to the dynamic
+profile to. Additionally, we'll also make sure the `source` is always serialized
+as well, to keep the profile correlated with the generator that created it.
+
+We'll need to keep the state of these dynamically generated profiles around in
+memory during runtime to be able to ensure the only state we're serializing is
+that which is different from the initially generated dynamic profile.
+
+When the generator is run, and determines that a new profile has been added,
+we'll need to make sure to add the profile to the user's settings file. This
+will create an easy point for users to customize the dynamic profiles. When
+added to the user settings, all that will be added is the `name`, `guid`, and
+`source`.
+
+Additionally, a user might not want a dynamic profile generator to always run.
+They might want to keep their Azure connections visible in the list of profiles,
+even if its no longer a valid target. Or they might want to not automatically
+connect to Azure to find new instances every time they launch the terminal. To
+enable scenarios like this, we'll add an additional setting,
+`disabledProfileSources`. This is an array of guids. If any guids are in that
+list, then those dynamic profile generators _won't_ be run, suppressing those
+profiles from appearing in the profiles list.
+
+If a dynamic profile generator needs to "delete" a profile, this will also work
+naturally with the above rules. Lets examine the case where the user has
+uninstalled the Ubuntu distro. When the WSL generator runs, it won't create the
+Ubuntu profile. When we get to the Ubuntu profile in the user's settings, it'll
+have a `source`, but we won't already have a profile with that `guid` and
+`source`. So we'll just ignore it, because whatever source for that profile
+doesn't want it anymore. Effectively, this will act like it was "deleted",
+though the artifacts still remain untouched in the user's json.
+
+#### What if a dynamic profile is removed, but it's the default?
+
+I'll direct our attention to [#1348] - Display a specific error for not finding
+the default profile. When we're done loading, and we determine that the default
+profile doesn't exist in the finalized list of profiles, we'll display a dialog
+to the user. This includes both hidden profiles and dynamic profiles that have
+been "deleted". We'll temporarily use the _first_ profile instead.
+
+#### Dynamic profile GUID generation
+
+In order to help facilitate the generation of stable, unique GUIDs for
+dynamically generated profiles, we'll enforce a few methods on each generator.
+The Generator should implement a method that returns its _unique_ namespace for
+profiles it generates:
+
+```c++
+class IDynamicProfileGenerator
+{
+    ...
+    virtual std::wstring GetNamespace() = 0;
+    ...
+}
+```
+
+For example, the WSL generator would return `Microsoft.Terminal.WSL`. The
+Powershell Core generator would return `Microsoft.Terminal.PowershellCore`.
+We'll use these names to be able to generate uuidv5 GUIDs that will be unique
+(so long as the names are unique).
+
+The generator should also be able to ask the app for two other pieces of
+functionality:
+* The generator should be able to ask the app for the generator's own namespace
+  GUID
+* The generator should be able to ask the app for a uuidv5 in the generator's
+  namespace, given a specific name key.
+
+These two functions will be exposed to the generator like so:
+
+```c++
+GUID GetNamespaceGuid(IDynamicProfileGenerator& generator);
+GUID GetGuidForName(IDynamicProfileGenerator& generator, std::wstring& name);
+```
+
+The generator does not _need_ to use `GetGuidForName` to generate guids for it's
+profiles. If the generator can determine another way to generate stable GUIDs
+for its profiles, it's free to use whatever method it wants. `GetGuidForName` is
+provided as a convenience.
+
+It's not the responsibility of the dynamic profile generator to fill in the
+`source` of the profiles it generates. The deserializer will make sure to go
+through and fill in the guid for the generated profiles given the generator's
+namespace GUID.
+
+### Powershell Core & the Defaults
+
+How do we handle the potential existence of Powershell Core in this model?
+Powershell core is unique as far as the default profiles goes - it may or may
+not exist on the user's system. Not only that, but depending on the user's
+install of Powershell Core, it might have a path in either `Program Files` or
+`Program Files(x86)`.
+
+Additionally, if it _is_ installed, we set it as the default profile instead of
+Windows Powershell.
+
+Powershell core acts much like a dynamic profile. It has an installation source
+that may or not be there. So we'll add a dynamic profile generator for
+Powershell Core. This will automatically create a profile for Powershell Core if
+necessary.
+
+Unlike the other dynamic profiles, if Powershell Core is present on
+_first_ launch of the terminal, we set that as the default profile. This can
+still be done - we'll need to do some special-case work when we're loading the
+user settings and we _don't_ find any existing settings. When that happens,
+we'll generate all the default user settings. Before we commit them, we'll check
+if the Powershell Core profile exists, and if it does, we'll set that as the
+default profile before writing the settings to disk.
+
+### Unbinding a Keybinding
+
+How can a user unbind a key that's part of the default keybindings? What if a
+user really wants <kbd>ctrl</kbd>+<kbd>t</kbd> to fall through to the
+commandline application attached to the shell, instead of opening a new tab?
+
+We'll need to introduce a new keybinding command that should indicate that the
+key is unbound. We'll load the user keybindings and layer them on the defaults
+as described above. If during the deserializing we find an entry that's bound to
+the command `"unbound"` or any other string that we don't understand, instead of
+trying to _set_ the keybinding, we'll _clear_ the keybinding with a new method
+`AppKeyBindings::ClearKeyBinding(chord)`.
+
+### Removing the Globals Object
+
+As a part of #[1005](https://github.com/microsoft/terminal/pull/1005), all the
+global settings were moved to their own object within the serialized settings.
+This was to try and make the file easier to parse as a user, considering global
+settings would be intermingled with profiles, keybindings, color schemes, etc.
+Since this change will make the user settings dramatically easier to navigate,
+we should probably remove the `globals` object, and have globals at the root
+level again.
+
+### Default `profiles.json`
+
+Below is an example of what the default user settings file might look like when
+it's first generated, taking all the above points into consideration.
+
+```js
+// To view the default settings, open <path-to-app-package>\defaults.json
+{
+    "defaultProfile" : "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
+    "profiles": [
+        {
+            // Make changes here to the cmd.exe profile
+            "guid": "{6239a42c-1de4-49a3-80bd-e8fdd045185c}"
+        },
+        {
+            // Make changes here to the Windows Powershell profile
+            "guid": "{086a83cd-e4ef-418b-89b1-3f6523ff9195}",
+        },
+        {
+            "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
+            "name" : "Powershell Core",
+            "source": "{2bde4a90-d05f-401c-9492-e40884ead1d8}",
+        }
+    ],
+
+    // Add custom color schemes to this array
+    "schemes": [],
+
+    // Add any keybinding overrides to this array.
+    // To unbind a default keybinding, set the command to "unbound"
+    "keybindings": []
+}
+
+```
+
+Note the following:
+* cmd.exe and powershell.exe are both in the file, as to give users an easy
+  point to extend the settings for those default profiles.
+* Powershell Core is included in the file, and the default profile has been set
+  to its GUID. The `source` has been set, indicating that it came from a dynamic profile source.
+* There are a few helpful comments scattered throughout the file to help point
+  the user in the right direction.
+
+### Re-ordering profiles
+
+Since there are shortcuts to open the Nth profile in the list of profiles, we
+need to expose a way for the user to change the order of the profiles. This was
+not a problem when there was only a single list of profiles, but if the defaults
+are applied _first_ to the list of profiles, then the user wouldn't be able to
+change the order of the default profiles. Additionally, any profiles they add
+would _always_ show up after the defaults.
+
+To remedy this, we could scan the user profiles in the user settings first, and
+create `Profile` objects for each of those profiles first. These `Profile`s
+would only be initialized with their GUID temporarily, but they'd be placed into
+the list of profiles in the order they appear in the user's settings. Then, we'd
+load all the default settings, overlaying any default profiles on the `Profile`
+objects that might already exist in the list of profiles. If there are any
+default profiles that don't appear in the user's settings, they'll appear
+_after_ any profiles in the user's settings. Then, we'll overlay the full user
+settings on top of the defaults.
+
+## UI/UX Design
+
+### Opening `defaults.json`
+How do we open both these files to show to the user (for the interim period
+before a proper Settings UI is created)? Currently, the "Settings" button only
+opens a single json file, `profiles.json`. We could keep that button doing the
+same thing, though we want the user to be able to also view the default settings
+file, to be able to inspect what settings they wish to change.
+
+We could have the "Settings" button open _both_ files at the same
+time. I'm not sure that `ShellExecute` (which is used to open these files)
+provides any ordering guarantees, so it's possible that the `defaults.json`
+would open in the foreground of the default json editor, while making in unclear
+that there's another file they should be opening instead. Additionally, if
+there's _no_ `.json` editor for the user, I believe the shell will attempt
+_twice_ to ask the user to select a program to open the file with, and it might
+not be clear that they need to select a program in both dialogs.
+
+Alternatively, we could make the defaults file totally inaccessible from the
+Terminal UI, and instead leave a comment in the auto-generated `profiles.json`
+like so:
+
+```json
+// To view the default settings, open the defaults.json file in this directory
+```
+
+The "Settings" button would then only open the file the user needs to edit, and
+provide them instructions on how to open the defaults file.
+
+There could alternatively be a hidden option for the "Open Settings" button,
+where holding <kbd>Alt</kbd> while clicking on the button would open the
+`defaults.json` instead.
+
+We could additionally add a `ShortcutAction` (to be bound to a keybinding) that
+would `openDefaultSettings`, and we could bind that to
+<kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>\`</kbd>, similar to `openSettings` on
+<kbd>ctrl</kbd>+<kbd>\`</kbd>.
+
+### How does this work with the settings UI?
+
+If we only have one version of the settings models (Globals, Profiles,
+ColorShemes, Keybindings) at runtime, and the user changes one of the settings
+with the settings UI, how can we tell that settings changed?
+
+Fortunately, this should be handled cleanly by the algorithm proposed above, in
+the "Serializing User Settings" section. We'll only be serializing settings that
+have changed from the defaults, so only the actual changes they've made will be
+persisted back to the user settings file.
+
+## Capabilities
+### Security
+
+I don't think this will introduce any new security issues that weren't already
+present
+
+### Reliability
+I don't think this will introduce any new reliability concerns that weren't
+already present. We will likely improve our reliability, as dynamic profiles
+that no longer exist will not cause the terminal to crash on startup anymore.
+
+### Performance, Power, and Efficiency
+
+By not writing the defaults to disk, we'll theoretically marginally improve the
+load and save times for the `profiles.json` file, by simply having a smaller
+file to load. However we'll also be doing more work to process the layering of
+defaults and user settings, which will likely slightly increase the load times.
+Overall, I expect the difference to be negligible due to these factors.
+
+One potential concern is long-running dynamic profile generators. Because
+they'll need to run on startup, they could negatively impact startup time. You
+can read more below, in "Dynamic Profile Generators Need to be Enabled".
+
+### Accessibility
+N/A
+
+## Potential Issues
+
+### Profiles with the same `guid` as a dynamic profile but not the same `source`
+
+What happens if the User settings has a profile with a `guid` that matches a
+dynamic or default profile, but the user profile doesn't have a matching source?
+This could happen trivially easily if the user deletes the `source` key from a
+profile that has dynamically generated.
+
+We could:
+1. Treat the profile as an entirely separate profile
+   - There's lots of other code that assumes each profile has only a unique GUID,
+     so we'd have to change the GUID of this profile. This would mean writing out
+     the user settings, which we'd like to avoid.
+   - We'll still end up generating the entry for the dynamic profile in the
+     user's settings, so we'll need to write out the user settings anyways.
+   - This other profile will likely not have a commandline set, so it might not
+     work at all.
+1. Ignore the profile entirely.
+   - When the dynamic profile generator runs, we're not going to find another
+     entry in the user profiles with both a matching `guid` and a matching
+     `source`. So we'll end up creating _another_ entry in the user profiles for
+     the dynamic profile.
+   - How could the user know that the profile is being ignored? There's nothing
+     in the file itself that indicates obviously that this profile is now
+     invalid.
+1. Treat the user settings as part of the dynamic profile
+   - In this scenario, the user profile continues to exist as part of the dynamic profile.
+   - When the dynamic profile generator runs, we're not going to find another
+     entry in the user profiles with both a matching `guid` and a matching
+     `source`. So we'll end up creating _another_ entry in the user profiles for
+     the dynamic profile.
+     - These two entries will each be layered upon the dynamically generated
+       profile, so the settings in the second profile entry will override
+       settings from the first.
+   - If the user disables the generator, or the profile source is removed, the
+     dynamic profile will cease to exist. However, the profile without the
+     `source` entry will remain, though likely will not work.
+   - How do we order these profiles for the user? When we're parsing the user
+     profiles list to build an ordering of profiles, do we use the first entry as
+     the index for that profile?
+1. (Variant of the above) Treat the profile as part of the dynamic profile, and
+   re-insert the `source` key.
+   - This will re-connect the user profile to the dynamic one.
+   - We'll need to make sure to do this before determining the new dynamic
+     profiles to add to the user settings.
+   - Given all the scenarios are going to cause a user settings write anyways,
+     this isn't terrible.
+   - If the user _really_ wants to split the profile in their user settings from
+     the dynamic one, they're free to always generate a new guid _and_ delete the
+     `source` key.
+
+Given the drawbacks associated with options 1-3, I propose we choose option 4 as
+our solution to this case.
+
+### Migrating Existing Settings
+
+I believe that existing `profiles.json` files will smoothly update to this
+model, without breaking. While in the new model, the `profiles.json` file can be
+much more sparse, users who have existing `profiles.json` files will have full
+settings in their user settings. We'll leave their files largely untouched, as
+we won't touch keys that have the same values as defaults that are currently in
+the `profiles.json` file. Fortunately though, users should be able to remove
+much of the boilerplate from their `profiles.json` files, and trim it down just
+to their modifications.
+
+#### Migrating Powershell Core
+
+Right now, default-generated Powershell Core profiles exist with a stable guid
+we've generated for them. However, when we move Powershell Core to being a
+dynamically generated profile, we'll have to ensure that we don't create a
+duplicated "dynamic" entry for that profile. If we want to convert the existing
+Powershell Core profiles into a dynamic profile, we'll need to make sure to add
+a `source` key to the profile. Everything else in the profile can remain the
+same. Once the `source` is added, we'll know to treat it as a dynamic profile,
+and it'll respond dynamically.
+
+This is actually something that will automatically be covered by the scenario
+mentioned above in "Profiles with the same `guid` as a dynamic profile but not
+the same `source`". When we encounter the existing Powershell Core profiles that
+don't have a `source`, we'll automatically think they're the dynamically
+generated ones, and auto-migrate them.
+
+#### Migrating Existing WSL Profiles
+
+Similar to the above, so long as we ensure the WSL dynamic profile generator
+generates the _same_ GUIDs as it does currently, all the existing WSL profiles
+will automatically be migrated to dynamic profiles.
+
+### Dynamic Profile Generators Need to be Enabled
+With the current proposal, profiles that are generated by a dynamic profile
+generator _need_ that generator to be enabled for the profile to appear in the
+list of profiles. If the generator isn't enabled, then the important parts of
+the profile (name, commandline) will never be set, and the profile's settings
+from the user settings will be ignored at runtime.
+
+For generators where the generation of profiles might be a lengthy process, this
+could negatively impact startup time. Take for example, some hypothetical
+generator that needs to make web requests to generate dynamic profiles. Because
+we need the finalized settings to be able to launch the terminal, we'll be stuck
+loading until that generator is complete.
+
+However, if the user disables that generator entirely, we'll never display that
+profile to the user, even if they've done that setup before.
+
+So the trade-off with this design is that non-existent dynamic profiles will
+never roam to machines where they don't exist and aren't valid, but the
+generators _must_ be enabled to use the dynamic profiles.
+
+## Future considerations
+* It's possible that a very similar layering loading mechanism could be used to
+  layer per-machine settings with roaming settings. Currently, there's only one
+  settings file, and it roams to all your devices. This could be problematic,
+  for example, if one of your machines has a font installed, but another
+  doesn't. A proposed solution to that problem was to have both roaming settings
+  and per-machine settings. The code to layer settings from the defaults and the
+  user settings could be re-used to handle layer the roaming and per-machine
+  settings.
+* What if an extension wants to generate their own dynamic profiles? We've
+  already outlined a contract that profile generators would have to follow to
+  behave correctly. It's possible that we could abstract our implementation into
+  a WinRT interface that extensions could implement, and be triggered just like
+  other dynamic profile generators.
+* **Multiple settings files** - This could enable us to place color schemes into
+  a seperate file (like `colorschemes.json`) and put keybindings into their own
+  file as well, and reduce the number of settings in the user's `profiles.json`.
+  It's unclear if this is something that we need quite yet, but the same
+  layering functionality that enables this scenario could also enable more than
+  two sources for settings.
+* **Global Default Profile Settings** - Say a user wants to override what the
+  defaults for a profile are, so that they can set settings for _all_ their
+  profiles at once? We could maybe introduce a profile in the user settings file
+  with a special guid set to `"default`, that we look for first, and treat
+  specially. We wouldn't include it in the list of profiles. When we're creating
+  profiles, we'll start with that profile as our prototype, instead of using the
+  default-constructed `Profile`. When we're serializing profiles, we'd again use
+  that as the point of comparison to check if a setting's value has changed.
+  There may be more unknowns with this proposal, so I leave it for a future
+  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 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
+  settings to determine the ordering of the profiles. It's possible in the
+  future we may want to give the user more control over this ordering. Maybe
+  we'll want to allow the user to manually index the profiles. Or, as discussed
+  in issues like #1571, we may want to allow the user to further customize the
+  new tab dropdown, beyond just the order of profiles. The re-ordering step
+  would be a great place to add code to support this re-ordering, with whatever
+  algorithm we eventually land on. Determining such an algorithm is outside the
+  scope of this spec, however.
+
+## Resources
+N/A
+
+
+<!-- Footnotes -->
+
+[#1348]: https://github.com/microsoft/terminal/issues/1348

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
 -------------|-------|-----------|-----------

doc/submitting_code.md

@@ -3,7 +3,7 @@
 
 In Openconsole, `dev/main` is the master branch for the repo.
 
-Any branch that begins with `dev/` is recognized by our CI system and will automatically run x86 and amd64 builds and run our unit and feature tests. For feature branchs the pattern we use is `dev/<alias>/<whatever you want here>`. ex. `dev/austdi/SomeCoolUnicodeFeature`. The important parts are the dev prefix and your alias.
+Any branch that begins with `dev/` is recognized by our CI system and will automatically run x86 and amd64 builds and run our unit and feature tests. For feature branches the pattern we use is `dev/<alias>/<whatever you want here>`. ex. `dev/austdi/SomeCoolUnicodeFeature`. The important parts are the dev prefix and your alias.
 
 `inbox` is a special branch that coordinates Openconsole code to the main OS repo.
 
@@ -15,12 +15,12 @@ Because we build outside of the OS repo, we need a way to get code back into it
 
 ## What to do when cherry-picking to inbox fails
 
-Sometimes VSTS doesn't want to allow a cherry pick to the inbox branch. It might have a valid reason or it might just be finicky. You'll need to complete the merge manually on a local machine. The steps are:
+Sometimes VSTS doesn't want to allow a cherry pick to the inbox branch. It might have a valid reason, or it might just be finicky. You'll need to complete the merge manually on a local machine. The steps are:
 
 1. make sure you have pulled the latest commits for the `dev/main` and `inbox` branches
 2. make a new branch from inbox
 3. cherry-pick the commits from the PR to the newly created branch (this is easier if you squashed your commits when you merged into `dev/main`
-4. fix any merge conficts and commit
+4. fix any merge conflicts and commit
 5. push the new branch to the remote
 6. create a new PR of that branch in `inbox`
 7. complete PR and continue on to completing the auto-created PR in the OS repo

doc/terminal-v1-roadmap.md

@@ -0,0 +1,95 @@
+# Terminal v1.0 Roadmap
+
+## Overview
+
+This document outlines our roadmap to delivering Windows Terminal v1.0 by spring 2020.
+
+## Milestones
+
+The Windows Terminal project is engineered and delivered as a set of 4-week milestones:
+
+| Duration | Activity | Releases |
+| --- | --- | --- |
+| 2 weeks | Dev Work<br/> <ul><li>Fixes / Features for future Windows Releases</li><li>Fixes / Features for Windows Terminal</li></ul> |  Release to Internal Selfhosters at end of week 2 |
+| 1 week | Quality & Stability<br/> <ul><li>Bug Fixes</li><li>Perf & Stability</li><li>UI Polish</li><li>Tests</li><li>etc.</li></ul>| Push to Microsoft Store at end of week 3 |
+| 1 week | Release <br/> <ul><li>Available from [Microsoft Store](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701) & [GitHub Releases](https://github.com/microsoft/terminal/releases) (Tues of 4th week)</li><li>Release Notes & Announcement Blog published</li><li>Engineering System Maintenance</li><li>Community Engagement</li><li>Docs</li><li>Future Milestone Planning</li></ul> | Release available from Microsoft Store & GitHub Releases |
+
+## Terminal Roadmap / Timeline
+
+Ultimately, we're aiming for Terminal v1.0 to be feature-complete by Dec 2019, and to declare v1.0 by April 2020:
+
+> ⚠ Note: Terminal v1.0 will be a quality-oriented release driven in large part by the community. So, ___if you see bugs, find/file them___!
+
+| Milestone end date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Milestone Name | Key Deliverables |
+| --- | --- | --- |
+| 2019-05-07 | [Announcement](https://devblogs.microsoft.com/commandline/introducing-windows-terminal/) | Terminal announced & open-sourced ([Build 2019 Terminal session](https://www.youtube.com/watch?v=KMudkRcwjCw), ["Sizzle" video](https://www.youtube.com/watch?v=8gw0rXPMMPE&list=PLEHMQNlPj-Jzh9DkNpqipDGCZZuOwrQwR&index=2&t=0s)) |
+| 2019-07-09 | [v0.2 (update)](https://github.com/microsoft/terminal/releases/tag/v0.2.1831.0) | First version of the Terminal released via the Microsoft Store, fundamental features in place, basic tab control, basic UI layout, config & settings via JSON file |
+| 2019-08-02 | [v0.3](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) | Major UI improvements, improved tab bar layout & color, basic a11y support, Azure Cloud Shell connection |
+| 2019-08-27 | [v0.4](https://github.com/microsoft/terminal/releases/tag/v0.4.2382.0) | HTML Copy, Tab Titles, Double/Triple Click Selection, Local Settings, JSON settings validation, A11y improvements |
+| 2019-09-24 | [1909]( http://devblogs.microsoft.com/commandline/windows-terminal-preview-1909) | Stability & Quality improvements, installs [Cascadia Code](https://github.com/microsoft/cascadia-code) font, adds JSON schema to `profiles.json` settings file enabling Intellisense in VSCode, etc. |
+| 2019-10-22 | [1910](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1910-release/) | Cascading Settings, Dynamic Profiles |
+| 2019-11-19 | 1911 | Final v1.0 feature work |
+| 2019-12-17 | 1912 | "Feature Complete" - All v1.0 Features in-place |
+| Winter Vacation | N/A | None planned |
+| 2020-01-28 | Beta 1 | Pri 0/1/2 Bug fixes & polish |
+| 2020-02-25 | Beta 2 | Pri 0/1 Bug fixes & polish |
+| 2020-03-24 | RC | Pri 0 bug fixes |
+| 2020-04-01 ? | v1.0 | Terminal v1.0 Release |
+
+## GitHub Milestones
+
+Each milestone above is/will be reflected in our [GitHub milestones](https://github.com/microsoft/terminal/milestones):
+
+| Milestone | Description |
+| --- | --- |
+| [Terminal-1909](https://github.com/microsoft/terminal/milestone/12) | Work planned for 1909 |
+| [Terminal-1910](https://github.com/microsoft/terminal/milestone/15) | Work planned for 1910 |
+| [Terminal-1911](https://github.com/microsoft/terminal/milestone/16) | Work planned for 1911 |
+| [Terminal-1912](https://github.com/microsoft/terminal/milestone/17) | Work planned for 1912 |
+| &lt;Future Milestones&gt; | &lt;Coming soon&gt; |
+| [Terminal v1.0](https://github.com/microsoft/terminal/milestone/6) | Work planned for v1.0, but not yet assigned to a milestone |
+| [Terminal Backlog](https://github.com/microsoft/terminal/milestone/7) | Work not yet assigned to a milestone or release |
+
+## Issue Triage & Prioritization
+
+Incoming issues/asks/etc. are triaged several times a week, labelled appropriately, and assigned to a milestone in priority order:
+
+* P0 (serious crashes, data loss, etc.) issues are scheduled to be dealt with ASAP
+* P1/2 issues/features/asks  assigned to the current or future milestone, or to the [Terminal v1.0 milestone](https://github.com/microsoft/terminal/milestone/6) for future assignment, if required to deliver a v1.0 feature
+* Issues/features/asks not on our list of v1.0 features is assigned to the [Terminal Backlog](https://github.com/microsoft/terminal/milestone/7) for subsequent triage, prioritization & scheduling.
+
+## v1.0 Scenarios
+
+The following are a list of the key scenarios we're aiming to deliver for Terminal v1.0.
+
+> 👉 Note: There are many other features that don't fit within v1.0, but will be re-assessed and prioritized for v2.0, the plan for which will be published in early in 2020.
+
+| Release | Priority\* | Scenario | Description/Notes |
+| --- | --- | --- | --- |
+| V1 | 0 | Performance & Efficiency | Terminal shall be fast and efficient. Input latency should be eliminated wherever possible. Terminal will be very memory-efficient, and will avoid utilizing unnecessary dependencies to minimize memory consumption and disk footprint |
+| V1 | 0 | Reliability | Every reasonable step should be taken to ensure that Terminal will not crash unexpectedly. Crashing is considered harmful to the user's well-being & state of mind. Crashing issues are prioritized Pri-0 by default |
+| V1 | 0 | Code Reuse | Terminal's core engine will reuse & share componentry from within Windows Console wherever feasible to minimize support & maintenance costs for both|
+| V1 | 0 | Terminal Reuse | Terminal's core will be hostable as a UWP (and perhaps WPF) Control so that apps can host/embed a high quality Terminal. This will satisfy a long-standing ask from many customers and partners for a hostable/embeddable Terminal Control. |
+| V1 | 0 | Rich, modern text renderer | Terminal must be able to render glyphs from East Asian and Middle Asian languages, inc. Chinese, Hebrew, Arabic, etc. Terminal will also be able to render Emoji - an increasingly important feature considering that several programming languages now support Emoji in method and variable names! To render such glyphs, the Terminal needs a DirectWrite-based layout & rendering system which supports font fallback, customizable text layout, GPU accelerated rendering, and many other features not currently supported by the built-in Windows Console |
+| V1 | 0 | Solid Unicode & UTF-8 support | Terminal must be able to store data encoded as Unicode UTF-16/UCS-2 and UTF-8, including surrogate pairs. Note: Terminal v1.0 won't be able to support composing characters or grapheme clusters that are not representable with a single unicode codepoint - this will be addressed in a subsequent release |
+| V1 | 0 | International text rendering | The Terminal will support rendering text for almost every language for which there is a fixed-width font including East Asian languages. Bonus points for RTL languages/scripts. |
+| V1 | 0 | Multiple instances | Users must be able to launch multiple independent instances of the Terminal in order to run tools side-by-side / independently |
+| V1 | 0 | Elevation | Terminal can be launched "elevated" with Admin rights if required so that the user can perform operations that affect machine-wide state |
+| V1 | 0 | Multiple Tabs per instance | Each Terminal instance must support one or more independent tabs. This is the #1 ask from the community! |
+| V1 | 0 | Configurability & Customization | The new Terminal will have a modern, flexible settings mechanism that persists settings to/from a JSON file stored in the user's app data folders, and/or in files synchronized between machines via OneDrive, etc. There will be no settings UI in Terminal v1 - this is a feature for a future Terminal release. |
+| V1 | 0 | Accessibility (A11y) | The Terminal will be highly accessible and inclusive. It will expose its contents via [UIA](https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-overview) to support tools such as [Windows Narrator](https://support.microsoft.com/en-us/help/22798/windows-10-complete-guide-to-narrator), and UI automation tools including [WinAppDriver](https://github.com/Microsoft/WinAppDriver) |
+| V1 | 1 | Color Theming & Styling | The Terminal will honor the user's Windows dark/light theme settings, and/or color accent settings. Also, the Terminal background & text colors will be highly configurable, and importable/exportable via settings files.|
+| V1 | 1 | Background transparency | Background transparency is a valuable feature for many command-line users. Terminal will (optionally) support transparent backgrounds, but without making the Terminal's text content itself transparent (like the Windows Console currently does due to GDI limitations)|
+| V1 | 1 | Fluent "Acrylic" blurred backgrounds | While full transparency is valuable to some, clear/full-transparency can be distracting. Some would like blurred transparency similar to Fluent Acrylic |
+| V1 | 1 | Customizable Key Bindings | Terminal will provide a way for users to customize key bindings, enabling them to configure specific key chords to particular Terminal actions |
+| V1 | 1 | Mouse Support | Terminal will support mouse input, passing mouse movements and actions to command-line apps |
+| V1 | 2 | Azure Cloud Shell | Enable users to register their Azure account/subscription, and allow the Terminal to enumerate and automatically configure a connection to the user's Cloud Shell |
+| V1 | 2 | Multiple panes | Multiple tabs are useful to some, but developers often need to see several files/logs on the same screen at the same time. Windows Terminal should allow a "page" to be split into "panes", each running independent commands/shells/etc. similar to [tmux](https://www.ocf.berkeley.edu/~ckuehl/tmux/) on *NIX/macOS |
+
+Feature Notes:
+
+\* Feature Priorities:
+
+0. Mandatory <br/>
+1. Optimal <br/>
+2. Optional / Stretch-goal <br/>

doc/user-docs/ThirdPartyToolProfiles.md

@@ -0,0 +1,67 @@
+# Adding profiles for third-party tools
+
+This doc will hopefully provide a useful guide for adding profiles for common
+third-party tools to your
+[profiles.json](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md)
+file.
+
+All of these profiles are provided _without_ their `guid` set. If you'd like to
+set any of these profiles as your _default_ profile, you'll need to make sure to
+[generate a unique guid](https://www.guidgenerator.com/) for them manually.
+
+## Anaconda
+
+Assuming that you've installed Anaconda into `%USERPROFILE%\Anaconda3`:
+
+```json
+{
+    "commandline" : "cmd.exe /K %USERPROFILE%\\Anaconda3\\Scripts\\activate.bat %USERPROFILE%\\Anaconda3",
+    "icon" : "%USERPROFILE%/Anaconda3/Menu/anaconda-navigator.ico",
+    "name" : "Anaconda3",
+    "startingDirectory" : "%USERPROFILE%"
+}
+```
+
+## cmder
+
+Assuming that you've installed cmder into `%CMDER_ROOT%`:
+
+```json
+{
+    "commandline" : "cmd.exe /k %CMDER_ROOT%\\vendor\\init.bat",
+    "name" : "cmder",
+    "startingDirectory" : "%USERPROFILE%"
+}
+```
+
+## Cygwin
+
+Assuming that you've installed Cygwin into `C:/Cygwin`:
+
+```json
+{
+    "name" : "Cygwin",
+    "commandline" : "C:/Cygwin/bin/bash --login -i",
+    "icon" : "C:/Cygwin/Cygwin.ico",
+    "startingDirectory" : "C:/Cygwin/bin"
+}
+```
+
+Note that the starting directory of Cygwin is set as it is to make the path
+work. The default directory opened when starting Cygwin will be `$HOME` because
+of the `--login` flag.
+
+## Git Bash
+
+Assuming that you've installed Git Bash into `C:/Program Files/Git`:
+
+```json
+{
+    "name" : "Git Bash",
+    "commandline" : "C:/Program Files/Git/bin/bash.exe",
+    "icon" : "C:/Program Files/Git/mingw64/share/git/git-for-windows.ico",
+    "startingDirectory" : "%USERPROFILE%"
+}
+````
+
+<!-- Adding a tool here? Make sure to add it in alphabetical order! -->

doc/user-docs/UsingJsonSettings.md

@@ -1,12 +1,22 @@
 # Editing Windows Terminal JSON Settings
 
-One way (currently the only way) to configure Windows Terminal is by editing the profiles.json settings file. At
-the time of writing you can open the settings file in your default editor by selecting
-`Settings` from the WT pull down menu.
+One way (currently the only way) to configure Windows Terminal is by editing the
+`profiles.json` settings file. At the time of writing you can open the settings
+file in your default editor by selecting `Settings` from the WT pull down menu.
 
-The settings are stored in the file `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_<randomString>\RoamingState\profiles.json` 
+The settings are stored in the file `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\profiles.json`.
 
-Details of specific settings can be found [here](../cascadia/SettingsSchema.md). A general introduction is provided below.
+As of [#2515](https://github.com/microsoft/terminal/pull/2515), the settings are
+split into _two_ files: a hardcoded `defaults.json`, and `profiles.json`, which
+contains the user settings. Users should only be concerned with the contents of
+the `profiles.json`, which contains their customizations. The `defaults.json`
+file is only provided as a reference of what the default settings are. For more
+details on how these two files work, see [Settings
+Layering](#settings-layering). To view the default settings file, click on the
+"Settings" button while holding the <kbd>Alt</kbd> key.
+
+Details of specific settings can be found [here](../cascadia/SettingsSchema.md).
+A general introduction is provided below.
 
 The settings are grouped under four headings:
 
@@ -17,12 +27,13 @@ The settings are grouped under four headings:
 
 ## Global Settings
 
-These settings define startup defaults.
+These settings define startup defaults, and application-wide settings that might
+not affect a particular terminal instance.
 
 * Theme
 * Title Bar options
 * Initial size
-* Default profile used when WT is started
+* Default profile used when the Windows Terminal is started
 
 Example settings include
 
@@ -31,10 +42,13 @@ Example settings include
     "initialCols" : 120,
     "initialRows" : 50,
     "requestedTheme" : "system",
-    "keybinding" : []
+    "keybindings" : []
     ...
 ```
 
+These global properties can exist either in the root json object, or in and
+object under a root property `"globals"`.
+
 ## Key Bindings
 
 This is an array of key chords and shortcuts to invoke various commands.
@@ -43,10 +57,47 @@ Each command can have more than one key binding.
 NOTE: Key bindings is a subfield of the global settings and
 key bindings apply to all profiles in the same manner.
 
+For example, here's a sample of the default keybindings:
+
+```json
+{
+    "keybindings":
+    [
+        { "command": "closePane", "keys": ["ctrl+shift+w"] },
+        { "command": "copy", "keys": ["ctrl+shift+c"] },
+        { "command": "newTab", "keys": ["ctrl+shift+t"] },
+        // etc.
+    ]
+}
+
+```
+
+### Unbinding keys
+
+If you ever come across a key binding that you're unhappy with, it's possible to
+easily change the keybindings. For example, vim uses <kbd>Ctrl+^</kbd> as a
+binding for "switch to previous buffer", which conflicts with the Terminal's
+default keybinding for "open a new tab with the sixth profile". If you'd like to
+unbind that keybinding, and allow the keystroke to fall through to vim, you can
+add the following to your keybindings:
+
+```json
+{
+    "command" : null, "keys" : ["ctrl+shift+6"]
+},
+```
+
+This will _unbind_ <kbd>Ctrl+Shift+6</kbd>, allowing vim to use the keystroke
+instead of the terminal.
+
 ## Profiles
 
-A profile contains the settings applied when a new WT tab is opened. Each profile is identified by a GUID and contains
-a number of other fields.
+A profile contains the settings applied when a new WT tab is opened. Each
+profile is identified by a GUID and contains a number of other fields.
+
+> 👉 **Note**: The `guid` property is the unique identifier for a profile. If
+> multiple profiles all have the same `guid` value, you may see unexpected
+> behavior.
 
 * Which command to execute on startup - this can include arguments.
 * Starting directory
@@ -67,14 +118,24 @@ Example settings include
     "fontSize" : 9,
     "guid" : "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",
     "name" : "Debian",
-    "startingDirectory" : "%USERPROFILE%/wslhome"
+    "startingDirectory" : "%USERPROFILE%\\wslhome"
     ....
 ```
 
+> 👉 **Note**: To use backslashes in any path field, you'll need to escape them following JSON escaping rules (like shown above). As an alternative, you can use forward slashes ("%USERPROFILE%/wslhome").
+
 The profile GUID is used to reference the default profile in the global settings.
 
 The values for background image stretch mode are documented [here](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.media.stretch)
 
+### Hiding a profile
+
+If you want to remove a profile from the list of profiles in the new tab
+dropdown, but keep the profile around in your `profiles.json` file, you can add
+the property `"hidden": true` to the profile's json. This can also be used to
+remove the default `cmd` and PowerShell profiles, if the user does not wish to
+see them.
+
 ##  Color Schemes
 
 Each scheme defines the color values to be used for various terminal escape sequences.
@@ -95,22 +156,197 @@ Each schema is identified by the name field. Examples include
 
 The schema name can then be referenced in one or more profiles.
 
+## Settings layering
+
+The runtime settings are actually constructed from _three_ sources:
+* The default settings, which are hardcoded into the application, and available
+  in `defaults.json`. This includes the default keybindings, color schemes, and
+  profiles for both Windows PowerShell and Command Prompt (`cmd.exe`).
+* Dynamic Profiles, which are generated at runtime. These include Powershell
+  Core, the Azure Cloud Shell connector, and profiles for and WSL distros.
+* The user settings from `profiles.json`.
+
+Settings from each of these sources are "layered" upon the settings from
+previous sources. In this manner, the user settings in `profiles.json` can
+contain _only the changes from the default settings_. For example, if a user
+would like to only change the color scheme of the default `cmd` profile to
+"Solarized Dark", you could change your cmd profile to the following:
+
+```js
+        {
+            // Make changes here to the cmd.exe profile
+            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+            "colorScheme": "Solarized Dark"
+        }
+```
+
+Here, we know we're changing the `cmd` profile, because the `guid`
+`"{0caa0dad-35be-5f56-a8ff-afceeeaa6101}"` is `cmd`'s unique GUID. Any profiles
+with that GUID will all be treated as the same object. Any changes in that
+profile will overwrite those from the defaults.
+
+Similarly, you can overwrite settings from a color scheme by defining a color
+scheme in `profiles.json` with the same name as a default color scheme.
+
+If you'd like to unbind a keystroke that's bound to an action in the default
+keybindings, you can set the `"command"` to `"unbound"` or `null`. This will
+allow the keystroke to fallthough to the commandline application instead of
+performing the default action.
+
+### Dynamic Profiles
+
+When dynamic profiles are created at runtime, they'll be added to the
+`profiles.json` file. You can identify these profiles by the presence of a
+`"source"` property. These profiles are tied to their source - if you uninstall
+a linux distro, then the profile will remain in your `profiles.json` file, but
+the profile will be hidden.
+
+The Windows Terminal uses the `guid` property of these dynamically-generated
+profiles to uniquely identify them. If you try to change the `guid` of a
+dynamically-generated profile, the Terminal will automatically recreate a new
+entry for that profile.
+
+If you'd like to disable a particular dynamic profile source, you can add that
+`source` to the global `"disabledProfileSources"` array. For example, if you'd
+like to hide all the WSL profiles, you could add the following setting:
+
+```json
+
+    "disabledProfileSources": ["Microsoft.Terminal.WSL"],
+    ...
+
+```
+
+### Default settings
+
+In [#2325](https://github.com/microsoft/terminal/issues/2325), we introduced the
+concept of "Default Profile Settings". These are settings that will apply to all
+of your profiles by default. Profiles can still override these settings
+individually. With default profile settings, you can easily make changes to all
+your profiles at once. For example, given the following settings:
+
+```json
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "profiles":
+    [
+        {
+            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+            "name": "Windows PowerShell",
+            "commandline": "powershell.exe",
+            "fontFace": "Cascadia Code",
+            "fontSize": 14
+        },
+        {
+            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+            "name": "cmd",
+            "commandline": "cmd.exe",
+            "fontFace": "Cascadia Code",
+            "fontSize": 14
+        },
+        {
+            "commandline" : "cmd.exe /k %CMDER_ROOT%\\vendor\\init.bat",
+            "name" : "cmder",
+            "startingDirectory" : "%USERPROFILE%",
+            "fontFace": "Cascadia Code",
+            "fontSize": 14
+        }
+    ],
+```
+
+All three of these profiles are using "Cascadia Code" as their `"fontFace"`, and
+14 as their `fontSize`. With default profile settings, you can easily set these
+properties for all your profiles, like so:
+
+```json
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "profiles": {
+        "defaults":
+        {
+            "fontFace": "Cascadia Code",
+            "fontSize": 14
+        },
+        "list": [
+            {
+                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+                "name": "Windows PowerShell",
+                "commandline": "powershell.exe",
+            },
+            {
+                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+                "name": "cmd",
+                "commandline": "cmd.exe"
+            },
+            {
+                "commandline" : "cmd.exe /k %CMDER_ROOT%\\vendor\\init.bat",
+                "name" : "cmder",
+                "startingDirectory" : "%USERPROFILE%"
+            }
+        ],
+    }
+```
+
+Note that the `profiles` property has changed in this example from a _list_ of
+profiles, to an _object_ with two properties:
+* a `list` that contains the list of all the profiles
+* the new `defaults` object, which contains all the settings that should apply to
+  every profile.
+
+What if I wanted a profile to have a different value for a property other than
+the default? Simply set the property in the profile's entry to override the
+value from `defaults`. Let's say you want the `cmd` profile to have _"Consolas"_
+as the font, but the rest of your profiles to still have _"Cascadia Code"_. You
+could achieve that with the following:
+
+```json
+    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+    "profiles": {
+        "defaults":
+        {
+            "fontFace": "Cascadia Code",
+            "fontSize": 14
+        },
+        "list": [
+            {
+                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
+                "name": "Windows PowerShell",
+                "commandline": "powershell.exe",
+            },
+            {
+                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
+                "name": "cmd",
+                "commandline": "cmd.exe",
+                "fontFace": "Consolas"
+            },
+            {
+                "commandline" : "cmd.exe /k %CMDER_ROOT%\\vendor\\init.bat",
+                "name" : "cmder",
+                "startingDirectory" : "%USERPROFILE%"
+            }
+        ],
+    }
+```
+
+In the above settings, the `"fontFace"` in the `cmd.exe` profile overrides the
+`"fontFace"` from the `defaults`.
+
+
 ## Configuration Examples:
 
 ### Add a custom background to the WSL Debian terminal profile
 
-1. Download the Debian SVG logo https://www.debian.org/logos/openlogo.svg
+1. Download the Debian JPG logo https://www.debian.org/logos/openlogo-100.jpg
 2. Put the image in the
- `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_<randomString>\RoamingState\`
+ `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_<randomString>\LocalState\`
  directory (same directory as your `profiles.json` file).
 
     __NOTE__:  You can put the image anywhere you like, the above suggestion happens to be convenient.
 3. Open your WT json properties file.
 4. Under the Debian Linux profile, add the following fields:
 ```json
-    "backgroundImage": "ms-appdata:///Roaming/openlogo.jpg",
-    "backgroundImageOpacity": 0.3,
-    "backgroundImageStretchMode":  "fill",
+    "backgroundImage": "ms-appdata:///Local/openlogo-100.jpg",
+    "backgroundImageOpacity": 1,
+    "backgroundImageStretchMode" : "none",
+    "backgroundImageAlignment" : "topRight",
 ```
 5. Make sure that `useAcrylic` is `false`.
 6. Save the file.
@@ -124,5 +360,81 @@ then you should use the URI style path name given in the above example.
 More information about UWP URI schemes [here](https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes).
 3. Instead of using a UWP URI you can use a:
     1. URL such as
-`http://open.esa.int/files/2017/03/Mayer_and_Bond_craters_seen_by_SMART-1-350x346.jpg` 
+`http://open.esa.int/files/2017/03/Mayer_and_Bond_craters_seen_by_SMART-1-350x346.jpg`
     2. Local file location such as `C:\Users\Public\Pictures\openlogo.jpg`
+
+### Adding Copy and Paste Keybindings
+
+As of [#1093](https://github.com/microsoft/terminal/pull/1093) (first available
+in Windows Terminal v0.3), the Windows Terminal now supports copy and paste
+keyboard shortcuts. However, if you installed and ran the terminal before that,
+you won't automatically get the new keybindings added to your settings. If you'd
+like to add shortcuts for copy and paste, you can do so by inserting the
+following objects into your `globals.keybindings` array:
+
+```json
+{ "command": "copy", "keys": ["ctrl+shift+c"] },
+{ "command": "paste", "keys": ["ctrl+shift+v"] }
+```
+
+> 👉 **Note**: you can also add a keybinding for the `copyTextWithoutNewlines` command. This removes newlines as the text is copied to your clipboard.
+
+This will add copy and paste on <kbd>ctrl+shift+c</kbd>
+and <kbd>ctrl+shift+v</kbd> respectively.
+
+You can set the keybindings to whatever you'd like. If you prefer
+<kbd>ctrl+c</kbd> to copy, then set the `keys` to `"ctrl+c"`.
+
+You can even set multiple keybindings for a single action if you'd like. For example:
+
+```json
+
+            {
+                "command" : "paste",
+                "keys" :
+                [
+                    "ctrl+shift+v"
+                ]
+            },
+            {
+                "command" : "paste",
+                "keys" :
+                [
+                    "shift+insert"
+                ]
+            }
+```
+
+will bind both <kbd>ctrl+shift+v</kbd> and
+<kbd>shift+Insert</kbd> to `paste`.
+
+> 👉 **Note**: If you set your copy keybinding to `"ctrl+c"`, you'll only be able to send
+an interrupt to the commandline application using <kbd>Ctrl+C</kbd> when there's
+no text selection. Additionally, if you set `paste` to `"ctrl+v"`, commandline
+applications won't be able to read a ctrl+v from the input. For these reasons,
+we suggest `"ctrl+shift+c"` and `"ctrl+shift+v"`
+
+
+### Setting the `startingDirectory` of WSL Profiles to `~`
+
+By default, the `startingDirectory` of a profile is `%USERPROFILE%`
+(`C:\Users\<YourUsername>`). This is a Windows path. However, for WSL, you might
+want to use the WSL home path instead. At the time of writing (26decf1 / Nov.
+1st, 2019), `startingDirectory` only accepts a Windows-style path, so setting it
+to start within the WSL distro can be a little tricky.
+
+Fortunately, with Windows 1903, the filesystems of WSL distros can easily be
+addressed using the `\\wsl$\` prefix. For any WSL distro whose name is
+`DistroName`, you can use `\\wsl$\DistroName` as a Windows path that points to
+the root of that distro's filesystem.
+
+For example, the following works as a profile to launch the "Ubuntu-18.04"
+distro in it's home path:
+
+```json
+{
+    "name": "Ubuntu-18.04",
+    "commandline" : "wsl -d Ubuntu-18.04",
+    "startingDirectory" : "//wsl$/Ubuntu-18.04/home/<Your Ubuntu Username>",
+}
+```

doc/user-docs/index.md

@@ -3,27 +3,25 @@
 NOTE: At the time of writing Windows Terminal is still under active development and many things will
 change. If you notice an error in the docs, please raise an issue. Or better yet, please file a PR with an appropriate update!
 
-## Installing Windows Terminal 
+## Installing Windows Terminal
 
 ### From Source Code
 
-Follow the instructions in this repo's [README](/README.md#developer-guidance).
+To compile Windows Terminal yourself using the source code, follow the instructions in the [README](/README.md#developer-guidance).
 
 ### From the Microsoft Store
 
-1. Make sure you have upgraded to the current Windows 10 release (at least 1903)
-2. Search for Windows Terminal in the Store
-3. Review the minimum system settings to ensure you can successfully install Windows Terminal
-4. Install in the normal fashion
+1. Make sure you have upgraded to the current Windows 10 release (at least build `1903`). To determine your build number, see [winver](https://docs.microsoft.com/en-us/windows/client-management/windows-version-search).
+2. Open the Windows Terminal listing in the [Microsoft Store](https://aka.ms/install-terminal).
+3. Review the minimum system requirements to confirm you can successfully install Windows Terminal.
+4. Click `Get` to begin the installation process.
 
 ## Starting Windows Terminal
 
-From the Windows Start menu, select Windows Terminal and run the application.
-
-Note: You can right click on the application item and run with Windows Administrator privilege if required.
-
-The default shell is PowerShell.
+1. Locate the _Windows Terminal_ app in your Start menu.
+2. Click _Windows Terminal_ to launch the app. If you need administrative privileges, right-click the entry and click `Run as administrator`. Alternatively, you can highlight the app and press `Ctrl`+`Shift`+`Enter`.
 
+NOTE: The default shell is PowerShell; you can change this using the _Running a Different Shell_ procedure.
 
 ### Command line options
 
@@ -32,32 +30,34 @@ None at this time. See issue [#607](https://github.com/microsoft/terminal/issues
 ## Multiple Tabs
 
 Additional shells can be started by hitting the `+` button from the tab bar -- a new instance of the
-default shell is displayed (default shortcut `Ctrl+Shift+1`).
+default shell is displayed (default shortcut: <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>1</kbd>).
 
 ## Running a Different Shell
 
-Note: The following text assumes you have WSL installed.
+Note: This section assumes you already have _Windows Subsystem for Linux_ (WSL) installed. For more information, see [the installation guide](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
 
-To choose a different shell (e.g. `cmd.exe` or WSL `bash`) then
+Windows Terminal uses PowerShell as its default shell. You can also use Windows Terminal to launch other shells, such as `cmd.exe` or WSL's `bash`:
 
-1. Select the `down` button next to the `+` in the tab bar
-2. Choose your new shell from the list (more on how to extend the list in the config section)
+1. In the tab bar, click the `⌵` button to view the available shells.
+2. Choose your shell from the dropdown list. The new shell session will open in a new tab.
+
+To customize the shell list, see the _Configuring Windows Terminal_ section below.
 
 ## Starting a new PowerShell tab with admin privilege
 
-There is no current plan to support this feature for security reaons. See issue [#623](https://github.com/microsoft/terminal/issues/632)
+There is no current plan to support this feature for security reasons. See issue [#623](https://github.com/microsoft/terminal/issues/632)
 
-## Using cut and paste in the Terminal window
+## Selecting and Copying Text in Windows Terminal
 
-### With PowerShell
+As in ConHost, a selection can be made by left-clicking and dragging the mouse across the terminal. This is a line selection by default, meaning that the selection will wrap to the end of the line and the beginning of the next one. You can select in block mode by holding down the <kbd>Alt</kbd> key when starting a selection.
 
-* Copy - Select the text with mouse (default left button), then right click with mouse
-* Paste - by default use `<ctrl>+v`>, or right click with mouse
+To copy the text to your clipboard, you can right-click the terminal when a selection is active. As of [#1224](https://github.com/microsoft/terminal/pull/1224) (first available in Windows Terminal v0.4), the Windows Terminal now supports HTML copy. The HTML is automatically copied to your clipboard along with the regular text in any copy operation.
 
-### With Bash
+If there is not an active selection, a right-click will paste the text content from your clipboard to the terminal.
 
-* Copy - Select the text with mouse (default left button), then right click with mouse
-* Paste - Right click with mouse
+Copy and paste operations can also be keybound. For more information on how to bind keys, see [Using Json Settings](UsingJsonSettings.md#adding-copy-and-paste-keybindings).
+
+> 👉 **Note**: If you have the `copyOnSelect` global setting enabled, a selection will persist and immediately copy the selected text to your clipboard. Right-clicking will always paste your clipboard data.
 
 ## Add a "Open Windows Terminal Here" to File Explorer
 
@@ -65,16 +65,15 @@ Not currently supported "out of the box". See issue [#1060](https://github.com/m
 
 ## Configuring Windows Terminal
 
-At the time of writing all Windows Terminal settings are managed via a json file.
+All Windows Terminal settings are currently managed using the `profiles.json` file, located within `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe/LocalState`.
 
-From the `down` button in the top bar select Settings (default shortcut `Ctrl+,`).
+To open the settings file from Windows Terminal:
 
-Your default json editor will open up the Terminal settings file. The file can be found
-at `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_<randomString>/RoamingState`
+1. Click the `⌵` button in the top bar.
+2. From the dropdown list, click `Settings`. You can also use a shortcut: <kbd>Ctrl</kbd>+<kbd>,</kbd>.
+3. Your default `json` editor will open the settings file.
 
-An introduction to the the various settings can be found [here](UsingJsonSettings.md).
-
-The list of valid settings can be found in the [Profiles.json Documentation](../cascadia/SettingsSchema.md) doc.
+For an introduction to the various settings, see [Using Json Settings](UsingJsonSettings.md). The list of valid settings can be found in the [profiles.json documentation](../cascadia/SettingsSchema.md) section.
 
 ## Tips and Tricks:
 
@@ -85,6 +84,6 @@ The list of valid settings can be found in the [Profiles.json Documentation](../
 
     (ref https://twitter.com/r_keith_hill/status/1142871145852440576)
 
-2. Terminal zoom can be changed by holding `Ctrl` and scrolling with mouse.
-3. If `useAcrylic` is enabled in profiles.json, background opacity can be changed by holding `Ctrl+Shift` and scrolling with mouse.
+2. Terminal zoom can be changed by holding <kbd>Ctrl</kbd> and scrolling with mouse.
+3. If `useAcrylic` is enabled in profiles.json, background opacity can be changed by holding <kbd>Ctrl</kbd>+<kbd>Shift</kbd> and scrolling with mouse.
 4. Please add more Tips and Tricks

doc/virtual-dtors.md

@@ -27,7 +27,7 @@ You may ask yourself, why is the destructor deleted, then later defined to the
   strangeness that can occur as well, the details of which escape my memory from
   when @austdi and I first investigaved this early 2018.
 
-The end result of not defining your interfaces exacly like this will be that
+The end result of not defining your interfaces exactly like this will be that
   occasionally, when destructing objects, you'll get a segfault.
 
 To check that this behavior works, I direct your attention to the VtIoTests.

pkg/appx/OpenConsolePackage.wapproj

@@ -1,86 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <Import Project="..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
-  <Import Project="$(OpenConsoleDir)src\wap-common.build.pre.props" />
-
-  <PropertyGroup Label="Configuration">
-    <TargetPlatformVersion>10.0.17763.0</TargetPlatformVersion>
-    <TargetPlatformMinVersion>10.0.17134.0</TargetPlatformMinVersion>
-    <!--
-    These two properties are very important!
-    Without them, msbuild will stomp MinVersion and MaxVersionTested in the
-    Package.appxmanifest and replace them with whatever our values for
-    TargetPlatformMinVersion and TargetPlatformVersion are.
-     -->
-    <AppxOSMinVersionReplaceManifestVersion>false</AppxOSMinVersionReplaceManifestVersion>
-    <AppxOSMaxVersionTestedReplaceManifestVersion>false</AppxOSMaxVersionTestedReplaceManifestVersion>
-
-    <!-- In a WAP project, this suppresses a spurious dependency on the non-Desktop VCLibs. -->
-    <IncludeGetResolvedSDKReferences>false</IncludeGetResolvedSDKReferences>
-
-    <!-- Suppress the inclusion of Windows.winmd in the appx. -->
-    <SkipUnionWinmd>true</SkipUnionWinmd>
-  </PropertyGroup>
-
-  <PropertyGroup>
-    <ProjectGuid>2D310963-F3E0-4EE5-8AC6-FBC94DCC3310</ProjectGuid>
-
-    <EntryPointExe>OpenConsole.exe</EntryPointExe>
-    <EntryPointProjectUniqueName>..\..\src\host\exe\Host.EXE.vcxproj</EntryPointProjectUniqueName>
-  </PropertyGroup>
-
-  <PropertyGroup>
-    <GenerateAppInstallerFile>False</GenerateAppInstallerFile>
-  </PropertyGroup>
-
-  <PropertyGroup Condition="!Exists('OpenConsolePackage_TemporaryKey.pfx')">
-    <AppxPackageSigningEnabled>false</AppxPackageSigningEnabled>
-    <AppxBundle>Never</AppxBundle>
-  </PropertyGroup>
-
-  <PropertyGroup Condition="Exists('OpenConsolePackage_TemporaryKey.pfx')">
-    <AppxPackageSigningEnabled>true</AppxPackageSigningEnabled>
-    <AppxAutoIncrementPackageRevision>False</AppxAutoIncrementPackageRevision>
-    <PackageCertificateKeyFile>OpenConsolePackage_TemporaryKey.pfx</PackageCertificateKeyFile>
-  </PropertyGroup>
-
-  <ItemGroup Condition="Exists('OpenConsolePackage_TemporaryKey.pfx')">
-    <None Include="OpenConsolePackage_TemporaryKey.pfx" />
-  </ItemGroup>
-
-  <ItemGroup>
-    <AppxManifest Include="Package.appxmanifest">
-      <SubType>Designer</SubType>
-    </AppxManifest>
-  </ItemGroup>
-
-  <ItemGroup>
-    <Content Include="images\LockScreenLogo.scale-200.png" />
-    <Content Include="images\Square150x150Logo.scale-200.png" />
-    <Content Include="images\Square44x44Logo.scale-200.png" />
-    <Content Include="images\Square44x44Logo.targetsize-16_altform-unplated.png" />
-    <Content Include="images\Square44x44Logo.targetsize-24_altform-unplated.png" />
-    <Content Include="images\Square44x44Logo.targetsize-32_altform-unplated.png" />
-    <Content Include="images\Square44x44Logo.targetsize-48_altform-unplated.png" />
-    <Content Include="images\Square44x44Logo.targetsize-256_altform-unplated.png" />
-    <Content Include="images\StoreLogo.png" />
-    <Content Include="images\Wide310x150Logo.scale-200.png" />
-  </ItemGroup>
-
-  <Import Project="$(OpenConsoleDir)src\wap-common.build.post.props" />
-
-  <ItemGroup>
-    <ProjectReference Include="..\..\src\host\exe\Host.EXE.vcxproj" />
-    <ProjectReference Include="..\..\src\propsheet\propsheet.vcxproj" />
-  </ItemGroup>
-
-  <Target Name="OpenConsoleStompSourceProjectForWapProject" BeforeTargets="_ConvertItems">
-    <ItemGroup>
-      <_TemporaryFilteredWapProjOutput Include="@(_FilteredNonWapProjProjectOutput)" />
-      <_FilteredNonWapProjProjectOutput Remove="@(_FilteredNonWapProjProjectOutput)" />
-      <_FilteredNonWapProjProjectOutput Include="@(_TemporaryFilteredWapProjOutput)">
-        <SourceProject></SourceProject> <!-- Blank SourceProject, which WapProj uses to name subdirectories. -->
-      </_FilteredNonWapProjProjectOutput>
-    </ItemGroup>
-  </Target>
-</Project>

pkg/appx/Package.appxmanifest

@@ -1,34 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3" xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5" xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10" xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4" IgnorableNamespaces="uap mp rescap">
-  <Identity Name="Microsoft.WindowsConsoleHost" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="0.9.0.0" />
-  <Properties>
-    <DisplayName>Windows Console (Preview)</DisplayName>
-    <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
-    <Logo>images\StoreLogo.png</Logo>
-  </Properties>
-  <Dependencies>
-    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0" MaxVersionTested="10.0.14393.0" />
-  </Dependencies>
-  <Resources>
-    <Resource Language="x-generate" />
-  </Resources>
-  <Applications>
-    <Application Id="App" Executable="OpenConsole.exe" EntryPoint="$targetentrypoint$">
-      <Extensions>
-        <uap3:Extension Category="windows.appExecutionAlias" EntryPoint="Windows.FullTrustApplication" Executable="OpenConsole.exe">
-          <uap3:AppExecutionAlias>
-            <desktop:ExecutionAlias Alias="OpenConsole.exe" />
-            <desktop:ExecutionAlias Alias="confans.exe" />
-          </uap3:AppExecutionAlias>
-        </uap3:Extension>
-      </Extensions>
-      <uap:VisualElements DisplayName="Windows Console (Preview)" Description="The Windows Console, but actually fun!" BackgroundColor="transparent" Square150x150Logo="images\Square150x150Logo.png" Square44x44Logo="images\Square44x44Logo.png">
-        <uap:DefaultTile Wide310x150Logo="images\Wide310x150Logo.png">
-        </uap:DefaultTile>
-      </uap:VisualElements>
-    </Application>
-  </Applications>
-  <Capabilities>
-    <rescap:Capability Name="runFullTrust" />
-  </Capabilities>
-</Package>

res/README.md

@@ -1,6 +1,21 @@
 # Windows Terminal and Console Assets
 
-The assets in this directory do not fall under the same [license](https://raw.githubusercontent.com/microsoft/terminal/master/LICENSE) as the rest
+## Images
+
+The images in this directory do not fall under the same [license](https://raw.githubusercontent.com/microsoft/terminal/master/LICENSE) as the rest
 of the Windows Terminal code.
 
-Please consult the [license](./LICENSE) in this directory for applicable terms.
+Please consult the [license](./LICENSE) in this directory for terms applicable to the image assets in this directory.
+
+## Fonts
+
+The fonts in this directory do not fall under the same [license](https://raw.githubusercontent.com/microsoft/terminal/master/LICENSE) as the rest
+of the Windows Terminal code.
+
+Please consult the [license](https://raw.githubusercontent.com/microsoft/cascadia-code/master/LICENSE) in the
+[microsoft/cascadia-code](https://github.com/microsoft/cascadia-code) repository for terms applicable to the fonts in this directory.
+
+### Fonts Included
+
+* Cascadia Code
+   * from microsoft/cascadia-code@d733599504811e8f3969de20368817d20e162dba