The Erase All VT sequence (`^[[2J`) is supposed to erase the entire
contents of the viewport. The way it usually does this is by shifting
the entirety of the viewport contents into scrollback, and starting the
new viewport below it.
Currently, conpty doesn't propagate that state change correctly. When
conpty gets a 2J, it simply erases the content of the connected
terminal's viewport, by writing over it with spaces. Conpty didn't
really have a good way of communicating "your viewport should move", it
only knew "the buffer is now full of spaces".
This would lead to bugs like #2832, where pressing <kbd>ctrl+L</kbd> in
`bash` would delete the current contents of the viewport, instead of
moving the viewport down.
This PR makes sure that when conpty sees a 2J, it passes that through
directly to the connected terminal application as well. Fortunately, 2J
was already implemented in the Windows Terminal, so this actually fixes
the behavior of <kbd>ctrl+L</kbd>/`clear` in WSL in the Terminal.
## References
* #4252 - right now this isn't the _most_ optimal scenario, we're
literally just printing a 2J, then we'll perform "erase line" `height`
times. The erase line operations are all redundant at this point - the
entire viewport is blank, but conpty doesn't really know that.
Fortunately, #4252 was already filed for me to come through and
optimize this path.
## PR Checklist
* [x] Closes#2832
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* ran tests
* compared <kbd>ctrl+L</kbd> with its behavior in conhost
* compared `clear` with its behavior in conhost
I never got to fixing these in the original #3789 PR, but I messed up that branch way too many times already that I figured I'd just do it in post.
* [x] Fixes the typo bot in `master`
* [x] I work here
This commit introduces a context menu for Tab and a new item,
"Color...", which will display a color picker.
A flyout menu, containing a custom flyout, is attached to each tab. The
flyout displays a palette of 16 preset colors and includes a color
picker. When the user selects or clears color, an event is fired, which
is intercepted by the tab to which the flyout belongs.
The changing of the color is achieved by putting the selected color in
the resource dictionary of the tab, using well-defined dictionary keys
(e.g. TabViewItemHeaderBackground). Afterwards the visual state of the
tab is toggled, so that the color change is visible immediately.
Custom-colored tabs will be desaturated (somewhat) by alpha blending
them with the tab bar background.
The flyout menu also contains a 'Close' flyout item.
## Validation Steps Performed
I've validated the behavior manually: start the program via the start
menu. Right click on the tab -> Choose a tab color.
The color flyout is going to be shown. Click a color swatch or click
'Select a custom color' to use the color picker. Use the 'Clear the
current color' to remove the custom color.
Closes#2994. References #3327.
<!-- 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
This fixes the RTL regression caused in #4747. We create the rectangle taking the direction (through the BiDi Level) into account, and then the rendering works again. The GlyphRun shaping could still probably use some work to be a polished thingy, and there are still issues with RTL getting chopped up a lot when there's font fallback going on, but this fixes the regression, and it's now functional again.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4779#4747
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4779
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- 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
The baseline is actually direction dependent. So when it was being initialized, the unconditional baseline as left broke it, setting the box off to right of the text. We just check if the `GlyphRun->bidiLevel` is set, and if so, we adjust it so that the baseline lines up with the right, not with the left.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- 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
Tooltip texts is an important element of each software! Added tooltip text to close button, minimize, restore down, and new tab. Moved from original.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
Connected to #5355
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [X] Closes#5355
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [X] No Docs
* [ ] 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: #5355
<!-- 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'm pretty sure most ppl know what a tooltip text is, but for those who don't, it's a text that tells you what a button does when you over the button with your mouse.
This commit introduces a NOTICE.html file that will be embedded into the
package. It will be stamped down with the real notices during a branded
release build (as part of the build pipeline.)
It, in part, reverts some of the really good work in determining the
commit hash at build time. That work will be preserved in history.
This is more compliant with our duties to the OSS we consume.
## Summary of the Pull Request
This PR implements a pair of shims for `cmd` and `powershell`, so that their `cls` and `Clear-Host` functions will clear the entire terminal buffer (like they do in conhost), instead of just the viewport. With the conpty viewport and buffer being the same size, there's effectively no way to know if an application is calling these API's in this way with the intention of clearing the buffer or the viewport. We absolutely have to guess.
Each of these shims checks to see if the way that the API is being called exactly matches the way `cmd` or `powershell` would call these APIs. If it does, we manually write a `^[[3J` to the connected terminal, to get he Terminal to clear it's own scrollback.
~~_⚠️ If another application were trying to clear the **viewport** with an exactly similar API call, this would also cause the terminal scrollback to get cleared ⚠️_~~
* [x] Should these shims be restricted to when the process that's calling them is actually `cmd.exe` or `powershell.exe`? Can I even do this? I think we've done such a good job of isolating the client process information from the rest of the host code that I can't figure out how to do this.
- YES, this can be done, and I did it.
* [ ] **TODO**: _While I'm here_, should I have `DoSrvPrivateEraseAll` (the implementation for `^[[2J`, in `getset.cpp`) also manually trigger a EraseAll in the terminal in conpty mode?
## PR Checklist
* [x] Closes#3126
* [x] Actually closes#1305 too, which is really the same thing, but probably deserves a callout
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* ran tests
* checked `cls` in the Terminal
* checked `Clear-Host` in the Terminal
* Checked running `powershell clear-host` from `cmd.exe`
We've got a weird crash that happens terribly inconsistently, but pretty
readily on migrie's laptop, only in Debug mode. Apparently, there's some
weird ref-counting magic that goes on during teardown, and our
Application doesn't get closed quite right, which can cause us to crash
into the debugger. This of course, only happens on exit, and happens
somewhere in the `...XamlHost.dll` code.
Crazily, if we _manually leak the `Application`_ here, then the crash
doesn't happen. This doesn't matter, because we really want the
Application to live for _the entire lifetime of the process_, so the only
time when this object would actually need to get cleaned up is _during
exit_. So we can safely leak this `Application` object, and have it just
get cleaned up normally when our process exits.
* [x] I discussed this with @DHowett-MSFT and we both agree this is mental
* [x] I'm pretty sure there's not an actual bug on our repo for this
* [x] I verified on my machine where I can crash the terminal 100% of the time on exit in debug, this fixes it
* [x] I verified that it doesn't introduce a _new_ crash in Release on my machine
Turns out we're still being a bit too aggressive when removing spaces.
If there are spaces at the end of the first run painted to a bottom
line, _and the bottom line was a different color than the previous_,
then we can't trim those spaces off the string. We still need to emit
those to make sure the terminal has colored spaces in it as well.
## References
* there's like 80 PRs in the last month for this function
## PR Checklist
* [x] Closes#5502
* [x] I work here
* [x] Tests added/passed
## Validation Steps
* [x] ran the tests
* [x] checked that vtpipeterm still worked
* [x] Checked that the bug was fixed in the Terminal
For our release builds, we're just going to integrate the UWPDesktop CRT
into our package and delete the package dependencies. It's very
difficult for users who do not have access to the store to get our
dependency packages, and we want to be robust and deployable everywhere.
Since these libraries can be redistributed, it's easiest if we simply
redistribute them.
Our package grows by ~550kb per architecture (compressed) because of
this. I've added validation that we don't have both the libs _and_ the
dependencies in the same package.
Fixes#3097.
## Validation
The script does it!
## Summary of the Pull Request
Based on the discussion in #5479, it seems that the crash is caused by a race condition due to not obtaining the write lock before calling `TriggerFontChange`.
I'm not totally sure if my approach is the right one, but I've taken the lock out of `_RefreshSize` since it seems like all calls of `_RefreshSize` come after a `TriggerFontChange`/`UpdateFont`. Then I just
made sure all calls of `TriggerFontChange`/`UpdateFont` are preceded with a `LockForWriting`.
## PR Checklist
* [x] Closes#5479
* [x] CLA signed.
* [x] Tests added/passed
## Validation Steps Performed
Scrolling to change my font size does not kill the Terminal anymore! 🙌
If a class has a constructor which can be called with a single argument,
then this constructor becomes conversion constructor because such a
constructor allows conversion of the single argument to the class being
constructed. To ensure these constructors are passed the argument of its
type, I labeled them explicit.
In some header files, there were constructors that took a value that
could involve implicit conversions, so I added explicit to ensure that
does not happen.
Hide any commandline (cooked read) we have before we begin a resize, and
show it again after the resize.
## References
* I found #5618 while I was working on this.
## PR Checklist
* [x] Closes#1856
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Basically, during a resize, we try to restore the viewport position
correctly, and part of that checks where the current commandline ends.
However, when we do that, the commandline's _current_ state still
reflects the _old_ buffer size, so resizing to be smaller can cause us
to throw an exception, when we find that the commandline doesn't fit in
the new viewport cleanly.
By hiding it, then redrawing it, we avoid this problem entirely. We
don't need to perform the check on the old commandline contents (since
they'll be empty), and we'll redraw it just fine for the new buffer size
## Validation Steps Performed
* ran tests
* checked resizing, snapping in conhost with a cooked read
* checked resizing, snapping in the Terminal with a cooked read
Web apps apparently will paste the <title> as plaintext before the
actual HTML content from the clipboard. Since this seems to be
widespread behavior across web apps, this isn't just a bug in _some
app_, this is a bug on us. We shouldn't emit the title.
This PR removes the title tag from the generated HTML.
Closes#5347
<!-- 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
In tonight's episode of "Can we be even faster?", we will... you know what, just take a look at the code.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- 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
It is actually a quite common technique seen inside the codebase to first reserve the spaces before pushing something into vectors. I don't know why it is not used here.
Before:
After:
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- 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
In tonight's episode of "I wanna my CPU back", we'll see a quite familiar face whose name is Mr.AttrRow.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#2937
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- 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 knew this is possible a long time ago. Just didn't got the chance to actually implement this. I understand that you guys are busy preparing the v1.0 release. So if this is a bad time, this can wait.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manually tested. If all goes well, nothing will be broken.
## Summary of the Pull Request
This PR clamp the "new rows" scrolling value to a positive number. We can't create a negative number of new rows. It also adds a test.
## References
## PR Checklist
* [x] Closes#5540
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
The origin of this bug is that as newlines are emitted, we'll accumulate an enormous scroll delta into a selection region, to the point of overflowing a `SHORT`. When the overflow occurs, the `Terminal` would fail to send a `NotifyScroll()` to the `TermControl` hosting it.
For this bug to repro, we need to:
- Have a sufficiently large buffer, because each newline we'll accumulate a delta of (0, ~bufferHeight), so (bufferHeight^2 + bufferHeight) > SHRT_MAX
- Have a selection
## Validation Steps Performed
* Dustin verified this actually
* Created a new insane test case
## Summary of the Pull Request
Before this, if the Search Box was open, new selections would not notify automation clients. This was because the UiaEngine (responsible for notifying automation clients) would remain disabled. Now we're enabling it before the early exit in TermControl's FocusHandler
## PR Checklist
* [X] Will close issue #5421 upon verification
## Validation Steps Performed
Verified using NVDA.
Narrator's behavior is not impacted, for some reason.
This PR fixes#5525 by re-adding range checks that were erroneously removed in
a9c9714.
## Validation Steps Performed
* Enabled a German keyboard layout
* Entered `<`, `+`, `7`, `8`, `9`, `0` while holding either Alt+Ctrl or AltGr and...
* Ensuring that both produce `|`, `~`, `{`, `[`, `]`, `}`
Closes#5525
## Summary of the Pull Request
This PR will add a link to the version of `NOTICE.md` in GitHub at the commit that the build was on. It uses the same approach for generating our settings files, where we'll create a header file with the commit hash assigned to a `wstring_view` during build time.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#5139
* [x] CLA signed.
* [x] Tests added/passed
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
The link is there and goes to the expected `NOTICE.md`.
This PR fixes a couple of issues with TSFInputControl alignment:
1. The emoji picker IME in particular would show up overlapping the
current buffer row because I stupidly didn't realize that
`TextBlock.ActualHeight` is 0 right after initialization and before
it has any text. So, the emoji picker will show up on the bottom of
the 0 height TextBlock, which overlaps the current buffer row. This
isn't a problem with CJK because inputting text _causes_ the IME to
show up, so by the time the IME shows up, the TextBlock has text and
accordingly has a height.
2. It turns out the emoji picker IME doesn't follow the `TextBlock`
bottom, unlike Chinese and Japanese IME, so if a user were to compose
near the edge of the screen and let the `TextBlock` start line
wrapping, the emoji IME doesn't follow the bottom of the `TextBlock`
as it grows. This means that the `TextBlock` position doesn't update
in the middle of composition, and the `LayoutRequested` event that it
fires at the beginning of composition is the only chance we get to
tell the emoji IME where to place itself. It turns out when we reset
`TextBlock.Text`, the ActualHeight doesn't get immediately reset back
to the min size. So if a user were to bring up the emoji IME before
`ActualHeight` is reset, the IME will show up way below the current
buffer row.
3. We don't currently `TryRedrawCanvas` when the window position changes
(resizing, dragging the window around), so sometimes dragging or
resizing the Terminal doesn't update the position of the IME. Ideally
it should be listening to some "window position changed" event, but
alas we don't have that and it would be much harder than this
incoming fix. We'll just track the window bounds as part of
`TryRedrawCanvas` and redraw if it changes. For the most part, this
will allow the IME to update to where the new window position is, but
it'll only be called if we receive a `LayoutRequested` event.
## PR Checklist
* [x] Closes#5470
* [x] CLA signed.
* [x] Tests added/passed
## Validation Steps Performed
I play with it for quite a bit.
<!-- 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
A tiny performance fix in `renderer.cpp`.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- 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
The cluster construction code is intensively called during rendering. Even though a single `back()` is fast, but accumulated `back()`s still take a noticiable amount of CPU cycles.
Before:
After:
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manually validated.
This property was deprecated in 0.11. We probably should have also added a warning
message to help the community figure out that this property is gone and won't work
anymore.
This PR adds that warning.
* I'm not going to list the enormous number of duped threads _wait yes I am_
* #5581
* #5547
* #5555
* #5557
* #5573
* #5532
* #5527
* #5535
* #5510
* #5511
* #5512
* #5513
* #5516
* #5515
* #5521
* This literally isn't even all of them
* [x] Also mainly related to #5458
* [x] I work here
* [x] Tests added/passed
Followup to ea61aa3b.
The default foreground in the iTerm2 defaults for the Tango Dark color
scheme is too bright, use the value for ANSI 7 (white) instead.
References #5305
Sorry, I should have really done this in the original PR.
Signed-off-by: Rafael Kitover <rkitover@gmail.com>
Also known as "Kill HRGN II: Kills Regions Dead (#5485)"
Copying the description from @greg904 in #4778.
--- 8< ---
My understanding is that the XAML framework uses another way of getting
mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It
looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`.
Before, we were cutting (with `HRGN`s) the drag bar part of the XAML
islands window in order to catch mouse messages and be able to implement
the drag bar that can move the window. However this "cut" doesn't only
apply to input (mouse messages) but also to the graphics so we had to
paint behind with the same color as the drag bar using GDI to hide the
fact that we were cutting the window.
The main issue with this is that we have to replicate exactly the
rendering on the XAML drag bar using GDI and this is bad because:
1. it's hard to keep track of the right color: if a dialog is open, it
will cover the whole window including the drag bar with a transparent
white layer and it's hard to keep track of those things.
2. we can't do acrylic with GDI
So I found another method, which is to instead put a "drag window"
exactly where the drag bar is, but on top of the XAML islands window (in
Z order). I've found that this lets us receive the `WM_LBUTTONDOWN`
messages.
--- >8 ---
Dustin's notes: I've based this on the implementation of the input sink
window in the UWP application frame host.
Tested manually in all configurations (debug, release) with snap,
drag, move, double-click and double-click on the resize handle. Tested
at 200% scale.
Closes#4744Closes#2100Closes#4778 (superseded.)
Takes the lock inside two routines in `TermControl` that were changing
the selection endpoint while a rendering frame was still drawing,
resulting in several variants of graphical glitches from double-struck
selection boxes to duplicated line text.
## References
- Introduced with #5185
## PR Checklist
* [x] Closes#5471
* [x] Already signed life away to company.
* [x] Manual tests passed since it's visual.
* [x] No extra doc besides the comments.
* [x] Am core contributor: Roar.
The renderer base and specific renderer engine do a lot of work to
remember the previous selection and compensate for scrolling regions and
deltas between frames. However, all that work doesn't quite match up
when the endpoints are changed out from under it. Unfortunately,
`TermControl` doesn't have a robust history of locking correctly in step
with the renderer nor does the renderer's `IRenderData` currently
provide any way of 'snapping' state at the beginning of a frame so it
could work without a full lock. So the solution for now is for the
methods that scroll the display in `TermControl` to take the lock that
is shared with the renderer's frame painter so they can't change out of
sync.
## Validation Steps Performed
- Opened terminal with Powershell core.
Did ls a bunch of times.
Clicked to make selection and held mouse button while wheeling around.
- Opened terminal with Powershell core.;
Did ls a bunch of times.
Clicked to make selection and dragged mouse outside the window to make
auto scroll happen.
- Opened terminal with Powershell core.
Did ls a bunch of times.
Clicked to make selection and released. Wheeled around like a crazy
person to make sure I didn't regress that.
Literally just <kbd>ctrl+f</kbd> find-and-replace all the old `profiles.json` that are sitting around in the repo with `settings.json`. I didn't touch the specs, since it seemed better to leave them in the state that they were originally authored in.
* [x] closes#5522
* [x] I work here.
* [x] This is docs.
It was brought to our attention that shipping a font with ligatures as our default
font could be an accessibility issue for the visually-impaired. Unfortunately, we
don't have a renderer setting to disable ligatures (#759). Fortunately however, we
DO already have a version of Cascadia that doesn't have ligatures.
If we ship that and set it as our default font, we'll at least let people _opt_ to
have ligatures enabled by switching from `Cascadia Mono` to `Cascadia Code`.
## PR Checklist
* [x] Closes internal discussion
* [x] CLA signed
* [ ] Tests added/passed
* [x] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
In order to support a transparent background for the acrylic effect, the
renderer sets the alpha value to zero for the default background color.
However, when the _reversed video_ attribute is set, the background is
actually filled with the foreground color, and will not be displayed
correctly if it is made transparent. This PR addresses that issue by
making sure the rendered background color is opaque if the reversed
video attribute is set.
## References
* This is not a major issue at the moment, since the _reverse video_
attribute is not typically forwarded though conpty, but that will
change once #2661 is fixed.
## PR Checklist
* [x] Closes#5498
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Requires documentation to be 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: #5498
## Detailed Description of the Pull Request / Additional comments
This simply adds an additional check in `Terminal::GetBackgroundColor`
to make sure the returned color is opaque if the _reverse video_
attribute is set. At some point in the future this check may need to be
extended to support the `DECSCNM` reverse screen mode, but for now
that's not an issue.
## Validation Steps Performed
I've run the test case from issue #5498, and confirmed that it now works
as expected. I've also got an experimental fix for #2661 that I've
tested with this patch, and that now displays _reverse video_ attributes
correctly too.
Closes#5498
If Terminal is spawned by a shortcut that requests that it run in a new process group
while attached to a console session, that request is nonsense. That request will, however,
cause WT to start with Ctrl-C disabled. This wouldn't matter, because it's a Windows-subsystem
application. Unfortunately, that state is heritable. In short, if you start WT using cmd in
a weird way, ^C stops working inside the terminal. Mad.
Fixes#5460.
## Summary of the Pull Request
- Adjusts scaling practices in `DxEngine` (and related scaling practices in `TerminalControl`) for pixel-perfect row baselines and spacing at High DPI such that differential row-by-row rendering can be applied at High DPI.
## References
- #5185
## PR Checklist
* [x] Closes#5320, closes#3515, closes#1064
* [x] I work here.
* [x] Manually tested.
* [x] No doc.
* [x] Am core contributor. Also discussed with some of them already via Teams.
## Detailed Description of the Pull Request / Additional comments
**WAS:**
- We were using implicit DPI scaling on the `ID2D1RenderTarget` and running all of our processing in DIPs (Device-Independent Pixels). That's all well and good for getting things bootstrapped quickly, but it leaves the actual scaling of the draw commands up to the discretion of the rendering target.
- When we don't get to explicitly choose exactly how many pixels tall/wide and our X/Y placement perfectly, the nature of floating point multiplication and division required to do the presentation can cause us to drift off slightly out of our control depending on what the final display resolution actually is.
- Differential drawing cannot work unless we can know the exact integer pixels that need to be copied/moved/preserved/replaced between frames to give to the `IDXGISwapChain1::Present1` method. If things spill into fractional pixels or the sizes of rows/columns vary as they are rounded up and down implicitly, then we cannot do the differential rendering.
**NOW:**
- When deciding on a font, the `DxEngine` will take the scale factor into account and adjust the proposed height of the requested font. Then the remainder of the existing code that adjusts the baseline and integer-ifies each character cell will run naturally from there. That code already works correctly to align the height at normal DPI and scale out the font heights and advances to take an exact integer of pixels.
- `TermControl` has to use the scale now, in some places, and stop scaling in other places. This has to do with how the target's nature used to be implicit and is now explicit. For instance, determining where the cursor click hits must be scaled now. And determining the pixel size of the display canvas must no longer be scaled.
- `DxEngine` will no longer attempt to scale the invalid regions per my attempts in #5185 because the cell size is scaled. So it should work the same as at 96 DPI.
- The block is removed from the `DxEngine` that was causing a full invalidate on every frame at High DPI.
- A TODO was removed from `TermControl` that was invalidating everything when the DPI changed because the underlying renderer will already do that.
## Validation Steps Performed
* [x] Check at 150% DPI. Print text, scroll text down and up, do selection.
* [x] Check at 100% DPI. Print text, scroll text down and up, do selection.
* [x] Span two different DPI monitors and drag between them.
* [x] Giant pile of tests in https://github.com/microsoft/terminal/pull/5345#issuecomment-614127648
Co-authored-by: Dustin Howett <duhowett@microsoft.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
## Summary of the Pull Request
Users were not able to intercept Ctrl-C input using `$Host.UI.RawUI.ReadKey("IncludeKeyUp")`, because we weren't sending a Ctrl-C KeyUp event. This PR simply adds a KeyUp event alongside the existing KeyDown.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#1894
* [x] CLA signed.
* [x] Tests added/passed
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
The repro script in #1894 now works, both options for `ReadKey`: `IncludeKeyUp` and `IncludeKeyDown` work fine.
This PR adds a test for #5428. Mysteriously, after #5398 merged, 5428 went away. However, I already wrote this test for it, so we might as well add it to our collection.
* [x] Closes#5428
* [x] I work here
* [x] Is a test
- build: move oss required to build conhost out of dep/
This change is necessary as the dep/ folder is not synced into the
Windows source tree.
I've also added a build rule producing a lib for {fmt}.
This will be required for our next OS ingestion.
Related work items: #26069643
This change is necessary as the dep/ folder is not synced into the
Windows source tree.
I've also added a build rule producing a lib for {fmt}.
This will be required for our next OS ingestion.
* Cleaning up the whitelist a bit.
* The magic to exclude repeated characters worked 👍
* Every successful run on master now logs its suggested cleanup, e.g. for 5740e197c2 has https://github.com/microsoft/terminal/runs/596271627#step:4:37
* ⚠️ This check-spelling 0.0.15a+ tolerates Windows line endings in the `whitelist.txt` file (another project I touched had some `.gitconfig` magic which required supporting them).
This means that if someone edits the file w/ something that likes Windows line endings, the file will successfully convert (instead of it being ignored and check-spelling complaining about everything). Most likely anyone else who then edits the file will use something that will maintain the line endings.
Improve wide glyph support in UIA (GH-4946)
Add enhanced key support for ConPty (GH-5021)
Set DxRenderer non-text alias mode (GH-5149)
Reduce CursorChanged Events for Accessibility (GH-5196)
Add more object ID tracing for Accessibility (GH-5215)
Add SS3 cursor key encoding to ConPty (GH-5383)
UIA: Prevent crash from invalid UTR endpoint comparison (GH-5399)
Make CodepointWidthDetector::GetWidth faster (CC-3727)
add til::math, use it for float conversions to point, size (GH-5150)
Add support for renderer backoff, don't FAIL_FAST on 3x failures, add UI (GH-5353)
Fix a deadlock and a bounding rects issue in UIA (GH-5385)
Don't duplicate spaces from potentially-wrapped EOL-deferred lines (GH-5398)
Reimplement the VT tab stop functionality (CC-5173)
Clamp parameter values to a maximum of 32767. (CC-5200)
Prevent the cursor type being reset when changing the visibility (CC-5251)
Make RIS switch back to the main buffer (CC-5248)
Add support for the DSR-OS operating status report (CC-5300)
Update the virtual bottom location if the cursor moves below it (CC-5317)
ci: run spell check in CI, fix remaining issues (CC-4799) (CC-5352)
Set Cascadia Code as default font (GH-5121)
Show a double width cursor for double width characters (GH-5319)
Delegate all character input to the character event handler (CC-4192)
Update til::bitmap to use dynamic_bitset<> + libpopcnt (GH-5092)
Merged PR 4465022: [Git2Git] Merged PR 4464559: Console: Ingest OSS changes up to e0550798
Correct scrolling invalidation region for tmux in pty w/ bitmap (GH-5122)
Render row-by-row instead of invalidating entire screen (GH-5185)
Make conechokey use ReadConsoleInputW by default (GH-5148)
Manually pass mouse wheel messages to TermControls (GH-5131)
This fixes C-M-space for WSL but not for Win32, but I'm not sure there's a problem in Win32 quite yet. (GH-5208)
Fix copying wrapped lines by implementing better scrolling (GH-5181)
Emit lines wrapped due to spaces at the end correctly (GH-5294)
Remove unneeded whitespace (CC-5162)
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/200414-1630 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 90031afa8114b7d95e3993573fc8449a1524a7fd
Related work items: #25439646
The "Campbell Powershell" color scheme does not have a high enough color contrast
ratio. Campbell does, so we're changing it there.
Closes (only upon validation) #5393.
## Summary of the Pull Request
This is a quick-and-easy solution to #5309. If the ITextRangeProvider API allows us to take in two UiaTextRanges, we need to verify that they are both valid.
With this PR, we make sure they both fit in the current TextBuffer. If not, we return `E_FAIL`. Though this doesn't prove that both UiaTextRanges are from the same TextBuffer, at the very least we don't crash and in cases where we can't make a valid comparison, we return an HRESULT failure.
## References
#5406 - This should be the proper solution to this problem. Each UiaTextRange needs to be aware of which TextBuffer it came from.
## PR Checklist
* [X] Closes#5309
## Validation Steps Performed
1. generate enough output to cause the terminal to scroll
2. execute `nano` to make us go into the alternate buffer
This previously crashed, now NVDA seems to detect that there was an error and keeps moving along.
