This adds an indirection for `_KeyHandler` so that `OnDirectKeyEvent`
can call `_KeyHandler`. This allows us to consistently handle
Alt-key-up events. Then I added custom handling for Alt+ddd (OEM),
Alt+0ddd (ANSI), and Alt+'+'+xxxx (Unicode) sequences, due to the
absence of Alt-key events with xaml islands and our TSF control.
Closes#17327
## Validation Steps Performed
* Tested it according to https://conemu.github.io/en/AltNumpad.html
* Unbind Alt+Space
* Run `showkey -a`
* Alt+Space generates `^[ `
* F7 generates `^[[18~`
## Summary of the Pull Request
Adds a scroll offset to avoid hiding the current search highlight with
the search box.
- Offset is based on the number of rows that the search box takes up.
(I am not totally sure I am calculating this right)
- This won't help when the current highlight is in the first couple
rows of the buffer.
Fixes: #4407
* Added/changed comments as mentioned.
* Improved the ugly `resize_and_overwrite` hack into the STL.
* Add `Write` functions for xterm's window API.
* The only reason we needed a move operator for `VtIo::Writer`
is because we used it in a ternary in `CONSOLE_INFORMATION`.
Ternaries are like if branches with hidden move assignments.
Instead, we simply construct each `Writer` in place.
No ternary = No move = No problems in life.
The best benefit of this is that this makes calling `GetVtWriter`
a hundred times cheaper.
Otherwise, I still need to extend a few tests in `VtIoTests`,
but I'm planning to do that later.
* Every single place that called `read_file_as_utf8_string_if_exists`
would immediately do a `.value_or(std::string{})`.
As such, the function now returns a string directly.
* There was just one caller to `read_file_as_utf8_string`
and it only cared about files that are non-empty.
As such, the specialization got removed.
Both of these make sense to me, as in practice there's seldom
a difference between an empty file and a non-existent one.
## Validation Steps Performed
* Compiles ✅
* Starts ✅
* Deleting the `settings.json` contents triggers a reload ✅
BackendD2D will now draw one extra cell on all sides when rendering the
background, filled with the expected background color, starting at (-1,
-1) to ensure that cell backgrounds do not bleed over the edges of the
viewport where the is swapchain but no content.
Fixes#17672
Roughly 4 years ago we gave Windows Terminal the ability to
differentiate between black/white and the default colors.
One of the victims was PowerShell and most importantly PSReadLine,
which emit SRG 37 & 40 when what they really want is 38 & 48.
We fixed this on our side by adding a shim.
Since the addition of VT passthrough in #17510 we now intentionally
lost the ability to translate VT sequences from one thing to another.
This meant we also lost the ability to do this shim and as such
this PR removes it. Luckily Windows 11 now ships PSReadLine 2.0.0,
which contains a proper fix for this.
Unfortunately, this is not the case for Windows 10, which ships
PSReadLine 2.0.0-beta2. Users affected by this will have to install
a newer version of PSReadLine or use the default black/white theme.
See 1bf4c082b4586dd056a9e67e363b5ab22197b09f
Closes#13037
This PR adds support for querying the cursor style - technically the
state of the `DECSCUSR` setting - using a `DECRQSS` escape sequence.
## References and Relevant Issues
The initial `DECRQSS` support was added in PR #11152, but it wasn't
practical to report the cursor style until conpty passthrough was added
in PR #17510.
## Detailed Description of the Pull Request / Additional comments
If the user has chosen a cursor style that isn't one of the shapes
supported by the `DECSCUSR` control, we report those as 0 (i.e. the
default style). That way, if an application later tries to restore the
cursor using the returned value, it should still be reset to its
original state.
I also took the opportunity in this PR to do some refactoring of the
other `DECRQSS` reports, since several of them were using unnecessary
appending that could be simplified to a single `fmt::format` call, or
even just static strings in some cases.
## Validation Steps Performed
I've checked the reports are working as expected in Vttest, and also
added some unit tests.
## PR Checklist
- [x] Tests added/passed
We aren't sure what exactly it is, but on the latest toolchain
this code miscompiles. The fmt call throws an exception because
it supposedly has too few arguments supplied for the format string.
Debugging the issue shows that the `next_arg_id_` internal to `fmt`
is 10000, even though it's parsing the first argument. At that point
it's supposed to be 0. This code hasn't been changed in years.
My hope is that this slight shuffling of the code causes
the issue to go away.
The idea is that we can translate Console API calls directly to VT at
least as well as the current VtEngine setup can. For instance, a call
to `SetConsoleCursorPosition` clearly translates directly to a `CUP`
escape sequence. Effectively, instead of translating output
asynchronously in the renderer thread, we'll do it synchronously
right during the Console API call.
Most importantly, the this means that any VT output that an
application generates will now be given to the terminal unmodified.
Aside from reducing our project's complexity quite a bit and opening
the path towards various interesting work like sixels, Device Control
Strings, buffer snapshotting, synchronized updates, and more, it also
improves performance for mixed text output like enwik8.txt in conhost
to 1.3-2x and in Windows Terminal via ConPTY to roughly 20x.
This adds support for overlapped IO, because now that output cannot
be "skipped" anymore (VtEngine worked like a renderer after all)
it's become crucial to block conhost as little as possible.
⚠️ Intentionally unresolved changes/quirks:
* To force a delayed EOL wrap to wrap, `WriteCharsLegacy` emits a
`\r\n` if necessary. This breaks text reflow on window resize.
We cannot emit ` \r` the way readline does it, because this would
overwrite the first column in the next row with a whitespace.
The alternative is to read back the affected cell from the buffer
and emit that character and its attributes followed by a `\r`.
I chose to not do that, because buffer read-back is lossy (= UCS2).
Unless the window is resized, the difference is unnoticeable
and historically, conhost had no support for buffer reflow anyway.
* If `ENABLE_VIRTUAL_TERMINAL_PROCESSING` is set while
`DISABLE_NEWLINE_AUTO_RETURN` is reset, we'll blindly replace all
LF with CRLF. This may hypothetically break DCS sequences, but it's
the only way to do this without parsing the given VT string and
thus the only way we can achieve passthrough mode in the future.
* `ENABLE_WRAP_AT_EOL_OUTPUT` is translated to `DECAWM`.
Between Windows XP and Windows 11 21H2, `ENABLE_WRAP_AT_EOL_OUTPUT`
being reset would cause the cursor position to reset to wherever
a write started, _if_ the write, including expanded control chars,
was less than 100 characters long. If it was longer than that,
the cursor position would end up in an effectively random position.
After lengthy research I believe that this is a bug introduced in
Windows XP and that the original intention was for this mode to be
equivalent to `DECAWM`. This is compounded by MSDN's description
(emphasis mine):
> If this mode is disabled, the **last character** in the row is
> overwritten with any subsequent characters.
⚠️ Unresolved issues/quirks:
* Focus/Unfocus events are injected into the output stream without
checking whether the VT output is currently in a ground state.
This may break whatever VT sequence is currently ongoing.
This is an existing issue.
* `VtIo::Writer::WriteInfos` should properly verify the width of
each individual character.
* Using `SetConsoleActiveScreenBuffer` destroys surrogate pairs
and extended (VT) attributes. It could be translated to VT pages
in the long term.
* Similarly, `ScrollConsoleScreenBuffer` results in the same and
could be translated to `DECCRA` and `DECFRA` in the near term.
This is important because otherwise `vim` output may loose
its extended attributes during scrolling.
* Reflowing a long line until it wraps results in the cooked read
prompt to be misaligned vertically.
* `SCREEN_INFORMATION::s_RemoveScreenBuffer` should trigger a
buffer switch similar to `SetConsoleActiveScreenBuffer`.
* Translation of `COMMON_LVB_GRID_HORIZONTAL` to `SGR 53` was dropped
and may be reintroduced alongside `UNDERSCORE` = `SGR 4`.
* Move the `OSC 0 ; P t BEL` sequence to `WriteWindowTitle`
and swap the `BEL` with the `ST` (`ESC \`).
* PowerShell on Windows 10 ships with PSReadLine 2.0.0-beta2
which emits SGR 37/40 instead of 39/49. This results in black
spaces when typing and there's no good way to fix that.
* A test is missing that ensures that `FillConsoleOutputCharacterW`
results in a `CSI n J` during the PowerShell shim.
* A test is missing that ensures that `PtySignal::ClearBuffer`
does not result in any VT being generated.
Closes#262Closes#1173Closes#3016Closes#4129Closes#5228Closes#8698Closes#12336Closes#15014Closes#15888Closes#16461Closes#16911Closes#17151Closes#17313
This fixes a regression caused by 5b44476 which accidentally moved
the two pushes into the if condition.
Closes MSFT:52463679
## Validation Steps Performed
* Enable `Feature_UseNumpadEventsForClipboardInput`
* `cmd`
* `chcp 54936`
* Paste narrow Unicode characters like ①
* It works ✅
Thanks to a string of compiler bugs, we had to use an older container
image that shipped with VS 17.9.
Unfortunately, that container image is falling further and further out
of date. The build agents don't cache it any longer, so they spend 30-45
minutes of every build pulling it from the registry.
With the changes to ConPTY in #17510 removing the need for til::bitmap,
we no longer need to work around the compiler bugs it exposed.
Furthermore, 17.10.6+ has a much more robust and presumably "working"
compiler.
The "copy the remaining attributes" loop assumes that it has full
ownership over the rows that it copies. For that to be true,
we have to of course make sure that the current write-cursor
is at a fresh, new row in the first place.
## Validation Steps Performed
* In a new pwsh tab with 120 colums:
``Write-Host -NoNewline "`e[36m$('a'*120)`e[m"; sleep 10``
* Resize the window wider
* Color doesn't get lost
Regressed in #15500, incorrectly fixed in #17332, exposed by #17583.
My ineptitude on full display. If this isn't the last cursor
invalidation bug I'm going to cry.
Closes#17615
## Validation Steps Performed
* cmd.exe
* a directory with 6 files
* 80x24 viewport
* run `cls`
* run `dir` twice
This PR adds the ability to load snippets from the CWD into the
suggestions UI.
If shell integration is disabled, then we only ever think the CWD for a
pane is it's `startingDirectory`. So, in the default case, users can
still stick snippets into the root of their git repos, and have the
Terminal load them automatically (for profiles starting in the root of
their repo).
If it's enabled though, we'll always try to load snippets from the CWD
of the shell.
* We cache the actions into a separate map of CWD -> actions. This lets
us read the file only the first time we see a dir.
* We clear that cache on settings reload
* We only load `sendInput` actions from the `.wt.json`
As spec'd in #17329
* Add a revision to `ImageSlice` so that the renderers
can use it to cache them as bitmaps across frames.
* Hooked up the revision tracking to AtlasEngine to cache the
slices into `Buffer`s so we can own them into the `Present`.
* Hooked up those snapshots to BackendD3D with a straightforward
hashmap -> atlas-rect logic. Just like rendering text.
* Hooked up BackendD2D with a bad, but simple & direct drawing logic.
* Bonus: Modify `ImageSlice` to be returned as a raw pointers
as this helps performance slightly. (Trivial type == good.)
* Bonus: Fixed the `_debugShowDirty` code (disabled by default).
## Validation Steps Performed
* `mpv --really-quiet --vo=sixel foo.mp4` looks good ✅
* Scroll up down & observe dirty rects ✅
`nuget restore` actually runs through MSBuild! However, #15855 added a
dependency from our project on a system-installed _or locally detected_
`vcpkg.targets` (or `.props`).
Our build runs `nuget restore` before finding or installing vcpkg, so
the rules in our project file would try to import vcpkg before it had
been found (or installed).
On build agents with vcpkg installed via the VS workload, this was fine:
we would import the one that came with VS and go on our merry way. On
build agents where it needs to be installed locally, it could not be
imported.
The fix in this PR is to install/bootstrap vcpkg before running nuget.
I tried to isolate the vcpkg rules to only run _in the absence of
nuget_, but that didn't work.
Removes the GitHub action that provides the functionality for the
similar issues bot prototype. We can onboard to the more official
prototype instead to conserve functionality.
This regressed in #15707. By having the `viewportOffset` on the
`Settings` object we accidentally invalidate the entire viewport
every time it scrolls. That doesn't break anything of course,
but it's better to prevent this.
This PR additionally contains a fix for clamping the y coordinates
coming from `Renderer`: Since `viewportCellCount.y` is a count and
thus exclusive, but clamp's max is inclusive, we must subtract 1.
This pull request removes the following vendored open source, in favor
of getting it from vcpkg:
- CLI11 2.4
- jsoncpp 1.9
- fmt 7.1.3
- gsl 3.1 (not vendored, but submoduled--arguably worse!)
Now that Visual Studio 2022 includes a built-in workload for vcpkg, the
onboarding process is much smoother. Terminal should only require the
vcpkg workload.
I've added some build rules that detect vcpkg via VS and via the user's
environment before falling back to a location in the source tree. The CI
pipeline will fall back to installing and bootstrapping vcpkg in
dep/vcpkg if necessary.
Some OSS has not been (and will not be) migrated:
- wyhash: ours is included directly in til/hash
- pcg_random: we have a stripped down copy compared to vcpkg
- stb_rect: vcpkg only ships *all of STB*; ours is a stripped down copy
- chromium numerics: vcpkg does not ship Chromium, especially not this
tiny fraction of Chromium
- dynamic_bitset and libpopcnt: removing in #17510
- interval_tree: no vcpkg equivalent
To support the needs of the inbox Windows build, I've split up our vcpkg
manifest into dependencies for all projects and dependencies just for
Terminal. To support this, we now offer a `terminal` feature. The vcpkg
rules in `common.build.pre.props` are set up to turn it on, whereas the
build rules we eventually write for the OS will not be.
Most of the work is concentrated in `common.build.pre.props`.
Split off from #17510:
* `Viewport::Clamp` used `std::clamp` to calculate the intersection
between two rectangles. That works for exclusive rectangles,
because `.left == .right` indicates an empty rectangle.
But `Viewport` is an inclusive one, and so `.left == .right` is
non-empty. For instance, if the to-be-clamped rect is fully
outside the bounding rect, the result is a 1x1 viewport.
In effect this meant that `Viewport::Clamp` never clamped so far.
* The `targetArea < targetBuffer.size()` check is the wrong way around.
It should be `targetArea > targetBuffer.size()`.
* The `sourceSize` and `targetSize` checks are incorrect, because the
rectangles may be non-empty but outside the valid bounding rect.
* If these sizes were empty, we'd return the requested rectangle which
is a regression since conhost v1 and violates the API contract.
* The `sourceRect` emptiness check is incorrect, because the clamping
logic before it doesn't actually clamp to the bounding rect.
* The entire clamping and iteration logic is just overall too complex.
Adds a keybinding to open the quick fix menu, if one is available. When
the action is used, we also open up the button (if it was collapsed)
because that looks nice.
The `showSuggestions` action is bound to `ctrl+shift+period` by default
to align with VS' "quick actions" feature and VS Code's "quick fix"
feature. This was chosen over binding to `quickFix` because it's more
helpful. The quick fix button is a route for users that prefer to use
the mouse. If users want to add a keybinding to activate the `quickFix`
button, they can do that now.
This PR also performs a bit of miscellaneous polish from the bug bash.
This includes:
- the suggestions UI now presents quick fixes first
- scrolling may result in the button being drawn in the wrong place
- The bug was tracked down this line:
`TermControl::CursorPositionInDips()` --> `_core.CursorPosition()` -->
`Terminal::GetViewportRelativeCursorPosition()`. The mutable viewport
there does _not_ update when the user scrolls. Thus, the button would be
drawn on the same position _on the screen_ even though we scrolled. To
fix this, I include the `_scrollOffset` in the calculation. The only
other place this function is used is with the suggestions UI, which does
_not_ update the UIs position as we scroll (but if we're interested in
doing that, we can now).
Closes#17377
Without a renderer in #17510 we cannot skip "frames" anymore.
As such, using overlapped IO becomes crucial to avoid a regression
in performance. ITerminalHandoff3 fixes this by allowing the terminal
to pick the pipes it wants, which mirrors CreatePseudoConsole
where the caller can also pick its own pipes.
## Validation Steps Performed
* Do a handoff with the dev build
* Input/Output works ✅
This implements a 3s timeout for cursor inheritance which prevents
ConPTY from being deadlocked at startup, if the terminal misbehaves.
It serves another purpose, however, in that it prepares the code for
the introduction of overlapped IO in #17510.
Closes#11213
After the ConPTY rewrite in #17510 we'll not modify any VT sequences
anymore. This means that the `--vtmode` flag uses its only function.
Its only known user is `telnet.exe` which needs to be updated
to sanitize the output on its own. See MSFT:52532514
Split off from #17510:
* `HandleWantsOverlappedIo` can be used to check if a handle requires
overlapped IO. This is important, as `ReadFile` and `WriteFile` are
documented to not work correctly if an overlapped handle is used
without overlapped IO and vice versa.
In my tests with pipes, this appears to be true.
* `CreatePipe` creates a synchronous, unidirectional pipe.
* `CreateOverlappedPipe` does what it says on the tin, while allowing
you to specify the direction of the pipe (in, out, duplex).
* `GetOverlappedResultSameThread` is largely the same as
`GetOverlappedResult`, but adds back a neat optimization from
the time before Windows 7. I thought it was neat.
This abstraction will help #17510 inject its ConPTY-specific behavior
into all 6 relevant console API functions simultaneously. This avoids
having to repeat the same prologue and epilogue 4 times.
Ideally, we'd use composition here, but I found it to be a bad fit.
