[pull] master from microsoft:master #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
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:  New appearance with this PR:  Most important deltas highlighted with red circles:  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: 
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` |  `false` |  ## 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.
This commit introduces two new launch modes: focus and maximizedFocus.
* Focused mode, behaves like a default mode, but with the Focus Mode
enabled.
* Maximized focused mode, behaves like a Maximized mode, but with the
Focus Mode enabled.
There two ways to invoke these new modes:
* In the settings file: you set the "launchMode" to either "focus" or
"maximizedFocus"
* In the command line options, you can path -f / --focus, which is
mutually exclusive with the --fullscreen, but can be combined with the
--maximized:
* Passing -f / --focus will launch the terminal in the "focus" mode
* Passing -fM / --focus --maximized will launch the terminal in the
"maximizedFocus" mode
This should resolve a relevant part in the command line arguments
mega-thread #4632
Closes #7124
Closes #7825
Closes #7875
* Correct the behaviour of parsing `rgb:R/G/B`. It should be interpreted as `RR/GG/BB` instead of `0R/0G/0B` * Add support for `rgb:RRR/GGG/BBB` and `rgb:RRRR/GGGG/BBBB`. The behaviour of 12 bit variants is to repeat the first digit at the end, e.g. `rgb:123/456/789` becomes `rgb:1231/4564/7897`. * Add support for `#` formats. We are following the rules of [XParseColor] by interpreting `#RGB` as `R000G000B000`. * Add support for XOrg app color names, which are supported by xterm, VTE and many other terminal emulators. * Multi-parameter OSC 4 is now supported. * The chaining of OSC 10-12 is not yet supported. But the parameter validation is relaxed by parsing the parameters as multi-params but only use the first one, which means `\e]10;rgb:R/G/B;` and `\e]10:rgb:R/G/B;invalid` will execute `OSC 10` with the first color correctly. This fixes some of the issues mentioned in #942 but not all of them. [XParseColor]: https://linux.die.net/man/3/xparsecolor Closes #3715
This PR updates the doc in the repo to address how to use TAEF as part of the development workflow. Closes #1962
This uses the templates from https://github.com/github/super-linter/tree/master/TEMPLATES currently. A future PR can add the necessary templates to the Windows Terminal repository and update the source of Templates following the README. Additionally we can add flags to explicitly choose the linters applicable to this code base but is not necessary. Per the README, this does not enforce any linting rules but rather outputs the suggestions in the build step, which are to be read by the PR submitter and Windows Terminal team to determine if they want to use the linting rule. C++ is currently not supported (Powershell, Json, Yaml, and Markdown will be the only things the linter checks for currently) but we could add our own custom support if desired in separate PR. ## Validation Steps Performed It successfully runs. Currently only shows the yaml file itself being linted in this PR as a test case. It will apply to new PRs once this is merged. We can lint existing code base but would require a separate PR and examining the code output (also requires updating the yaml file temporarily). Closes #7513
Just a simple update on the emoji so that it catch people attention as I see many open issues about terminal not running on Windows Server 2016.
<!-- 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 Add a "Close..." option to the tab context menu, with nested entries to close tabs to the right and close other tabs (actions already available)  <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5524 * [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. * [ ] 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 First contribution 🙂 Tried to follow some suggestions from #1912 (comment) <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
For whatever reason, the super linter seems to think that any file it doesn't recognize is an EDITORCONFIG file. That means all our `cpp`, `hpp`, `h`, `resw`, `xaml`, etc files are going to get linted with different rules than the clang-format ones we already use. This PR disables the EDITORCONFIG linter, and has a minimal change to a cpp file to ensure that it's no longer linted by the action. See also: * #7637 added this * #7799 is blocked by this * #7924 is blocked by this
## Summary of the Pull Request Added watch on desktopImagePath to check when the path equals "DesktopWallpaper" If it does equal "DesktopWallpaper" it replaces the path with a path to the desktop's wallpaper *I am a student and this is my first pull request for Terminal so please give feedback no matter how small. It's the best way I can learn. ## PR Checklist * [X] Closes #7295 * [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [?] Tests added/passed * [X] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: MicrosoftDocs/terminal#155 * [?] Schema updated. (Not sure if this is needed, also not sure where this would be) * [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: #7295 (Have only talked with the people on the issue, which I don't think has any core contributors) ## Detailed Description of the Pull Request / Additional comments I am using SystemParametersInfo for SPI_GETDESKWALLPAPER which puts the path into a WCHAR and that is then inserted as the BackgroundImagePath. I do not think an additional test would add value. The SPI_GETDESKTOPWALLPAPER uses the computers local wallpaper path and puts it into a WCHAR, which then I feed into BackgroundImagePath() as it's new path. I don't think there adds value in making a static path of the desktop background and testing that, given that static tests are already done for "BackgroundImage()". ## Validation Steps Performed (Manual Validation - Test False Value) 1. Ran Terminal 2. Set setting ["backgroundImage": "<some random img path>"] under profiles->defaults 3. Verified terminal's background is not the desktops wallpaper. (Manual Validation - Test True Value) 1. Ran Terminal 2. Set setting ["backgroundImage": "DesktopWallpaper"] under profiles->defaults 3. Verified the background image matches the desktop background image. (Manual Validation - Multiple Tabs True Value) 1. Ran Terminal 2. Set setting ["backgroundImage": "DesktopWallpaper"] under profiles->defaults 3. Verified the background image matches the desktop background image. 4. Opened new tabs 5. Verified the background image matches the desktop background image for each tab.
This PR introduces a pair of classes for managing VT parameters that automatically handle range checking and default fallback values, so the individual operations don't have to do that validation themselves. In addition to simplifying the code, this fixes a few cases where we were mishandling missing or extraneous parameters, and adds support for parameter sequences on commands that couldn't previously handle them. This PR also sets a limit on the number of parameters allowed, to help thwart DoS memory consumption attacks. ## References * The new parameter class also introduces the concept of an omitted/default parameter which is not necessarily zero, which is a prerequisite for addressing issue #4417. ## Detailed Description of the Pull Request / Additional comments There are two new classes provide by this PR: a `VTParameter` class, similar in function to a `std::optional<size_t>`, which holds an individual parameter (which may be an omitted/default value); and a `VTParameters` class, similar in function to `gsl:span<VTParameter>`, which holds a sequence of those parameters. Where `VTParameter` differs from `std::optional` is with the inclusion of two cast operators. There is a `size_t` cast that interprets omitted and zero values as 1 (the expected behaviour for most numeric parameters). And there is a generic cast, for use with the enum parameter types, which interprets omitted values as 0 (the expected behaviour for most selective parameters). The advantage of `VTParameters` class is that it has an `at` method that can never fail - out of range values simply return the a default `VTParameter` instance (this is standard behaviour in VT terminals). It also has a `size` method that will always return a minimum count of 1, since an empty parameter list is typically the equivalent of a single "default" parameter, so this guarantees you'll get at least one value when iterating over the list with `size()`. For cases where we just need to call the same dispatch method for every parameter, there is a helper `for_each` method, which repeatedly calls a given predicate function with each value in the sequence. It also collates the returned success values to determine the overall result of the sequence. As with the `size` method, this will always make at least one call, so it correctly handles empty sequences. With those two classes in place, we could get rid of all the parameter validation and default handling code in the `OutputStateMachineEngine`. We now just use the `VTParameters::at` method to grab a parameter and typically pass it straight to the appropriate dispatch method, letting the cast operators automatically handle the assignment of default values. Occasionally we might need a `value_or` call to specify a non-standard default value, but those cases are fairly rare. In some case the `OutputStateMachineEngine` was also checking whether parameters values were in range, but for the most part this shouldn't have been necessary, since that is something the dispatch classes would already have been doing themselves (in the few cases that they weren't, I've now updated them to do so). I've also updated the `InputStateMachineEngine` in a similar way to the `OutputStateMachineEngine`, getting rid of a few of the parameter extraction methods, and simplifying other parts of the implementation. It's not as clean a replacement as the output engine, but there are still benefits in using the new classes. ## Validation Steps Performed For the most part I haven't had to alter existing tests other than accounting for changes to the API. There were a couple of tests I needed to drop because they were checking for failure cases which shouldn't have been failing (unexpected parameters should never be an error), or testing output engine validation that is no longer handled at that level. I've added a few new tests to cover operations that take sequences of selective parameters (`ED`, `EL`, `TBC`, `SM`, and `RM`). And I've extended the cursor movement tests to make sure those operations can handle extraneous parameters that weren't expected. I've also added a test to verify that the state machine will correctly ignore parameters beyond the maximum 32 parameter count limit. I've also manual confirmed that the various test cases given in issues #2101 are now working as expected. Closes #2101
Terminal ships with this dependency embedded, and it is not required that you install it separately. Since the link is broken, let's just remove it entirely. * [x] fixes #7889 * [x] related to #7917 (comment) * [x] I work here * [x] is a docs update Additionally, update the markdown linter rules in the wake of #7637, because apparently that was never actually applied to any files, so now the onus is on the first person to touch any of our markdown files.
This commit is in support of WTU. I initially added support for a new flag, `PSEUDOCONSOLE_UNDOCKED_PREFER_INBOX_CONHOST`, which I liked because it was more explicit. We chose not to go that route. ### Automatic fallback #### Pros * It's easier on the consumer * We can eventually expand it to support `$ARCH/openconsole.exe` #### Cons * Packaging the project wrong will result in a working-but-somewhat-broken experience (old conhost) * We ameliorated this by checking it in the packaging script. * Implicit behavior may be bad
Adds a new setting, `bellStyle`, to be able to disable the audible bell added in #7679. Currently, this setting accepts two values: * `audible`: play a noise on a bell * `none`: Don't play a noise. In the future, we can add a `"bellStyle": "visible"` for flashing the Terminal instead of making a noise on bell. ## Validation Steps Performed Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of triggering a bell. I set the setting to `none`, and presto, the bell stopped. Closes #2360
This PR adds support for the `DECREQTPARM` (Request Terminal Parameters) escape sequence, which was originally used on the VT100 terminal to report the serial communication parameters. Modern terminal emulators simply hardcode the reported values for backward compatibility. The `DECREQTPARM` sequence has one parameter, which was originally used to tell the terminal whether it was permitted to send unsolicited reports or not. However, since we have no reason to send an unsolicited report, we don't need to keep track of that state, but the permission parameter does still determine the value of the first parameter in the response. The response parameters are as follows: | Parameter | Value | Meaning | | ---------------- | ------ | ------------------------ | | response type | 2 or 3 | unsolicited or solicited | | parity | 1 | no parity | | data bits | 1 | 8 bits per character | | transmit speed | 128 | 38400 baud | | receive speed | 128 | 38400 baud | | clock multiplier | 1 | | | flags | 0 | | There is some variation in the baud rate reported by modern terminal emulators, and 9600 baud seems to be a little more common than 38400 baud, but I thought the higher speed was probably more appropriate, especially since that's also the value reported by XTerm. ## Validation Steps Performed I've added a couple of adapter and output engine tests to verify that the sequence is dispatched correctly, and the expected responses are generated. I've also manually tested in Vttest and confirmed that we now pass the `DECREQTPARM` test in the _Test of terminal reports_. Closes #7852
VsCode uses `>` as its "prefix" for the equivalent of their "action mode". This PR aligns the Terminal with their logic here. We have to be tricky - if we use the `>` in the actual input as the indicator for action mode, we can't display any placeholder text in the input to tell users to type a command. This wasn't an issue for the commandline mode previously, because we'd stick the "prompt" in the "no matches text" space. However, we can't do that for action mode. Instead, we'll stick a floating text block over the input box, and when the user's in action mode, we'll manually place a `>` into that space. When the user backspaces the `>`, we'll remove it from that block, and switch into commandline mode. ## Validation Steps Performed Played with the cmdpal in lots of different modes, this finally feels good Closes #7736
When handling SendKey, preserve selection upon PrintScreen (VK_SNAPSHOT) Closes #7395
This optimizes the binary size of the xorg color table by replacing the static lookup table with a table of variable colors (indexed "" (0) through "4"), calculated greys for gr[ae]y0-100, and a table of the remaining unsuffixed colors. 78 variable colors ... 8 bytes each for pointer+size 5 variants, 4 bytes each for the color data 718 bytes for 0-terminated color names plus 84 colors ... 8 bytes each for pointer+size 4 bytes each for the color data 955 bytes for 8-terminated color names 2902 = (78 * 8) + (78 * 5 * 4) + 718 + 1963 = (84 * 8) + (84 * 4) + 955 ------ 4865 bytes (approximately) "I couldn't sleep at night thinking that after years of accusing Windows being bloated and literally making it even more bloated with my hands. So here you go. The mediocre yet working solution. This reduces the binary size to 1051k (1067k before) while keeping the code maintainable for human beings."
This commit adds a missing conversion utf8 to utf16 in decoding base64
for handling multibyte text in copying via OSC 52.
## Validation Steps Performed
* automatically
* Tests w/ multibyte characters
* manually
* case1
* Executed `printf "\x1b]52;;%s\x1b\\" "$(printf '👍👍🏻👍🏼👍🏽👍🏾👍🏿' | base64)"`
* Verified `👍👍🏻👍🏼👍🏽👍🏾👍🏿` in my clipboard
* case2
* Copied `👍👍🏻👍🏼👍🏽👍🏾👍🏿` by tmux 2.6 default copy function (OSC 52)
* Verified `👍👍🏻👍🏼👍🏽👍🏾👍🏿` in my clipboard
Closes #7819
It turns out that we missed part of the OSC 8 spec which indicated that _hyperlinks with the same ID but different URIs are logically distinct._ > Character cells that have the same target URI and the same nonempty id > are always underlined together on mouseover. > The same id is only used for connecting character cells whose URIs is > also the same. Character cells pointing to different URIs should never > be underlined together when hovering over. This pull request fixes that oversight by appending the (hashed) URI to the generated ID. When Terminal receives one of these links over ConPTY, it will hash the URL a second time and therefore append a second hashed ID. This is taken as an acceptable cost. Fixes #7698
## Summary of the Pull Request This implements the `Copy` function for `CascadiaSettings`. Copy performs a deep copy of a `CascadiaSettings` object. This is needed for data binding in the Terminal Settings Editor. The `Copy` function was basically implemented in every settings model object. This was mostly just repetitive work. ## References #7667 - TSM #1564 - Settings UI ## PR Checklist * [X] Tests added/passed
Fix for crash occurring when splitting a pane, due to tab context menu created multiple times. ## References #7728 ## PR Checklist * [x] Closes #7941 * [x] CLA signed. ## Detailed Description of the Pull Request / Additional comments When splitting panes the `Tab::Initialize` function is called again. This rebuilt the context menu from scratch and appended the existing Close... sub-menu items to a new parent, thus causing the crash. It is not necessary to re-create the context menu every time you split panes, it can be created only once. ## Validation Steps Performed Manual verification: - Play with the context menu, the Close... submenu is functioning - Split panes (ALT + New tab), no crash occurs and context menu still functioning
Updates the GH Action and makes a small update to the README to test changes. A missing install step for Windows Terminal using Scoop has been added. The versioning of Super-Linter was also switched to v3 to allow auto-updates within the v3 series. This can be version-pinned again if a breaking change comes later. The current updates fix some bugs and bump the linters utilized. ## Validation Steps Performed Validation will be shown in the build steps. Closes #7934
This import is required to make localized resources work.
Let's assume the user has bound the dead key ^ to a sendInput command
that sends "b". If the user presses the two keys ^a it'll produce "bâ",
despite us marking the key event as handled. We can use `ToUnicodeEx`
to clear such dead keys from the keyboard state and should make use of
that for keybindings. Unfortunately `SetKeyboardState` cannot be used
for this purpose as it doesn't clear the dead key state.
Validation
* Enabled a German keyboard layout
* Added the following two keybindings:
{ "command": { "action": "sendInput", "input": "x" }, "keys": "q" },
{ "command": { "action": "sendInput", "input": "b" }, "keys": "^" }
* Pressed the following keys → ensured that the given text is printed:
* q → x
* ´ → nothing
* a → á
* ^ → b
* a → a (previously this would print: â)
* ´ → nothing
* ^ → b
* a → a (unfortunately we cannot specifically clear only ^)
Closes #5784
This PR changes the ATS display order to _always_ be in most recently used (MRU) order. I chose not to give ATS the option to be displayed in-order because that order is better served through the traditional left-right TabRow switching. _Note_: `TabSearch` will stay in-order. This means that users can only choose one order or another in their `nextTab/prevTab` bindings. Setting `useTabSwitcher` to true will make nT/pT open the ATS in MRU order. If it's set to false, the ATS won't open and nT/pT will simply go left and right on the TabRow. I'm open to getting rid of the global and making ATS its own keybinding, but for now I figured I would keep the current behavior and open the PR to get eyes on the code that doesn't have anything to do with the settings. Closes #973
## Summary of the Pull Request Just deleting an unnecessary call to `_UpdateCommandsForPalette` **Note:** This only fixes slowdown when opening/closing a tab, but not upon first startup (we still need to call `_UpdateCommandsForPalette` there ## References Fixes the slowdown described in #7820 for opening and closing tabs, but doesn't improve startup time dramatically. ## Validation Steps Performed Tested with ~100 profiles in my settings file
## Summary of the Pull Request Fixes the bug where `exit`ing inside a closed pane would leave the Terminal blank. Additionally, removes `Tab::GetRootElement` and replaces it with the _observable_ `Tab::Content`. This should be more resilient in the future. Also adds some tests, though admittedly not for this exact scenario. This scenario requires a cooperating TerminalConnection that I can drive for the sake of testing, and _ain't nobody got time for that_. ## References * Introduced in #6989 ## PR Checklist * [x] Closes #7252 * [x] I work here * [x] Tests added/passed 🎉 * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments From notes I had left in `Tab.cpp` while I was working on this: ``` OKAY I see what's happening here the ActivePaneChanged Handler in TerminalPage doesn't re-attach the tab content to the tree, it just updates the title of the window. So when the pane is `exit`ed, the pane's control is removed and re-attached to the parent grid, which _isn't in the XAML tree_. And no one can go tell the TerminalPage that it needs to re set up the tab content again. The Page _manually_ does this in a few places, when various pane actions are about to take place, it'll unzoom. It would be way easier if the Tab could just manage the content of the page. Or if the Tab just had a Content that was observable, that when that changed, the page would auto readjust. That does sound like a LOT of work though. ``` ## Validation Steps Performed Opened panes, closed panes, exited panes, zoomed panes, moved focus between panes, panes, panes, panes
Our build pipeline was originally set up such that we could take any binaries from the Terminal build and seamlessly re-package them with the release or preview livery. My initial plan was to stamp a stable and preview build at the same time, out of the same bits, to make ring promotion easier. I've never done that. For the last five releases, we've just re-cut a new stable build along with the new preview build, usually because we want to backport some fixes to stable. This commit introduces preprocessor defines, detectable through CL and RC, for any project that wants them. Right now, that's just going to be WindowsTerminal.vcxproj (since it hosts the icons and the app entry point). This list may be extended to include wt (the shim executable) and the shell extension at some future date. This will greatly simplify the logic in #7971, as we'll no longer need to detect if we're dev or preview at runtime. It may also simplify the logic in the shell extension for determining whether we're Dev or not.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )