FontInfoBase and it's descendents are missing noexcept annotations, which
virally forces other code to not be noexcept as well during AuditMode checks.
Apart from adding noexcept, this commit also
* Passes std::wstring_view by reference.
* Pass the FillLegacyNameBuffer argument as a simple pointer-to-array,
allowing us to fill the buffer with a single memcpy.
(gsl::span's iterators inhibit any internal STL optimizations.)
* Move operator== declarations inside the class to reduce code size.
All other changes are an effect of the virality of noexcept.
This is an offshoot from #11623.
## Validation Steps Performed
* It still compiles ✔️
`SRWLOCK`, as used by `std::shared_mutex`, is a inherently unfair mutex
and makes no guarantee whatsoever whether a thread may acquire the lock
in a timely manner. This is problematic for our renderer which relies on
being able to acquire the lock in a timely and predictable manner.
Drawing stalls of up to one minute have been observed in tests.
This issue can be solved with a primitive ticket lock, which is 10x
slower than a `SRWLOCK` but still sufficiently fast for our use case
(10M locks per second per thread). It's likely that any non-trivial lock
duration will diminish the difference to "negligible".
## Validation Steps Performed
* It still blends ✔️
The CursorStyle enum is declared as being of type `uint` on the C# side,
but as `size_t` on the C++ side. There's a C# size_t impostor we could
use, System.UIntPtr, but I don't want to risk changing the public API of
TerminalTheme and I don't know if it can be used as a base type for an
enum.
Anyway, since we don't have more than four billion cursor types I chose
to narrow the field to a uint32_t and unpack it in TerminalSetTheme.
Fixes#10485
Adds the ability to manually handle the terminal renderer resizing
events by allowing different render size and WPF control size. This is
done by adding an `AutoFill` property to the control that prevents the
renderer from automatically resizing and tells the WPF control to fill
in the extra space with the terminal background as shown below:
This PR adds the following:
- Helper method in the DX engine to convert character viewports into
pixel viewports
- `AutoFill` property that prevents automatic resizing of the renderer
- Tweaks and fixes that automatically fill in the empty space if
`AutoFill` is set to false
- Fixes resizing methods and streamlines their codepath
## Validation Steps Performed
Manual validation with the Visual Studio Integrated Terminal tool
window.
Adds the ability to set the selection background opacity when setting the
selection background. This also exposes the selection background and alpha
through the terminal WPF container.
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
* 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.
Adds support for `win32-input-mode` to conhost, conpty, and the Windows
Terminal.
* The shared `terminalInput` class supports sending these sequences when
a VT client application requests this mode.
* ConPTY supports synthesizing `INPUT_RECORD`s from the input sent to it
from a terminal
* ConPTY requests this mode immediately on startup (if started with a
new flag, `PSEUDOCONSOLE_WIN32_INPUT_MODE`)
* The Terminal now supports sending this input as well, when conpty asks
for it.
Also adds a new ConPTY flag `PSEUDOCONSOLE_WIN32_INPUT_MODE` which
requests this functionality from conpty, and the Terminal requests this
by default.
Also adds `experimental.input.forceVT` as a global setting to let a user
opt-out of this behavior, if they don't want it / this ends up breaking
horribly.
## Validation Steps Performed
* played with this mode in vtpipeterm
* played with this mode in Terminal
* checked a bunch of scenarios, as outlined in a [comment] on #4999
[comment]: https://github.com/microsoft/terminal/issues/4999#issuecomment-628718631
References #4999: The megathread
References #5887: The spec
Closes#879Closes#2865Closes#530Closes#3079Closes#1119Closes#1694Closes#3608Closes#4334Closes#4446
Selection would act up when you were using shift to ignore VT mouse
mode: we would get hundreds of WM_KEYDOWN for VK_SHIFT and dismiss the
selection every time.
I took the opportunity to move the actual responsibility for key event
dispatch into HwndTerminal. In the future, I'd like to make more of the
TerminalXxx calls just call impl methods on HwndTerminal.
## Summary of the Pull Request
This pull request ports the VT mouse code from TermControl to WpfTerminalControl. Our WPF control is a lot closer to Win32 than to Xaml, so our mouse event handler looks _nothing_ like the one that we got from Xaml. We can pass events through almost directly, because the window message handling in the mouse input code actually came from _conhost_. It's awesome.
Neither TermControl nor conhost pass hover events through when the control isn't focused, so I wired up focus events to make sure we acted the same.
Just like Terminal and conhost, mouse events are suppressed when <kbd>Shift</kbd> is held.
## Validation Steps Performed
Tested with MC, and tested by manually engaging SGR events in an Echo terminal.
## Summary of the Pull Request
This pull request ports #5096 to WpfTerminalControl, bringing it in line with the selection mechanics in Terminal. It also introduces double- and triple-click selection and makes sure we clear the selection when we resize.
Please read #5096 for more details.
## Detailed Description of the Pull Request / Additional comments
This code is, largely, copy-and-pasted from TermControl with some updates to use `std::chrono` and `til::point`. I love `til::point`. A lot.
## Validation Steps Performed
Lots of manual selection.
My basic idea was that `WM_CHAR` is just the better `WM_KEYDOWN`.
The latter fails to properly support common dead key sequences like in
#3516.
As such I added some logic to `Terminal::SendKeyEvent` to make it return
false if the pressed key represents a printable character.
This causes us to receive a character event with a (hopefully) correctly
composed code unit, which then gets sent to `Terminal::SendCharEvent`.
`Terminal::SendCharEvent` in turn had to be modified to support
potentially pressed modifier keys, since `Terminal::SendKeyEvent` isn't
doing that for us anymore.
Lastly `TerminalInput` had to be modified heavily to support character
events with modifier key states. In order to do so I merged its
`HandleKey` and `HandleChar` methods into a single one, that now handles
both cases.
Since key events will now contain character data and character events
key codes the decision logic in `TerminalInput::HandleKey` had to be
rewritten.
## PR Checklist
* [x] CLA signed
* [x] Tests added/passed
* [x] I've discussed this with core contributors already.
## Validation Steps Performed
* See #3516.
* I don't have any keyboard that generates surrogate characters. Due to
this I modified `TermControl::_SendPastedTextToConnection` to send the
data to `_terminal->SendCharEvent()` instead. I then pasted the test
string ""𐐌𐐜𐐬" and ensured that the new `TerminalInput::_SendChar`
method still correctly assembles surrogate pairs.
Closes#3516Closes#3554 (obsoleted by this PR)
Potentially impacts #391, which sounds like a duplicate of #3516
PR #4548 inadvertantly broke mouse button input in the WPF control. This happened due to the extra layer of HWND indirection. The fix is to move the mouse button handling down into the native control where the window messages are now being sent.
This PR hooks up the existing UIA implementation to the WPF control. Some existing code that was specific to the UWP terminal control could be shared so that has been refactored to a common location as well.
## Validation Steps Performed
WPF control was brought up in UISpy and the UIA tree was verified. NVDA was then used to check that screen readers were operating properly.
This adds the WPF control to our project, courtesy of the Visual Studio team.
It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
