Before sending calling the `HandleClipboardData` member function on
the `PasteFromClipboardEventArgs` object when we receive a request
from the `TermControl` to send it the clipboard's text content, we
now display a warning to let the user choose whether to continue or
not if the text is larger than 5 KiB or contains the _new line_
character, which can be a security issue if the user is pasting the
text in a shell.

These warnings can be disabled with the `largePasteWarning` and
`multiLinePasteWarning` global settings respectively.

Closes #2349

This commit adds tooltip text to every color button in the tab color
picker.

This PR fixes the scheme resolution bug outlined in #5326

The approach is as follows:

* In [SchemeManager.cs], find the first scheme parser that actually
  successfully parses the scheme, as opposed to the existing code, which
  finds the first scheme parser which _says it can parse the scheme_, as
  that logic spuriously returns `true` currently. 
* In [XmlSchemeParser.cs] and [JsonParser.cs], ensure that the contents
  of the file are read and the contents passed to XmlDocument.LoadXXX,
  as this fails with an UriException on WSL otherwise.
* Remove `CanParse` as it is superfluous. The check for a valid scheme
  parser should not just check an extension but also if the file exists
  - this is best done by the `ParseScheme` function as it already
  returns null on failure.
* Add `FileExtension` to the interface because we need it lifted now.

Closes #5326

Pretty straightforward. `toggleRetroEffect` will work to toggle the
retro terminal effect on/off. 

* Made possible by contributions from #6551, _and viewers like you_

…6763)

The VT reset operations `RIS` and `DECSTR` are implemented as a series
of steps, each of which could potentially fail. Currently these
operations abort as soon as an error is detected, which is particularly
problematic in conpty mode, where some steps deliberately "fail" to
indicate that they need to be "passed through" to the conpty client. As
a result, the reset won't be fully executed. This PR changes that
behaviour, so the error state is recorded for any failures, but the
subsequent steps are still run.

Originally the structure of these operations was of the form:

    bool success = DoSomething();
    if (success)
    {
        success = DoSomethingElse();
    }

But I've now changed the code so it looks more like this:

    bool success = DoSomething();
    success = DoSomethingElse() && success;

This means that every one of the steps should execute, regardless of
whether previous steps were successful, but the final _success_ state
will only be true if none of the steps has failed.

While this is only really an issue in the conhost code, I've updated
both the `AdaptDispatch` and `TerminalDispatch` classes, since I thought
it would be best to have them in sync, and in general this seems like a
better way to handle multi-step operations anyway.

VALIDATION

I've manually tested the `RIS` escape sequence (`\ec`) in the Windows
Terminal, and confirmed that it now correctly resets the cursor
position, which it wasn't doing before.

Closes #6545

## Summary of the Pull Request

This PR adds support for the `SGR 53` and `SGR 55` escapes sequences,
which enable and disable the ANSI _overline_ graphic rendition
attribute, the equivalent of the console character attribute
`COMMON_LVB_GRID_HORIZONTAL`. When a character is output with this
attribute set, a horizontal line is rendered at the top of the character
cell.

## PR Checklist
* [x] Closes #6000
* [x] CLA signed. 
* [x] Tests added/passed
* [ ] Documentation updated. 
* [ ] Schema updated.
* [x] I've discussed this with core contributors already.

## Detailed Description of the Pull Request / Additional comments

To start with, I added `SetOverline` and `IsOverlined` methods to the
`TextAttribute` class, to set and get the legacy
`COMMON_LVB_GRID_HORIZONTAL` attribute. Technically there was already an
`IsTopHorizontalDisplayed` method, but I thought it more readable to add
a separate `IsOverlined` as an alias for that.

Then it was just a matter of adding calls to set and reset the attribute
in response to the `SGR 53` and `SGR 55` sequences in the
`SetGraphicsRendition` methods of the two dispatchers. The actual
rendering was already taken care of by the `PaintBufferGridLines` method
in the rendering engines.

The only other change required was to update the `_UpdateExtendedAttrs`
method in the `Xterm256Engine` of the VT renderer, to ensure the
attribute state would be forwarded to the Windows Terminal over conpty.

## Validation Steps Performed

I've extended the existing SGR unit tests to cover the new attribute in
the `AdapterTest`, the `OutputEngineTest`, and the `VtRendererTest`.
I've also manually tested the `SGR 53` and `SGR 55` sequences to confirm
that they do actually render (or remove) an overline on the characters
being output.

…utton (#6766)

The MUX TabView control has a uniquely-shaped [+] button.  TerminalApp
doesn't use it: instead, it has a SplitView button that is styled to
look like MUX's official button.  However, it doesn't get the button's
shape right.  This PR updates TerminalApp's custom button to look more
like MUX's.

The difference is that MUX only rounds the top two corners, and it uses
a bigger radius.  Without matching MUX's radius, the upper-left corner
of the button makes an awkward asymmetric divot with the abutting tab.
There's also a spot in the lower-left corner that just looks like
someone accidentally spilled a few pixels on the floor.

Current appearance before this PR:
![oldlight](https://user-images.githubusercontent.com/10259764/86410863-74ca5e80-bc70-11ea-8c15-4ae22998b209.png)

New appearance with this PR:
![newlight](https://user-images.githubusercontent.com/10259764/86410871-772cb880-bc70-11ea-972c-13332f1a1bdb.png)

Most important deltas highlighted with red circles:
![marklight](https://user-images.githubusercontent.com/10259764/86410877-78f67c00-bc70-11ea-8a6d-696cfbd89b1d.png)


Note that this PR does *not* attempt to fix the colors.  The colors are
also just slightly different from what MUX uses.  I'll save that for a
separate PR, since all those screenshots would clutter this up this PR.

## Summary of the Pull Request

Let's try and figure out just how many people are actually using Solarized. I emailed @DHowett about this a week ago, but otherwise we don't really have any other tasks for this.

## PR Checklist
* [x] I work here
* [n/a] Requires documentation to be updated

Update colors of our custom NewTab button to match MUX's TabView button

MUX has a NewTab button, but Terminal uses a homemade lookalike.  The
version in Terminal doesn't use the same brush color resources as MUX's
button, so it looks very slightly different.  This PR updates Terminal's
button to use the exact same colors that MUX uses.  I literally copied
these brush names out of MUX source code.

## References
This is the color version of the layout fix #6766 
This is a prerequisite for fixing #5360

## Detailed Description of the Pull Request / Additional comments
The real reason that this matters is that once you flip on
`ApplicationHighContrastAdjustment::None`, the existing colors will not
work at all.  The existing brushes are themed to black foreground on a
black background when High Contrast (HC) Black theme is enabled.  The
only thing that's saving you is
`ApplicationHighContrastAdjustment::Auto` is automatically backplating
the glyphs on the buttons, which (by design) hides the fact that the
colors are poor.  The backplates are those ugly squares inside the
buttons on the HC themes.

Before I can push a PR that disables automatic backplating (set
`ApplicationHighContrastAdjustment` to `None`), we'll need to select
better brushes that work in HC mode.  MUX has already selected brushes
that work great in all modes, so it just makes sense to use their
brushes.

The one very subtle difference here is that, for non-HC themes, the
glyph's foreground has a bit more contrast when the button is in
hovered/pressed states.  Again this slight difference hardly matters
now, but using the correct brushes will become critical when we try to
remove the HC backplating.

Closes #6812

## Summary of the Pull Request

This proposes a change to how Terminal will scroll in response to newly
generated output. The Terminal will scroll upon receiving new output if
the viewport is at the bottom of the scroll history and no selection is
active.

This spec also explores the possibility of making this response
configurable with a `snapOnOutput` profile setting. It also discusses
the possibility of adding a scroll lock keybinding action.

## PR Checklist
* [X] Spec for #980

…6806)

## Summary of the Pull Request

In the wake of #6635, a couple things got missed in merges:
* `toggleRetroEffect` didn't get into the schema, nor did `renameTab` or
  `commandPalette`.
* `toggleRetroEffect` also didn't get a name

Furthermore, I thought it might be a good idea to start sticking
commands into `bindings` even without `keys`. So I tried doing that for
`opentabColorPicker` and `toggleRetroEffect`, and found immediately that
the labels for the key chord still appear even when the text is empty.
So I added some XAML magic to hide those when the text is empty.

## References
* #6762 
* #6691
* #6557 
* #6635 

## PR Checklist
* [x] Closes #6762
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

* See also: https://docs.microsoft.com/en-us/windows/uwp/data-binding/data-binding-quickstart#formatting-or-converting-data-values-for-display
  - make sure to switch to C++/WinRT at the top!

## Validation Steps Performed
Removed all my manual actions, ran the Terminal:
![image](https://user-images.githubusercontent.com/18356694/86652356-f5a79400-bfa9-11ea-9131-5b7d3e835e19.png)

See: https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.200609001

> ### Notable Changes:
> 
>     Resize tab view items only once the pointer has left the TabViewItem strip (microsoft/microsoft-ui-xaml#2569)
>     Align TabView visuals with Edge (microsoft/microsoft-ui-xaml#2201)
>     Fix background of MenuFlyout in white high contrast (microsoft/microsoft-ui-xaml#2446)
>     TabView: Make TabViewItem consume the TabViewItemHeaderForeground theme resource (microsoft/microsoft-ui-xaml#2348)
>     TabView: Add tooltips to its scrolling buttons. (microsoft/microsoft-ui-xaml#2369)


* [x] Related to #5360 (@jtippet confirms that this alone does not close it.)
* [x] I work here

## Summary of the Pull Request

Pretty straightforward. Logs three scenarios:
* The user opened the command palette (and which mode it was opened in)
* The user ran a command from the palette
* The user dismissed the palette without running an action.

We discussed this in team sync yesterday.

## PR Checklist
* [x] I work here
* [n/a] Requires documentation to be updated

WinUI's `Margin` and `Padding` work very similarly. `Margin` distances
ourselves from our parent. Whereas `Padding` distances our children from
ourselves.

Terminal's `padding` setting is actually implemented by defining
`Margin` on the SwapChainPanel. This means that the "padding" that is
created is actually belongs to SwapChainPanel's parent: Grid (not to be
confused with its parent, "RootGrid").

When a user clicks on the padded area, input goes to Grid. But there's a
twist: you can't actually hit Grid. To be able to hit Grid, you can't
just set IsHitTestVisible. You need to set it's Visibility to Visible,
and it's Background to Transparent (not null) [2].

## Validation Steps Performed

- [X] Start a selection from the padding area
- [X] Click on a SearchBox if one is available
   - The SearchBox gets first dibs on the hit test so none gets through
     to the SwapChainPanel

## References
[1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.ishittestvisible
[2] https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/events-and-routed-events-overview#hit-testing-and-input-events

Closes #5626

This PR enables `ApplicationHighContrastAdjustment::None`.  Doing this
disables a set of mitigations in XAML designed to band-aid apps that
were never explicitly designed for High Contrast (HC) modes.  Terminal
now has full control of and responsibility for its appearance in HC
mode.  This allows Terminal to look a lot better.

On paper, we should be able to set `HighContrastAdjustment="None"` on
the `<Application>` element.  But that doesn't have any effect.  I don't
know if this is a bug in `<Toolkit:XamlApplication>` or somewhere else.
So instead I set the property in codebehind, which is not as ideal, but
does at least work.  I'd love to a way to move this into App.xaml.

The Find box had a couple stray styles to override the ToggleButton's
foreground color.  With backplating removed, these styles became
actively harmful (white foreground on highlight color background), so I
just removed them.  The built-in style for ToggleButton is perfect
as-is.

Closes #5360

## PR Checklist
* [x] Closes perf itch.
* [x] I work here.
* [x] Manual perf test.
* [x] Documentation irrelevant.
* [x] Schema irrelevant.
* [x] Am core contributor.

## Detailed Description of the Pull Request / Additional comments
Passes the bitmap by ref into the tracing function instead of making a copy on the way in. It's only read anyway for tracing (if enabled) so the copy was a pointless oversight.

## Validation Steps Performed
- Observed WPR trace before and after with `time cat big.txt` in WSL.

A lot of time was spent between each individual line in the VT paint
engine in allocating some scratch space to assemble the clusters then
deallocating it only to have the next line do that again. Now we just
hold onto that memory space since it should be approximately the size of
a single line wide and will be used over and over and over as painting
continues.

## Validation Steps Performed
- Run `time cat big.txt` under WPR. Checked before and after perf
  metrics.

The main change in 16.7 is the separation of `AppContainerApplication`
into `WindowsStoreApp` and `WindowsAppContainer`. There's been a bit of
interest in splitting packaging away from containment, and this is the
first step in that direction.

We're a somewhat unique application, but as WinUI3 becomes more
prevalent we will become _less_ unique.

Some of these things, I've looked at and wondered how they ever worked.

## PR Checklist
* [x] Closes nothing

## Validation Steps Performed
Built locally and in CI. Tested the generated package with the package tester. Built on 16.6 and seen that it still seems to work.

Looking up the size of the viewport from the underlying dimensions of
the structures seemed like a good idea at the time (so it would only be
in one place), but it turns out to be more of a perf cost than we
expected. Not necessarily on any one hot path, but if we sort by
functions in WPR, it was the top consumer on the Terminal side. This
instead saves the size as a member of the `TextBuffer` and serves that
out. It only changes when it is constructed or resized traditionally, so
it's easy to update/keep track of. It impacted conhost/conpty to a
lesser degree but was still noticeable.

## Validation Steps Performed
- Run `time cat big.txt` under WPR. Checked before and after perf
  metrics.

## PR Checklist
* [x] Closes perf itch
* [x] I work here
* [x] Manual test
* [x] Documentation irrelevant.
* [x] Schema irrelevant.
* [x] Am core contributor.

## Summary of the Pull Request
Updates the Terminal's scroll response to new output. The Terminal will not automatically scroll if...
- a selection is active, or
- the viewport is at the bottom of the scroll history

## References
#2529 - Spec
#3863 - Implementation

## PR Checklist
* [X] Closes #980
* [X] Closes #3863
* [ ] Tests added/passed
* [ ] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments
Updates the `_scrollOffset` value properly in TerminalCore when the cursor moves. We calculate a new `_scrollOffset` based on if we are circling the buffer and how far below the mutable bottom is.

We specifically check for if a selection is active and if the viewport is at the bottom, then use that as a condition for deciding if we should update `_scrollOffset` to the new calculated value or 0 (the bottom of the scroll history).

## Validation Steps Performed
Manual testing. Though I should add automated tests.
- [X] new output
- [X] new output when circling
- [X] new output when circling and viewport is at the top

## Summary of the Pull Request

This PR adds full support for the `DECSCNM` reverse screen mode in the Windows Terminal to align with the implementation in conhost.

## References

* The conhost implementation of `DECSCNM` was in PR #3817.
* WT originally inherited that functionality via the colors being passed through, but that behaviour was lost in PR #6506.

## PR Checklist
* [x] Closes #6622
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] 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: #6622

## Detailed Description of the Pull Request / Additional comments

The `AdaptDispatch::SetScreenMode` now checks if it's in conpty mode and simply returns false to force a pass-through of the mode change. And the `TerminalDispatch` now has its own `SetScreenMode` implementation that tracks any changes to the reversed state, and triggers a redraw in the renderer.

To make the renderer work, we just needed to update the `GetForegroundColor` and `GetBackgroundColor` methods of the terminal's `IRenderData` implementation to check the reversed state, and switch the colors being calculated, the same way the `LookupForegroundColor` and `LookupBackgroundColor` methods work in the conhost `Settings` class.

## Validation Steps Performed

I've manually tested the `DECSCNM` functionality for Windows Terminal in Vttest, and also with some of my own test scripts.

By storing up the accumulated delta in the mouse input handler, we can
enlighten both conhost and terminal about wheel events that are less
than one line in size. Previously, we had a workaround in conhost that
clamped small scroll deltas to a whole line, which made trackpad
scrolling unimaginably fast. Terminal didn't make this mistake, but it
also didn't handle delta accumulation . . . which resulted in the same
behavior.

MouseInput will now wait until it's received WHEEL_DELTA (well-known
constant, value 120) worth of scrolling delta before it dispatches a
single scroll event.

Future considerations may include sending multiple wheel button events
for every *multiple* of WHEEL_DELTA, but that would be a slightly larger
refactoring that I'm not yet ready to undertake.

There's a chance that we should be dividing WHEEL_DELTA by the system's
"number of lines to scroll at once" setting, because on trackpads
conhost now scrolls a little _slow_. I think the only way to determine
whether this is palatable is to just ship it.

Fixes #6184.

There is going to be a very long tail of applications that will
explicitly request VT SGR 40/37 when what they really want is to
SetConsoleTextAttribute() with a black background/white foreground.
Instead of making those applications look bad (and therefore making us
look bad, because we're releasing this as an update to something that
"looks good" already), we're introducing this compatibility quirk.
Before the color reckoning in #6698 + #6506, *every* color was subject
to being spontaneously and erroneously turned into the default color.
Now, only the 16-color palette value that matches the active console
background/foreground color will be destroyed, and only when received
from specific applications.

Removal will be tracked by #6807.

Michael and I discussed what layer this quirk really belonged in. I
originally believed it would be sufficient to detect a background color
that matched the legacy default background, but @j4james provided an
example of where that wouldn't work out (powershell setting the
foreground color to white/gray). In addition, it was too heavyhanded: it
re-broke black backgrounds for every application.

Michael thought that it should live in the server, as a small VT parser
that righted the wrongs coming directly out of the application. On
further investigation, however, I realized that we'd need to push more
information up into the server (so that it could make the decision about
which VT was wrong and which was right) than should be strictly
necessary.

The host knows which colors are right and wrong, and it gets final say
in what ends up in the buffer.

Because of that, I chose to push the quirk state down through
WriteConsole to DoWriteConsole and toggle state on the
SCREEN_INFORMATION that indicates whether the colors coming out of the
application are to be distrusted. This quirk _only applies to pwsh.exe
and powershell.exe._

NOTE: This doesn't work for PowerShell the .NET Global tool, because it
is run as an assembly through dotnet.exe. I have no opinion on how to
fix this, or whether it is worth fixing.

VALIDATION
----------
I configured my terminals to have an incredibly garish color scheme to
show exactly what's going to happen as a result of this. The _default
terminal background_ is purple or red, and the foreground green. I've
printed out a heap of test colors to see how black interacts with them.

Pull request #6810 contains the images generated from this test.

The only color lines that change are the ones where black as a
background or white as a foreground is selected out of the 16-color
palette explicitly. Reverse video still works fine (because black is in
the foreground!), and it's even possible to represent "black on default"
and reverse it into "default on black", despite the black in question
having been `40`.

Fixes #6767.

This is a refactoring of the renderer color calculations to simplify the
implementation, and to make it easier to support additional
color-altering rendition attributes in the future (e.g. _faint_ and
_conceal_).

## References

* This is a followup to PRs #3817 and #6809, which introduced additional
  complexity in the color calculations, and which suggested the need for
  refactoring. 

## Detailed Description of the Pull Request / Additional comments

When we added support for `DECSCNM`, that required the foreground and
background color lookup methods to be able to return the opposite of
what was requested when the reversed mode was set. That made those
methods unnecessarily complicated, and I thought we could simplify them
considerably just by combining the calculations into a single method
that derived both colors at the same time.

And since both conhost and Windows Terminal needed to perform the same
calculations, it also made sense to move that functionality into the
`TextAttribute` class, where it could easily be shared.

In general this way of doing things is a bit more efficient. However, it
does result in some unnecessary work when only one of the colors is
required, as is the case for the gridline painter. So to make that less
of an issue, I've reordered the gridline code a bit so it at least
avoids looking up the colors when no gridlines are needed.

## Validation Steps Performed

Because of the API changes, quite a lot of the unit tests had to be
updated. For example instead of verifying colors with two separate calls
to `LookupForegroundColor` and `LookupBackgroundColor`, that's now
achieved with a single `LookupAttributeColors` call, comparing against a
pair of values. The specifics of the tests haven't changed though, and
they're all still working as expected.

I've also manually confirmed that the various color sequences and
rendition attributes are rendering correctly with the new refactoring.

This PR adds support for the `DA2` (Secondary Device Attributes) and
`DA3` (Tertiary Device Attributes) escape sequences, which are standard
VT queries reporting basic information about the terminal.

The _Secondary Device Attributes_ response is made up of a number of
parameters:
1. An identification code, for which I've used 0 to indicate that we
   have the capabilities of a VT100 (using code 0 for this is an XTerm
   convention, since technically DA2 would not have been supported by a
   VT100).
2. A firmware revision level, which some terminal emulators use to
   report their actual version number, but I thought it best we just
   hardcode a value of 10 (the DEC convention for 1.0).
3. Additional hardware options, which tend to be device specific, but
   I've followed the convention of the later DEC terminals using 1 to
   indicate the presence of a PC keyboard.

The _Tertiary Device Attributes_ response was originally used to provide
a unique terminal identification code, and which some terminal emulators
use as a way to identify themselves. However, I think that's information
we'd probably prefer not to reveal, so I've followed the more common
practice of returning all zeros for the ID.

In terms of implementation, the only complication was the need to add an
additional code path in the `OutputStateMachine` to handle the `>` and
`=` intermediates (technically private parameter prefixes) that these
sequences require. I've done this as a single method - rather than one
for each prefix - since I think that makes the code easier to follow.

VALIDATION
----------

I've added output engine tests to make sure the sequences are dispatched
correctly, and adapter tests to confirm that they are returning the
responses we expect. I've also manually confirmed that they pass the
_Test of terminal reports_ in Vttest.

Closes #5836

Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows
Terminal as Administrator. This is caused by the app execution alias and
the actual targeted executable not having the same name.

In addition, PowerShell has an issue detecting app execution aliases as
GUI/TUI applications. When you run wt from PowerShell, the shell will
wait for WT to exit before returning to the prompt. Having a shim that
immediately re-executes WindowsTerminal and then returns handily knocks
this issue out (as the process that PS was waiting for exits
immediately.)

This could cause a regression for anybody who tries to capture the PID
of wt.exe. Our process tree is not an API, and we have offered no
consistency guarantee on it.

VALIDATION
----------

Tested manual launch in a number of different scenarios:

* [x] start menu "wtd"
* [x] start menu tile
* [x] powertoys run
* [x] powertoys run ctrl+shift (admin)
* [x] powershell inbox, "core"
* [x] cmd
* [x] run dialog
* [x] run dialog ctrl+shift (admin)
* [x] run from a lnk with window mode=maximized

Fixes #4645 (PowerShell waits for wt)
Fixes #6625 (Can't launch as admin using C-S-enter)

…6890)

This commit updates JsonUtilsNew to support winrt
`Windows::Foundation::IReference<T>` as an option type, and cleans up the
optional support code by removing the optional overload on
`GetValue(...)`. Instead of using an overload with a partial
specialization, we're using a constexpr if with a type trait to
determine option-type-ness.

In addition, Carlos reported an issue with deriving from `FlagMapper`
(itself templated) and referring to the base type's members without
fully qualifying them. To make derivation easier, `EnumMapper` and
`FlagMapper` now provide `BaseEnumMapper` and `BaseFlagMapper` type
aliases.

I've taken the opportunity to add a `winrt::hstring` conversion
trait.

Lastly, in casual use, I found out that I'd written the til::color
converter wrong: it supports color strings of length 7 (`#rrggbb`) and
length 4 (`#rgb`). I mistyped (and failed to test) support for 4-length
color strings by pretending they were only 3 characters long.

## References

Merged JsonUtils changes from #6004 and #6590.

## PR Checklist
* [x] Unblocks aforementioned PRs
* [x] cla
* [x] Tests added/passed
* [x] Documentation N/A
* [x] Schema N/A
* [x] Kid tested, mother approved.

## Summary of the Pull Request

Add support for "focus" mode, which only displays the actual terminal content, no tabs or titlebar. The edges of the window are draggable to resize, but the window can't be moved in borderless mode.

The window looks _slightly_ different bewteen different values for `showTabsInTitlebar`, because switching between the `NonClientIslandWindow` and the `IslandWindow` is _hard_.

`showTabsInTitlebar` | Preview
-- | --
`true` | ![image](https://user-images.githubusercontent.com/18356694/86639069-f5090080-bf9d-11ea-8b29-fb1e479a078d.png)
`false` | ![image](https://user-images.githubusercontent.com/18356694/86639094-fafee180-bf9d-11ea-8fc0-6804234a5113.png)

## PR Checklist
* [x] Closes #2238 
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

* **KNOWN ISSUE**: Upon resizing the NCIW, the top frame margin disappears, making that border disappear entirely. 6356aaf has a bunch of WIP work for me trying to fix that, but I couldn't get it quite right.

## Validation Steps Performed
* Toggled between focus and fullscreen a _bunch_ in both modes.

## Summary of the Pull Request

This PR adds support for the `SGR 2` escape sequence, which enables the
ANSI _faint_ graphic rendition attribute. When a character is output
with this attribute set, it uses a dimmer version of the active
foreground color.

## PR Checklist
* [x] Closes #6703
* [x] CLA signed. 
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #6703

## Detailed Description of the Pull Request / Additional comments

There was already an `ExtendedAttributes::Faint` flag in the
`TextAttribute` class, but I needed to add `SetFaint` and `IsFaint`
methods to access that flag, and update the `SetGraphicsRendition`
methods of the two dispatchers to set the attribute on receipt of the
`SGR 2` sequence. I also had to update the existing `SGR 22` handler to
reset _Faint_ in addition to _Bold_, since they share the same reset
sequence. For that reason, I thought it a good idea to change the name
of the `SGR 22` enum to `NotBoldOrFaint`.

For the purpose of rendering, I've updated the
`TextAttribute::CalculateRgbColors` method to return a dimmer version of
the foreground color when the _Faint_ attribute is set. This is simply
achieved by dividing each color component by two, which produces a
reasonable effect without being too complicated. Note that the _Faint_
effect is applied before _Reverse Video_, so if the output it reversed,
it's the background that will be faint.

The only other complication was the update of the `Xterm256Engine` in
the VT renderer. As mentioned above, _Bold_ and _Faint_ share the same
reset sequence, so to forward that state over conpty we have to go
through a slightly more complicated process than with other attributes.
We first check whether either attribute needs to be turned off to send
the reset sequence, and then check if the individual attributes need to
be turned on again.

## Validation

I've extended the existing SGR unit tests to cover the new attribute in
the `AdapterTest`, the `ScreenBufferTests`, and the `VtRendererTest`,
and added a test to confirm the color calculations  when _Faint_ is set
in the `TextAttributeTests`.

I've also done a bunch of manual testing with all the different VT color
types and confirmed that our output is comparable to most other
terminals.

console: switch to /Zc:wchar_t (native wchar_t)

This matches what we use in OpenConsole and makes {fmt} play nice.

I've also removed the workaround we introduced into OutputCellIterator
to work around not using /Zc:wchar_t.

Fixes MSFT:27626309.
Fixes GH-2673.

Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp 1508f7c232ec58bebc37fedfdec3eb8f9bff5502

#6891)

This parameter was added as a workaround for our fast trackpad
scrolling. Since that was fixed before 1.0 shipped, in #4554, it has
been largely vestigial. There is no reason for us to keep it around any
longer.

It was also the only "logic" in TerminalSettings, which is otherwise a
library that only transits data between two other libraries.

I have not removed it from the schema, as I do not want to mark folks'
settings files invalid to a strict schema parser.

While I was in the area, I added support for "scroll one screen at a
time" (which is represented by the API returning WHEEL_PAGESCROLL),
fixing #5610. We were also storing it in an int (whoops) instead of a
uint.

Fixes #5610

## Summary of the Pull Request

This PR adds support for the `SGR 8` and `SGR 28` escape sequences,
which enable and disable the _concealed/invisible_ graphic rendition
attribute. When a character is output with this attribute set, it is
rendered with the same foreground and background colors, so the text is
essentially invisible.

## PR Checklist
* [x] Closes #6876
* [x] CLA signed. 
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
  where discussion took place: #6876

## Detailed Description of the Pull Request / Additional comments

Most of the framework for this attribute was already implemented, so it
was just a matter of updating the `TextAttribute::CalculateRgbColors`
method to make the foreground the same as the background when the
_Invisible_ flag was set. Note that this has to happen after the
_Reverse Video_ attribute is applied, so if you have white-on-black text
that is reversed and invisible, it should be all white, rather than all
black.

## Validation Steps Performed

There were already existing SGR unit tests covering this attribute in
the `ScreenBufferTests`, and the `VtRendererTest`. But I've added to the
`AdapterTest` which verifies the SGR sequences for setting and resetting
the attribute, and I've extended the `TextAttributeTests` to verify that
the color calculations return the correct values when the attribute is
set.

I've also manually confirmed that we now render the _concealed text_
values correctly in the _ISO 6429_ tests in Vttest. And I've manually
tested the output of _concealed_ when combined with other attributes,
and made sure that we're matching the behaviour of most other terminals.

{fmt} 7.0.1 improves binary size, compile-time format string handling,
compile time improvements and named arguments.

In a test Windows build, it shrank our binary by ~14kb.

Closes #6905.

## PR Checklist
* [x] Closes #6905
* [x] CLA

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Update the Palette to be readable under High Contrast mode

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References
Regressed in #6833

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [X] Closes #6892
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [X] 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: #6892

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
I pulled the styling of the KeyChord text into a Style, so we can give it a different style under High Contrast.  Under HC, I just left all the colors at their default, so ListView can do its thing.  (IMHO, the HC style now looks better than the non-HC mode, but maybe I'm biased ;) )

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
| | Old | New |
|---|:---:|:---:|
| Light | ![light](https://user-images.githubusercontent.com/10259764/87398203-6b8f9a80-c56a-11ea-99d0-2eeefcfea269.png) | ![newlight](https://user-images.githubusercontent.com/10259764/87399212-e3aa9000-c56b-11ea-9e94-c8fae8825cd1.png) |
| Dark | ![dark](https://user-images.githubusercontent.com/10259764/87398269-819d5b00-c56a-11ea-9180-5c6ec1071b95.png) | ![newdark](https://user-images.githubusercontent.com/10259764/87399227-ead19e00-c56b-11ea-996d-ad52bc2dcbf3.png) |
| HC White | ![oldwhite](https://user-images.githubusercontent.com/10259764/87398320-92e66780-c56a-11ea-9d52-e2f6e31ae487.png) | ![newwhite](https://user-images.githubusercontent.com/10259764/87398340-98dc4880-c56a-11ea-87e2-ed257ad89c4a.png) |
| HC Black | ![oldblack](https://user-images.githubusercontent.com/10259764/87398357-9f6ac000-c56a-11ea-848c-1ccef6a65442.png) | ![newblack](https://user-images.githubusercontent.com/10259764/87398370-a396dd80-c56a-11ea-9540-8aa9bb934791.png) |

GSL 3, the next major version of GSL after the one we're using, replaced
their local implementation of `span` with one that more closely mimics
C++20's span. Unfortunately, that is a breaking change for all of GSL's
consumers.

This commit updates our use of span to comply with the new changes in
GSL 3.

Chief among those breaking changes is:

* `span::at` no longer exists; I replaced many instances of `span::at`
  with `gsl::at(x)`
* `span::size_type` has finally given up on `ptrdiff_t` and become
  `size_t` like all other containers

While I was here, I also made the following mechanical replacements:

* In some of our "early standardized" code, we used std::optional's
  `has_value` and `value` back-to-back. Each `value` incurs an
  additional presence test.
  * Change: `x.value().member` -> `x->member` (`optional::operator->`
    skips the presence test)
  * Change: `x.value()` -> `*x` (as above)
* GSL 3 uses `size_t` for `size_type`.
  * Change: `gsl::narrow<size_t>(x.size())` -> `x.size()`
  * Change: `gsl::narrow<ptrdiff_t>(nonSpan.size())` -> `nonSpan.size()`
    during span construction

I also replaced two instances of `x[x.size() - 1]` with `x.back()` and
one instance of a manual array walk (for comparison) with a direct
comparison.

NOTE: Span comparison and `make_span` are not part of the C++20 span
library.

Fixes #6251

This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀 

Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
``` 

instead of 

```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```

The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.

I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form. 

Closes #5466

This PR adds support for always on top mode, via two mechanisms:
* The global setting `alwaysOnTop`. When set to true, the window will be
  created in the "topmost" group of windows.  Changing this value will
  hot-reload whether the window is in the topmost group.
* The action `toggleAlwaysOnTop`, which will toggle the `alwaysOnTop`
  property at runtime.

## Detailed Description of the Pull Request / Additional comments

All "topmost" windows maintain an internal z-ordering relative to one
another, but they're all always above all other "non-topmost" windows.
So multiple Windows Terminal windows which are both `alwaysOnTop` will
maintain a z-order relative to one another, but they'll all be on top of
all other windows.

## Validation Steps Performed

Toggled always on top mode, both in the settings and also at runtime,
and verified that it largely did what I expected.

Closes #3038

This commit adds image assets for High Contrast mode

Tagging this issue so it contains a nice list of all the recent HC
fixes: #5360

I made several changes to DHowett's script and added it to the repo:
* Add support for generating high contrast icons
* Add the ability to easily edit the "intermediate" (previously "zbase")
  files for manual hinting
* Appease the spellchecker

I created new SVGs for HC mode. There's one SVG for both Black and White
modes -- I just invert the colors. Then I manually hinted the generated
bitmaps for the production icons. I didn't bother hinting the Dev/Pre
ones, so the text does get unreadable at small sizes.

View the original images in #6915.

Co-authored-by: Jeffrey Tippet <[email protected]>
Co-authored-by: Dustin L. Howett <[email protected]>
Closes #6822

This results in smaller code and faster copying. I chose til::color even
though it results in slightly worse codegen (byteswapping in a tight
loop) than COLORREF (SSE-enlightened block copy) because eventually the
internal representations of the color tables will also be til::color and
_then_ it will become a block copy.

We were using std::basic_string_view as a stand-in for std::span so that
we could change over all at once when C++20 dropped with full span
support. That day's not here yet, but as of 54a7fce we're using GSL 3,
whose span is C++20-compliant.

This commit replaces every instance of basic_string_view that was not
referring to an actual string with a span of the appropriate type.

I moved the `const` qualifier into span's `T` because while
`basic_string_view.at()` returns `const T&`, `span.at()` returns `T&`
(without the const). I wanted to maintain the invariant that members of
the span were immutable.

* Mechanical Changes
   * `sv.at(x)` -> `gsl::at(sp, x)`
   * `sv.c{begin,end}` -> `sp.{begin,end}` (span's iterators are const)

I had to replace a `std::basic_string<>` with a `std::vector<>` in
ConImeInfo, and I chose to replace a manual array walk in
ScreenInfoUiaProviderBase with a ranged-for. Please review those
specifically.

This will almost certainly cause a code size regression in Windows
because I'm blowing out all the PGO counts. Whoops.

Related: #3956, #975.

The recent changes to use gsl::span everywhere added a few bounds checks
along codepaths where we were already checking bounds. Some of them may
be non-obvious to the optimizer, so we can now use til::at to help them
along.

To accomplish this, I've added a new overload of til::at that takes a
span and directly accesses its backing buffer.

…6751)

## Summary of the Pull Request

This PR adds the `til::spsc` namespace, which implements a lock-free, single-producer, single-consumer FIFO queue ("channel"). The queue efficiently blocks the caller using Futexes if no data can be written to / read from the queue (e.g. using `WaitOnAddress` on Windows). Furthermore it allows batching of data and contains logic to signal the caller if the other side has been dropped/destructed.

## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] 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

`til::spsc::details::arc<T>` contains most of the queue's logic and as such has the relevant documentation for its design.

## Validation Steps Performed

The queue was tested on Windows, Linux and macOS using MSVC, gcc and llvm and each of their available runtime introspection utilities in order to ensure no race conditions or memory leaks occur.

In `Renderer::TriggerRedraw`, the act of fetching the viewport from the
`pData` over and over is wasted time. We already have a cached variable
of the viewport that is updated on every scroll check (on
`TriggerScroll` and on `PaintFrame`.) Scrolling wouldn't be working
correctly if the clients weren't already notifying us that the viewport
has changed for scroll purposes, so we can just keep using that cached
value for the invalidation restriction to speed things up over fetching
it again.

## Validation Steps Performed
- Run `time cat big.txt`. Checked average time before/after, WPR traces
  before/after.

## PR Checklist
* [x] Closes perf itch
* [x] I work here
* [x] Manual test
* [x] Documentation irrelevant.
* [x] Schema irrelevant.
* [x] Am core contributor.

Without this fix, you'd end up with an empty target variable, and so
msbuild would complain and tell you to give it a target.

The command palette is a ListView of commands.  As you type into the
search box, commands are added or removed from the ListView.  Currently,
each update is done by completely clearing the backing list, then adding
back any items that should be displayed.  However, this defeats the
ListView's built-in animations: upon every keystroke, ListView displays
its list-clearing animation, then animates the insertion of every item
that wasn't deleted.  This results in noticeable flickering.

This PR changes the update logic so that it updates the list using
(roughly) the minimum number of Insert and Remove calls, so the ListView
makes smoother transitions as you type.

I implemented it by keeping the existing code that builds the filtered
list, but I changed it to build into a scratch list.  Then I grafted on
a generic delta algorithm to make the real list look like the scratch
list.

To verify the delta algorithm, I tested all 360,000 permutations of
pairs of up to 5 element lists in a toy C# app.

## Validation
I'm not sure if my screen capture tool really caught all the flickering
here, but the screencasts below should give a rough idea of the
difference.  (All the flickering was becoming a nuisance while I was
testing out the HC changes.)

See the images in #6939 for more info.

Co-authored-by: Jeffrey Tippet <[email protected]>

After we stood up our own NuGet feed in Azure blob storage, Azure DevOps
came out with a public artifact feed feature. I've migrated all our
packages over, and the only thing left to do is switch our project's
NuGet config to use it.

Fixes #6952

…6590)

This pull request converts the following JSON deserializers to use the
new JSON deserializer pattern:

* Profile
* Command
* ColorScheme
* Action/Args
* GlobalSettings
* CascadiaSettingsSerialization

This is the completion of a long-term JSON refactoring that makes our
parser and deserializer more type-safe and robust. We're finally able to
get rid of all our manual enum conversion code and unify JSON conversion
around _types_ instead of around _keys_.

I've introduced another file filled with template specializations,
TerminalSettingsSerializationHelpers.h, which comprises a single unit
that holds all of the JSON deserializers (and eventually serializers)
for every type that comes from TerminalApp or TerminalSettings.

I've also moved some types out of Profile and GlobalAppSettings into a
new SettingsTypes.h to improve settings locality.

This does to some extent constitute a breaking change for already-broken
settings. Instead of parsing "successfully" (where invalid values are
null or 0 or unknown or unset), deserialization will now fail when
there's a type mismatch. Because of that, some tests had to be removed.

While I was on a refactoring spree, I removed a number of helpless
helpers, like GetWstringFromJson (which converted a u8 string to an
hstring to make a wstring out of its data pointer :|) and
_ConvertJsonToBool.

In the future, we can make the error types more robust and give them
position and type information such that a conformant application can
display rich error information ("line 3 column 3, I expected a string,
you gave me an integer").

Closes #2550.

## Summary of the Pull Request

Text can have various attributes, such as "bold", "italic", "underlined", etc.  The TextAttribute class embodies this. It has methods to set/query these attributes.

This change tweaks a few of the method names to make them match. I.e. for an imaginary text property "Foo", we should have methods along the lines of:

```
IsFoo
SetFoo(bool isFoo)
```

And variations should match: we should have "Foo" and "OverFoo", not "Fooey" and "OverFoo".

I chose to standardize on the adjective form, since that's what we are closest to already. The attributes I attacked here are:

SetItalic**s** --> SetItalic
SetUnderline --> SetUnderline**d**
SetOverline --> SetOverline**d**

("italic" is an adjective; "italics" is a plural noun, representing letters or words in an italic typeface)

And I also added methods for "DoublyUnderlined" for good measure.

I stopped short of renaming the GraphicsOptions enum values to match, too; but I'd be willing to do that in a follow-up change if people wanted it.

## Validation Steps Performed
It builds, and tests still pass.

By default, the memory order on atomics is `seq_cst`. This is a relatively expensive ordering and it shows in situations where we're rapidly signaling a consumer to pick up something from a producer. I've instead attempted to switch these to `release` (producer) and `acquire` (consumer) to improve the performance of these signals. 

## Validation Steps Performed
- Run `time cat big.txt` and `time cat ls.txt` under VS Performance Profiler. 

## PR Checklist
* [x] Closes perf itch
* [x] I work here
* [x] Manual test
* [x] Documentation irrelevant.
* [x] Schema irrelevant.
* [x] Am core contributor.

…6919)

The act of calling `InsertAttrRuns` is relatively slow. Instead of
calling it a bunch of times to meddle with colors one cell at a time,
we'll accumulate a length of color and call it to make it act all at
once. This is great for when one color full line is getting replaced
with another color full line OR when a line is being replaced with the
same color all at once. There's significantly fewer checks to be made
inside `InsertAttrRuns` if we can help it out by accumulating the length
of each color before asking it to stitch it into the storage.

Validation
----------

- Run `time cat big.txt` and `time cat ls.txt` under VS Performance
  Profiler.

)

The command palette has some content that can overlap with its
scrollbar.  This PR adds a 16px gutter for the scrollbar, as recommended
[here](https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/scroll-controls#:~:text=leave%2016px%20of%20padding%20on%20the%20edge%20of%20the%20viewport).

## Detailed Description of the Pull Request / Additional comments
You can repro the overlap in the default configuration by grabbing the
scrollbar with the mouse pointer.  But there's an accessibility option
that makes this more obvious: Settings > Display > Automatically hide
scroll bars.  With that option enabled, the text is _always_
overlapping.

The gutter does look slightly larger than it needs to be when the
scrollbar is thin or completely hidden.  Dynamic reflow may help, but
unfortunately, I don't know enough XAML to wire that up.  MUX has a
promising visual state named `ScrollBarsSeparatorExpanded`, so the
scientists suggest we _could_, while the designers are still pondering
whether we _should_.

## Validation Steps Performed

Old appearance:
![image](https://user-images.githubusercontent.com/10259764/87817879-94d85100-c81e-11ea-956c-ca0e23576fef.png)

New appearance with fat scrollbars:
![image](https://user-images.githubusercontent.com/10259764/87817914-a4579a00-c81e-11ea-9e9d-195969e6da95.png)

New appearance with thin scrollbars:
![image](https://user-images.githubusercontent.com/10259764/87818061-dff26400-c81e-11ea-866e-088f72276343.png)

New appearance with no scrollbar:
![image](https://user-images.githubusercontent.com/10259764/87819674-7758b680-c821-11ea-98b7-dddd1573c242.png)

… of height (#6922)

We spend a lot of time invalidating in the DX Renderer. This is a
creative trick to not bother invalidating any further if we can tell
that the bitmap is already completely invalidated. That is, if we've
scrolled at least an entire screen in height... then the entire bitmap
had to have been marked as invalid as the new areas were "uncovered" by
the `InvalidateScroll` command. So further setting invalid bits on top
of a fully invalid map is pointless. 

Note: I didn't use `bitmap::all()` here because it is significantly
slower to check all the bits than it is to just reason out that the
bitmap was already fully marked.

## Validation Steps Performed
- Run `time cat big.txt`. Checked average time before/after, WPR traces
  before/after.

…A KEYBINDING (#6537)

## Summary of the Pull Request

Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_. 

## References

* Related to #4472 
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970

## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does

## Detailed Description of the Pull Request / Additional comments

One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again. 

We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.

This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out. 

This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.

## Validation Steps Performed

This was what the json blob I was using for testing evolved into

```json
        {
            "command": {
                "action":"wt",
                "commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",

            },
            "keys": ["ctrl+shift+n"]
        }
```

I also added some tests.

# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
  - Probably should just do nothing for the empty string

Original notes from @M-Pixel:

> Console applications assume that backgrounds are black, and that
> `lightBlack`/`DarkGrey` are lighter than `black`/`Black`.  This
> assumption is accounted for by all color schemes in `defaults.json`,
> except for the Solarized themes.
> 
> The Solarized Dark theme, in particular, makes `-Parameters` invisible
> against the background in PowerShell, which is obviously an unacceptable
> usability flaw.
> 
> This change makes `black` and `background` to the same (which is common
> throughout the color schemes), and makes `brightBlack` (`DarkGray` in
> .NET) lighter than black (which is obviously more correct given the
> meanings of those words).

Out of the box, we ship a pretty bad behavior.

If I look at all of the existing shipped color schemes--and that
includes things like Tango and One Half--we are universally following a
`background` == `black` rule.

If I consult gnome-terminal or xterm, they do the same thing; Xterm by
default, gnome-terminal for solarized. The background generally matches
color index `0` across all their **dark** schemes. Konsole and
lxterminal disagree and map background to `0 intense` for Solarized.

I want to put our Solarized schemes on a deprecation path, but
unfortunately we still need to ship _something_ for users who we're
going to strand on them.

I'm going to have to swallow my bitter and say that yes, we should
probably just change the index mapping and go with something that works
right out of the box while we figure out how to do perceptual color
nudging and eventually remove bad defaults (like Solarized).

From #6618.

Fixes #4047.
Closes #6618.

In UiaTextRange, `_getBufferSize` returns an optimized version of the
size of the buffer to be the origin and the last character in the
buffer. This is to improve performance on search or checking if you are
currently on the last word/line.

When setting the endpoint and drawing the bounding rectangles, we should
be retrieving the true buffer size. This is because it is still possible
to create UiaTextRanges that are outside of this optimized size. The
main source of this is `ExpandToEnclosingUnit()` when the unit is
`Document`. The end _should_ be the last visible character, but it isn't
because that would break our tests.

This is an incomplete solution. #6986 is a follow up to completely test
and implement the solution.

The crash in #6402 was caused by getting the document range (a range of
the full text buffer),  then moving the end by one character. When we
get the document range, we get the optimized size of the buffer (the
position of the last character). Moving by one character is valid
because the buffer still has more to explore. We then crash from
checking if the new position is valid on the **optimized size**, not the
**real size**.

REFERENCES

#6986 - follow up to properly handle/test this "end of buffer" problem

Closes #6402

* send alt/F10 through the control
  We were not listening for WM_SYSKEY{UP,DOWN}
* extract the actual scancode during WM_CHAR, not the bitfield
  We were accidentally sending some of the additional keypress data in with
  the character event in Win32 Input Mode
* set default fg/bg to campbell
  The WPF control starts up in PowerShell blue even though it's not typically used
  in PowerShell blue.
* don't rely on the font to determine wideness
  This is a cross-port of #2928 to the WPF control
* deterministic shutdown
  In testing, I saw a handful of crashes on teardown because we were not shutting
  down the render thread properly.
* don't pass 10 for the font weight ...
  When Cascadia Code is set, it just looks silly.
* trigger render when selection is cleared, do it under lock

Fixes #6966.

[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/200720-1445 into official/rs_onecore_dep_uxp
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp 5e1509a00f1acdefe1e6392468ffc9ae44dc89cb

Related work items: MSFT:25731998

- Move to GSL 3.1.0 (GH-6908)
- Replace the color table init code with two const arrays (GH-6913)
- Replace basic_string_view<T> with span<const T> (GH-6921)
- Replace gsl::at with a new til::at(span) for pre-checked bounds (GH-6925)

Related work items: MSFT:27866336

We've been trying to improve the copy/paste experience with the terminal
in Visual Studio. Once of our problematic scenarios is when the terminal
is connected to a remote environment and the user attempts to
copy/paste. This gets forwarded to the remote shell that copy/paste into
the remote clipboard instead of the local one. 

So we opted to add ctrl+shift+c/v to the terminal and need access to the
selected text via the terminal control

VALIDATION
Tested with Visual Studio integrated terminal

* Fixed window title not updating with tab rename

* pass the correct title to event handler instead

This was never hooked up to the TerminalCore implementation.

Closes #7102

This is a refactoring of the grid line renderers, adjusting the line
widths to scale with the font size, and optimising the implementation to
cut down on the number of draw calls. It also extends the supported grid
line types to include true underlines and strike-through lines in the
style of the active font.

The main gist of the optimisation was to render the horizontal lines
with a single draw call, instead of a loop with lots of little strokes
joined together. In the case of the vertical lines, which still needed
to be handled in a loop, I've tried to move the majority of static
calculations outside the loop, so there is bit of optimisation there
too.

At the same time this code was updated to support a variable stroke
width for the lines, instead of having them hardcoded to 1 pixel. The
width is now calculated as a fraction of the font size (0.025 "em"),
which is still going to be 1 pixel wide in most typical usage, but will
scale up appropriately if you zoom in far enough.

And in preparation for supporting the SGR strike-through attribute, and
true underlines, I've extended the grid line renders with options for
handling those line types as well. The offset and thickness of the lines
is obtained from the font metrics (rounded to a pixel width, with a
minimum of one pixel), so they match the style of the font.

VALIDATION

For now we're still only rendering grid lines, and only the top and
bottom lines in the case of the DirectX renderer in Windows Terminal. So
to test, I hacked in some code to force the renderer to use all the
different options, confirming that they were working in both the GDI and
DirectX renderers.

I've tested the output with a number of different fonts, comparing it
with the same text rendered in WordPad. For the most part they match
exactly, but there can be slight differences when we adjust the font
size for grid alignment. And in the case of the GDI renderer, where
we're working with pixel heights rather than points, it's difficult to
match the sizes exactly.

This is a first step towards supporting the strike-through attribute
(#6205) and true underlines (#2915).

Closes #6911

Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp 29b1a1d663d0047dc0d2125dd05f75959bca27ef

Related work items: MSFT:27866336

Reverts "Merged PR 4670666: Workaround for LKG10 internal linker error"

Related work items: MSFT:25439646, MSFT:26598503

Allows splitting pane (with default settings) by holding down ALT and pressing the new tab button ('+')

## PR Checklist
* [X] Closes #6757 
* [X] Works here.
* [X] Manual test (below)
* [X] Is core contributor. 

## More detailed description

Pretty much exactly the code added in #5928 (all credit to @carlos-zamora), but put at the new tab button event binding

## Validation steps

Seems to work - holding ALT while pressing '+' opens a pane instead of a tab. Holding ALT while starting up terminal for the first time does not seem to affect the behaviour.

When we added support for win32 input mode, we neglected to pass
`ENHANCED_KEY` through the two surfaces that would generate events. This
broke arrow keys in much the same way was #2397, but in a different
layer.

While I was working on the WPF control, I took a moment to refactor the
message cracking out into a helper. It's a lot easier on the eyes than
four lines of bit shifting repeated three times.

Fixes #7074

This PR adds support for the ANSI _crossed-out_ graphic rendition
attribute, which is enabled by the `SGR 9` escape sequence.

* Support for the escape sequences and storage of the attribute was
  originally added in #2917.
* Support for drawing the strikethrough effect in the grid line renderer
  was added in #7107.

Since the majority of the code required for this attribute had already
been implemented, it was just a matter of activating the
`GridLines::Strikethrough` style in the `Renderer::s_GetGridlines`
method when the `CrossedOut` attribute was set.

VALIDATION

There were already some unit tests in place in `VtRendererTest` and the
`ScreenBufferTests`, but I've also now extended the SGR tests in
`AdapterTest` to cover this attribute.

I've manually confirmed the first test case from #6205 now works as
expected in both conhost and Terminal.

Closes #6205

This PR updates the rendering of the _underlined_ graphic rendition
attribute, using the style specified in the active font, instead of just
reusing the grid line at the bottom of the character cell.

* Support for drawing the correct underline effect in the grid line
  renderer was added in #7107.

There was already an `ExtendedAttributes` flag defined for the
underlined state, but I needed to update the `SetUnderlined` and
`IsUnderlined` methods in the `TextAttribute`  class to use that flag
now in place of the legacy `LVB_UNDERSCORE` attribute. This enables
underlines set via a VT sequence to be tracked separately from
`LVB_UNDERSCORE` grid lines set via the console API.

I then needed to update the `Renderer::s_GetGridlines` method to
activate the `GridLines::Underline` style when the `Underlined`
attribute was set. The `GridLines::Bottom` style is still triggered by
the `LVB_UNDERSCORE` attribute to produce the bottom grid line effect.

Validation
----------

Because this is a change from the existing behaviour, certain unit tests
that were expecting the `LVB_UNDERSCORE` to be toggled by `SGR 4` and
`SGR 24` have now had to be updated to check the `Underlined` flag
instead.

There were also some UI Automation tests that were checking for `SGR 4`
mapping to `LVB_UNDERSCORE` attribute, which I've now substituted with a
test of the `SGR 53` overline attribute mapping to
`LVB_GRID_HORIZONTAL`. These tests only work with legacy attributes, so
they can't access the extended underline state, and I thought a
replacement test that covered similar ground would be better than
dropping the tests altogether.

As far as the visual rendering is concerned, I've manually confirmed
that the VT underline sequences now draw the underline in the correct
position and style, while grid lines output via the console API are
still displayed in their original form.

Closes #2915

Co-authored-by: Mike Griese <[email protected]>

## Summary of the Pull Request

This spec is a subset of #5772, but specific to per-profile tab colors. We've had enough requests for that in the last few days that I want to pull that feature out into it's own spec, so we can get that approved and implemented in a future-proof way.

> This spec describes a way to specify tab colors in a profile in a way that will
> be forward compatible with theming the Terminal. This spec will be largely
> dedicated to the design of a single setting, but within the context of theming.
> 

## PR Checklist
* [x] Specs: #1337
* [x] References: #5772 
* [x] I work here

## Detailed Description of the Pull Request / Additional comments
_\*<sup>\*</sup><sub>\*</sub> read the spec  <sub>\*</sub><sup>\*</sup>\*_

…mdpal

Updates TAEF to 10.57.200731005-develop

## PR Checklist
* [x] Helps #6992 by bringing `wttlog.dll` along with the rest of TAEF.
* [x] I work here.
* [x] Automated tests in CI
* [x] No doc/schema update necessary (checked for docs in this repo)
* [x] Am core contributor.

…mdpal (#7165)

Add some user research to determine what the average number of characters a user types before executing a cmdpal action.

This might need to be modified when it merges with #6732

Move TerminalSettings object from TerminalSettings project
(Microsoft.Terminal.Settings) to TerminalApp project. `TerminalSettings`
specifically operates as a bridge that exposes any necessary information
to a TerminalControl.

Closes #7139 
Related Epic: #885
Related Spec: #6904

## PR Checklist
* [X] Closes #7139 
* [X] CLA signed
* [X] Tests ~added~/passed (no additional tests necessary)
* [X] ~Documentation updated~
* [X] ~Schema updated~

## Validation Steps Performed
Deployed Windows Terminal and opened a few new tabs.

This pull request fixes capture and event generation in VT mouse mode
for both conhost and terminal.

Fixes #6401.

[1/3] Terminal: clamp mouse events to the viewport, don't throw them away

 gnome-terminal (at least) sends mouse events whose x/y are at the
 extreme ends of the buffer when a drag starts inside the terminal and
 then exits it.

 We would previously discard any mouse events that exited the borders of
 the viewport. Now we will keep emitting events where X/Y=0/w/h.

[2/3] conhost: clamp VT mouse to viewport, capture pointer

 This is the same as (1), but for conhost. conhost wasn't already
 capturing the pointer when VT mouse mode was in use. By capturing, we
 ensure that events that happen outside the screen still result in events
 sent to an application (like a release after a drag)

[3/3] wpf: capture the pointer when VT mouse is enabled

 This is the same as (2), but for the WPF control. Clamping is handled
 in TerminalCore in (1), so we didn't need to do it in WPF.

I found this while crawling through conhost's WindowIo. Mouse wheel
events come in in screen coordinates, unlike literally every other mouse
event.

The WPF control was doing it wrong.

Carlos Zamora (1)
* UIA: use full buffer comparison in rects and endpoint setter (GH-6447)

Dan Thompson (2)
* Tweaks: normalize TextAttribute method names (adjective form) (GH-6951)
* Fix 'bcz exclusive' typo (GH-6938)

Dustin L. Howett (4)
* Fix VT mouse capture issues in Terminal and conhost (GH-7166)
* version: bump to 1.3 on master
* Update Cascadia Code to 2007.15 (GH-6958)
* Move to the TerminalDependencies NuGet feed (GH-6954)

James Holderness (3)
* Render the SGR "underlined" attribute in the style of the font (CC-7148)
* Add support for the "crossed-out" graphic rendition attribute (CC-7143)
* Refactor grid line renderers with support for more line types (CC-7107)

Leonard Hecker (1)
* Added til::spsc, a lock-free, single-producer/-consumer FIFO queue (CC-6751)

Michael Niksa (6)
* Update TAEF to 10.57.200731005-develop (GH-7164)
* Skip DX invalidation if we've already scrolled an entire screen worth of height (GH-6922)
* Commit attr runs less frequently by accumulating length of color run (GH-6919)
* Set memory order on slow atomics (GH-6920)
* Cache the viewport to make invalidation faster (GH-6918)
* Correct comment in this SPSC test as a quick follow up to merge.

Related work items: MSFT-28208358

Up until #4999 we deferred all key events to the character event handler
for which `ToUnicodeEx` returned a valid character and alternatively
those who aren't a special key combination as listed in
`TerminalInput`'s implementation.

Since #4999 we started acknowledging/handling all key events no matter
whether they're actually a known key combination. Given non-ASCII inputs
the Win32 `SendInput()` method generates certain sequences that aren't
recognizable combinations though and if they're handled by the key event
handler no follow up character event is sent containing the unicode
character.

This PR adds another condition and defers all key events without scan
code (i.e. those not representable by the current keyboard layout) to
the character event handler.

I'm absolutely not certain that this PR doesn't have a negative effect
on other kinds of inputs.

Is it common for key events to not contain a scan code? I personally
haven't seen it happen before AutoHotKey/SendInput.

Before this PR is merged it'd be nice to have a good testing plan in
place in order to ensure nothing breaks.

## Validation Steps Performed

Remapped `AltGr+8` to `»` using AutoHotKey using `<^>!8::SendInput {Raw}»`.
Ensured `»` is printed if `AltGr+8` is pressed.

Closes #7064
Closes #7120

I've typed this up way too many times now. I'm sticking this comment in Niksa.md, and if it's ever an insufficient explanation of the differences, we can elaborate.

## Summary of the Pull Request

Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter.

* `closeOtherTabs`: Close tabs other than `index`
* `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right")

## References
* This PR is being made to unblock @RahulRavishankar in #1912
## PR Checklist
* [x] I work here
* [ ] Tests added/passed
* [x] Requires documentation to be updated
* [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action
* [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided

## Validation Steps Performed
* _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_
* _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_
* _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_
* _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_
    - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.

This fixes the build the rest of the way in VS 16.7. Something about the
way we were using the Store/Container flags caused some of our projects
to end up linking kernel32.lib only (MinimalCoreWin==KernelOnly).
The best way to solve it once and for all is to make sure MinimalCoreWin
is always set.

References 313568d.

## Summary of the Pull Request
Move `ICoreSettings` and `IControlSettings` from the TerminalSettings project to the TerminalCore and TerminalControl projects respectively. Also entirely removes the TerminalSettings project.

The purpose of these interfaces is unchanged. `ICoreSettings` is used to instantiate a terminal. `IControlSettings` (which requires an `ICoreSettings`) is used to instantiate a UWP terminal control.

## References
Closes #7140 
Related Epic: #885 
Related Spec: #6904 

## PR Checklist
* [X] Closes #7140 
* [X] CLA signed
* [X] Tests ~added~/passed (no additional tests necessary)
* [X] ~Documentation updated~
* [X] ~Schema updated~

## Detailed Description of the Pull Request / Additional comments
A lot of the work here was having to deal with winmd files across all of these projects. The TerminalCore project now outputs a Microsoft.Terminal.TerminalControl.winmd. Some magic happens in TerminalControl.vcxproj to get this to work properly.

## Validation Steps Performed
Deployed Windows Terminal and opened a few new tabs.

Consecutive RTL GlyphRuns are drawn from the last to the first.

References
#538, #7149, all those issues asking for RTL closed as dupes.

As @miniksa suggested in a comment on #7149 -- handle the thingy on the
render side.

If we have GlyphRuns abcdEFGh, where EFG are RTL, we draw them now in
order abcdGFEh.

This has ransom-noting, because I didn't touch the font scaling at all.
This should fix the majority of RTL issues, except it *doesn't* fix
issues with colors, because those get split in the TextBuffer phase in
the renderer I think, so they show up separately by the GlyphRun phase.

This PR adds support for per-profile tab colors, in accordance with
#7134. This adds a single `tabColor` property, that when set, specifies
the background color for profile's tab. This color can be overridden by
the color picker, and clearing the color with the color picker will
revert to this default color set for the tab.

* Full theming is covered in #3327 & #5772 

Validation: Played with setting this color, both on launch and via
hot-reload

Specified in #7134
Closes #1337

This PR adds the `togglePaneZoom` action, which can be used to make a
pane expand to fill the entire contents of the window.  A tab that
contains a zoomed pane will have a magnifying glass icon prepended
to its title. Any attempts to manage panes with one zoomed will force
the zoomed pane back to normal size.

VALIDATION
Zoomed in and out a bunch. Tried closing panes while zoomed. Tried
splitting panes while zoomed. Etc.

Closes #996

MouseInput was directly asking user32 about the state of the mouse buttons,
which was somewhat of a layering violation. This commit makes all callers
have to pass the mouse state in themselves.

Closes #4869