## 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.
## Summary of the Pull Request
This is 100% on me. Even after mucking around in this function for the last 3
months, I missed that there was a single addition where we weren't doing a
clamped addition. This would lead to us creating a buffer with negative height,
and all sorts of badness.
Clamping this addition was enough to fix the bug.
## PR Checklist
* [x] Closes#2815
* [x] Closes#4972
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* ran tests
* Created a profile with `"historySize" : 32728`, then filled the viewport with
text, then maximized, and saw that the viewport indeed did resize to the new
size of the window.
Double/Triple click create a selection expanding beyond one cell. This PR makes it so that when you're dragging your mouse to expand the selection, you expand to the next delimiter defined by double/triple click.
So, double click expands by doubleClickDelimiter ranges. Triple click expands by line.
When you double/triple click, a word/line is selected. When you drag, that word/line will remain selected after the expansion occurs.
Closes#1933
## Details
Rather than resizing the selection when the mouse event occurs, I figured I'd do what I did with wide glyph selection: expand at render time.
We needed an enum `multiClickSelectionMode` to keep track of which expansion mode we're in.
Minor modifications to `_ExpandDoubleClickSelection*(COORD)` had to be made so that we can re-use them.
Actual expansion occurs in `_GetSelectionRects()`
## Validation Steps Performed
- generic double click test
- `dir` or `ls`
- double click a word
- drag up
- Works! ✔
- double click on delimiter test
- `dir` or `ls`
- double click a word delimiter (i.e.: space between words)
- drag up
- Works! ✔
- generic triple click test
- `dir` or `ls`
- triple click a line
- drag up
- Works! ✔
- ALT + double click test
- `dir` or `ls`
- hold ALT
- double click a word
- drag up
- Works! ✔
repeat above tests in following scenarios:
- when at top of scrollback
- drag down instead of up
* fix for historySize=32767 hang (except for historySize=0 case); tests still in progress
* tests run and almost pass - failure is a real bug in my change
* fixed bug that caused tests to fail, but it seems another bug causes the app to crash with a zero row count
* fix the additional bug (at a higher layer) mentioned in previous commit description
* Fix chk build assertion failures in new tests
It seems C++/WinRT doesn't like it when you implement a Windows Runtime
interface but then create instances of the implementing class
with function-call lifetime (aka stack allocation). That makes sense
given that WinRT objects are COM objects, but in my defense I was following
this example where they are just fine instantiating the `App` object
on the stack:
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-apis#if-youre-not-authoring-a-runtime-class
* tabs to spaces
* CR feedback
* fix minor CR feedback (incorrect test log message)
