forked from microsoft/terminal
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Fork #1
Merged
Merged
Update Fork #1
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
## Summary of the Pull Request ![textAboveCursor003](https://user-images.githubusercontent.com/18356694/83681722-67a24d00-a5a8-11ea-8d9b-2d294065e4e4.gif) This is the plan that @miniksa suggested to me. Instead of trying to do lots of work in all the renderers to do backgrounds as one pass, and foregrounds as another, we can localize this change to basically just the DX renderer. 1. First, we give the DX engine a "heads up" on where the cursor is going to be drawn during the frame, in `PrepareRenderInfo`. - This function is left unimplemented in the other render engines. 2. While printing runs of text, the DX renderer will try to paint the cursor in `CustomTextRenderer::DrawGlyphRun` INSTEAD of `DxEngine::PaintCursor`. This lets us weave the cursor background between the text background and the text. ## References * #6151 was a spec in this general area. I should probably go back and update it, and we should probably approve that first. * #6193 is also right up in this mess ## PR Checklist * [x] Closes #1203 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * This is essentially `"cursorTextColor": "textForeground"` from #6151. * A follow up work item is needed to add support for the current behavior, (`"cursorTextColor": null`), and hooking up that setting to the renderer.
…6312) ## Summary of the Pull Request Adds support for trailing commas in our json files. ## References * Enabled due to the excellent work over in open-source-parsers/jsoncpp#1098 ## PR Checklist * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
Related work items: #26765368
This PR improves our VT character set support, enabling the [`SCS`] escape sequences to designate into all four G-sets with both 94- and 96-character sets, and supports invoking those G-sets into both the GL and GR areas of the code table, with [locking shifts] and [single shifts]. It also adds [`DOCS`] sequences to switch between UTF-8 and the ISO-2022 coding system (which is what the VT character sets require), and adds support for a lot more characters sets, up to around the level of a VT510. [`SCS`]: https://vt100.net/docs/vt510-rm/SCS.html [locking shifts]: https://vt100.net/docs/vt510-rm/LS.html [single shifts]: https://vt100.net/docs/vt510-rm/SS.html [`DOCS`]: https://en.wikipedia.org/wiki/ISO/IEC_2022#Interaction_with_other_coding_systems ## Detailed Description of the Pull Request / Additional comments To make it easier for us to declare a bunch of character sets, I've made a little `constexpr` class that can build up a mapping table from a base character set (ASCII or Latin1), along with a collection of mappings for the characters the deviate from the base set. Many of the character sets are simple variations of ASCII, so they're easy to define this way. This class then casts directly to a `wstring_view` which is how the translation tables are represented in most of the code. We have an array of four of these tables representing the four G-sets, two instances for the active left and right tables, and one instance for the single shift table. Initially we had just one `DesignateCharset` method, which could select the active character set. We now have two designate methods (for 94- and 96- character sets), and each takes a G-set number specifying the target of the designation, and a pair of characters identifying the character set that will be designated (at the higher VT levels, character sets are often identified by more than one character). There are then two new `LockingShift` methods to invoke these G-sets into either the GL or GR area of the code table, and a `SingleShift` method which invokes a G-set temporarily (for just the next character that is output). I should mention here that I had to make some changes to the state machine to make these single shift sequences work. The problem is that the input state machine treats `SS3` as the start of a control sequence, while the output state machine needs it to be dispatched immediately (it's literally the _Single Shift 3_ escape sequence). To make that work, I've added a `ParseControlSequenceAfterSs3` callback in the `IStateMachineEngine` interface to decide which behavior is appropriate. When it comes to mapping a character, it's simply an array reference into the appropriate `wstring_view` table. If the single shift table is set, that takes preference. Otherwise the GL table is used for characters in the range 0x20 to 0x7F, and the GR table for characters 0xA0 to 0xFF (technically some character sets will only map up to 0x7E and 0xFE, but that's easily controlled by the length of the `wstring_view`). The `DEL` character is a bit of a special case. By default it's meant to be ignored like the `NUL` character (it's essentially a time-fill character). However, it's possible that it could be remapped to a printable character in a 96-character set, so we need to check for that after the translation. This is handled in the `AdaptDispatch::Print` method, so it doesn't interfere with the primary `PrintString` code path. The biggest problem with this whole process, though, is that the GR mappings only really make sense if you have access to the raw output, but by the time the output gets to us, it would already have been translated to Unicode by the active code page. And in the case of UTF-8, the characters we eventually receive may originally have been composed from two or more code points. The way I've dealt with this was to disable the GR translations by default, and then added support for a pair of ISO-2022 `DOCS` sequences, which can switch the code page between UTF-8 and ISO-8859-1. When the code page is ISO-8859-1, we're essentially receiving the raw output bytes, so it's safe to enable the GR translations. This is not strictly correct ISO-2022 behavior, and there are edge cases where it's not going to work, but it's the best solution I could come up with. ## Validation Steps Performed As a result of the `SS3` changes in the state machine engine, I've had to move the existing `SS3` tests from the `OutputEngineTest` to the `InputEngineTest`, otherwise they would now fail (technically they should never have been output tests). I've added no additional unit tests, but I have done a lot of manual testing, and made sure we passed all the character set tests in Vttest (at least for the character sets we currently support). Note that this required a slightly hacked version of the app, since by default it doesn't expose a lot of the test to low-level terminals, and we currently identify as a VT100. Closes #3377 Closes #3487
Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 677d15a4e298a0e1e3ce093bc1dff8d832e3c2b1 Related work items: #26765368
## Summary of the Pull Request Some people wish to use Ctrl+Alt combinations without Windows treating those as an alias for AltGr combinations. This PR adds a new `altGrAliasing` setting allowing one to control this behavior. ## PR Checklist * [x] Closes #6211 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Manual testing * [x] Requires documentation to be updated: MicrosoftDocs/terminal#50 * [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: #xxx ## Validation Steps Performed * Choose a German keyboard layout * Using `showkey -a` ensured that both `Ctrl+Alt+Q/E` and `AltGr+Q/E` produce `@/€` * Added `"altGrAliasing": false` to the WSL profile * Using `showkey -a` ensured `Ctrl+Alt+Q/E` now produces `^[^Q/E` while `AltGr+Q/E` continues to produce `@/€`
This brings support for "Compact" tab sizing, which compresses all inactive tabs to just the size of their icons plus the close button. Neat! It also just keeps us generally up-to-date and good citizens.
docs have no build, cleaning out draft spec from PR queue
Co-authored-by: Michael Niksa <miniksa@microsoft.com> putting outdated draft spec into drafts folder and closing PR. CI has no function on docs.
## Summary of the Pull Request Really couldn't be more starightforward. MUX 2.4 added support for "compact" sized tabs. This PR (targeting the 2.4 PR currently, will move to `master` when that merges) enables users to specify `"tabWidthMode": "compact"` in their global settings to get this behavior. ## References * #5778 - PR to move to MUX 2.4 * [microsoft-ui-xaml#2016](microsoft/microsoft-ui-xaml#2016) - the MUX PR for compact tab sizing. * #597 - Tab sizing options? ## PR Checklist * [x] I don't think we have an issue for this, though I could be wrong. * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments In this screenshot, I'm hovering over tab 2, but the ubuntu tab is focused: ![image](https://user-images.githubusercontent.com/18356694/81302365-e6ef4000-903f-11ea-9ce3-5f5ce92e5ba4.png) In this screenshot, tab 2 is focused: ![image](https://user-images.githubusercontent.com/18356694/81302383-ea82c700-903f-11ea-9820-92348d5adc64.png)
## Summary of the Pull Request When we select a color for the tab, we update the foreground color of the text so that it maintains acceptable contrast with the new tab color. However, we weren't also updating the foreground color of the close button. This is understandable though, because apparently this wasn't fixable until MUX 2.4 arrived. I'm not a XAML expert, but I know that setting this key only works when we're using MUX 2.4, so I'm assuming something about the TabView implementation changed in that release. _This PR is marked as a draft until #5778 is merged, then I'll re-target to master._ ## References * #5778 - PR to move to MUX 2.4 * This bug was introduced with the tab color picker in #3789 ## PR Checklist * [x] Closes #5780 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed A light tab color: ![image](https://user-images.githubusercontent.com/18356694/81303943-00918700-9042-11ea-86e6-7bdfe343c4ca.png) A dark tab color: ![image](https://user-images.githubusercontent.com/18356694/81303953-04250e00-9042-11ea-8db2-be97af519fae.png)
Dustin Howett (1): Merge remote-tracking branch 'openconsole/inbox' into HEAD James Holderness (1): Improve support for VT character sets (CC-4496) Related work items: MSFT:26791619
In Windows, we build with /Zc:wchar_t- (which makes wchar_t an unsigned short typedef.) This causes build breaks when we compare two wchar_t values (or a wchar_t and an enum class that's of type wchar_t) and the compiler decides that it might want to _promote them to TextAttribute_ before doing the comparison.
Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 272dfa1c4ad5e4202c4c56f3db7a445dc0b003cf
This PR provides a faster algorithm for converting 8-bit and 24-bit colors into the 4-bit legacy values that are required by the Win32 console APIs. It also fixes areas of the code that were incorrectly using a simple 16-color conversion that didn't handle 8-bit and 24-bit values. The faster conversion algorithm should be an improvement for issues #783 and #3950. One of the main points of this PR was to fix the `ReadConsoleOutputAttribute` API, which was using a simplified legacy color conversion (the original `TextAttribute:GetLegacyAttributes` method), which could only handle values from the 16-color table. RGB values, and colors from the 256-color table, would be mapped to completely nonsensical values. This API has now been updated to use the more correct `Settings::GenerateLegacyAttributes` method. But there were also a couple of other places in the code that were using `GetLegacyAttributes` when they really had no reason to be working with legacy attributes at all. This could result in colors being downgraded to 4-bit values (often badly, as explained above), when the code was already perfectly capable of displaying the full 24-bits. This included the fill colors in the IME composer (in `ConsoleImeInfo`), and the construction of the highlighting colors in the color search/selection handler (`Selection::_HandleColorSelection`). I also got rid of some legacy attribute code in the `Popup` class, which was originally intended to update colors below the popup when the settings changed, but actually caused more problems than it solved. The other major goal of this PR was to improve the performance of the `GenerateLegacyAttributes` method, since the existing implementation could be quite slow when dealing with RGB values. The simple cases are handled much the same as they were before. For an `IsDefault` color, we get the default index from the `Settings::_wFillAttribute` field. For an `IsIndex16` color, the index can just be returned as is. For an `IsRgb` color, the RGB components are compressed down to 8 bits (3 red, 3 green, 2 blue), simply by dropping the least significant bits. This 8-bit value is then used to lookup a representative 16-color value from a hard-coded table. An `IsIndex256` color is also converted with a lookup table, just using the existing 8-bit index. The RGB mapping table was calculated by taking each compressed 8-bit color, and picking a entry from the _Campbell_ palette that best approximated that color. This was done by looking at a range of 24-bit colors that mapped to the 8-bit value, finding the best _Campbell_ match for each of them (using a [CIEDE2000] color difference calculation), and then the most common match became the index that the 8-bit value would map to. The 256-color table was just a simpler version of this process. For each entry in the table, we take the default RGB palette value, and find it's closest match in the _Campbell_ palette. Because these tables are hard-coded, the results won't adjust to changes in the palette. However, they should still produce reasonable results for palettes that follow the standard ANSI color range. And since they're only a very loose approximation of the colors anyway, the exact value really isn't that important. That said, I have tried to make sure that if you take an RGB value for a particular index in a reasonable color scheme, then the legacy color mapped from that value should ideally match the same index. This will never be possible for all color schemes, but I have tweaked a few of the table entries to improve the results for some of the common schemes. One other point worth making regarding the hard-coded tables: even if we wanted to take the active palette into account, that wouldn't actually be possible over a conpty connection, because we can't easily know what color scheme the client application is using. At least this way the results in conhost are guaranteed to be the same as in the Windows Terminal. [CIEDE2000]: https://en.wikipedia.org/wiki/Color_difference#CIEDE2000 ## Validation Steps Performed This code still passes the `TextAttributeTests` that check the basic `GetLegacyAttribute` behaviour and verify the all legacy attributes roundtrip correctly. However, some of the values in the `RgbColorTests` had to be updated, since we're now intentionally returning different values as a result of the changes to the RGB conversion algorithm. I haven't added additional unit tests, but I have done a lot of manual testing to see how well the new algorithm works with a range of colors and a variety of different color schemes. It's not perfect in every situation, but I think it works well enough for the purpose it serves. I've also confirmed that the issues reported in #5940 and #6247 are now fixed by these changes. Closes #5940 Closes #6247
Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must be generated by targets. We mostly use wildcards for pulling in PRI files that are dumped on disk by the translation tool. We don't want to check those in, so we can't expand references to them. To that end, I've introduced a new target that will take a list of folders containing resw files and expand wildcards under them. All[1] other wildcards have been moved into their respective targets _or_ simply expanded. [1]: Nothing has complained about the resource wildcards in CascadiaResources.build.items, so I haven't exploded it yet. Fixes #6214.
We're removing this because of MSFT:24623699, which prevents us from being able to do the right thing when we're called on the background of a directory for a range of OS builds. #6414 will track re-adding this to the Terminal when the original issue is closed. * [x] closes #6245 * I work here
Adds support for `win32-input-mode` to conhost, conpty, and the Windows Terminal. * The shared `terminalInput` class supports sending these sequences when a VT client application requests this mode. * ConPTY supports synthesizing `INPUT_RECORD`s from the input sent to it from a terminal * ConPTY requests this mode immediately on startup (if started with a new flag, `PSEUDOCONSOLE_WIN32_INPUT_MODE`) * The Terminal now supports sending this input as well, when conpty asks for it. Also adds a new ConPTY flag `PSEUDOCONSOLE_WIN32_INPUT_MODE` which requests this functionality from conpty, and the Terminal requests this by default. Also adds `experimental.input.forceVT` as a global setting to let a user opt-out of this behavior, if they don't want it / this ends up breaking horribly. ## Validation Steps Performed * played with this mode in vtpipeterm * played with this mode in Terminal * checked a bunch of scenarios, as outlined in a [comment] on #4999 [comment]: #4999 (comment) References #4999: The megathread References #5887: The spec Closes #879 Closes #2865 Closes #530 Closes #3079 Closes #1119 Closes #1694 Closes #3608 Closes #4334 Closes #4446
## Summary of the Pull Request Remove parentheses from the Preview and Dev build. Now they're called Windows Terminal Preview and Windows Terminal Dev Build respectively. Also removed them from other identifiers of Terminal for consistency. ## PR Checklist * [X] Closes #5974
<!-- 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 Upload the roadmap for Windows Terminal 2.0 and link to it on the README. <!-- 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 * [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: #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 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
When opening a new tab, it takes a few milliseconds before title to appears. This PR makes it instantaneous. * Updated the Terminal so that it can load the title from the settings before it is initialized. * Load terminal settings in TermControl constructor before the terminal is initialized (see above). * Update Tab so that it sets the TabViewItem's title in the constructor (in Tab::_MakeTabViewItem) instead of waiting for the VT sequence to set the title (from what I understand). NOTE 1: there is a similar problem with the tabview icon which is not fixed by this PR. NOTE 2: This is only a problem with animations disabled because otherwise the title fades in so there is enough time for it to be set when it becomes visible. ## Validation I ran the terminal and opened a new tab. The title appears instantly.
) Does what it says on the label. Pure modifier keys weren't making it this far at all prior to #6309. This PR changes these methods to make sure that we only dismiss a selection or snap on input when the key pressed isn't a modifier key. ## References * regressed in #6309 ## PR Checklist * [x] Closes #6423 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * Tried to repro this in the Terminal, couldn't anymore.
## Summary of the Pull Request When someone asked "Do we need to send a F7 keyup too" in #6309, the right answer was actually _no_. Turns out that while XAML will eat the F7 key**down**, it _won't_ eat the F7 key**up**. ## References * regressed in #6309 ## PR Checklist * [x] Closes #6438 * [x] I work here * [ ] Tested manually * [n/a] Requires documentation to be updated ## Validation Steps Performed * Checked this with the debug tap
## Summary of the Pull Request ![cmdpal-default-nested-commands](https://user-images.githubusercontent.com/18356694/90684483-e6b13400-e22d-11ea-8ca6-fe90ca8d9e82.gif) Adds a pair of top-level commands that both have nested, iterable sub-commands. The "New Tab..." command has one child for each profile, and will open a new tab for that profile. The "Split Pane..." command similarly has a nested command for each profile, and also has a nested command for split auto/horizontal/vertical. ## References * megathread: #5400 * Would look better with icons from #6644 ## PR Checklist * [x] Closes #7174 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
<!-- 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 PR splits the anchored and unanchored tab switcher into two. The anchored tab switcher is now baked into `nextTab`/`prevTab`, and the unanchored tab switcher command is just named `tabSearch`. `tabSearch` takes no arguments. To reflect this distinction, `CommandPalette.cpp` now refers to one as `TabSwitchMode` and the other as `TabSearchMode`. I've added a global setting named `useTabSwitcher` (name up for debate) that makes the Terminal use the anchored tab switcher experience for `nextTab` and `prevTab`. I've also given the control the ability to detect <kbd>Alt</kbd> KeyUp events and to dispatch keybinding events. By listening for keybindings, the ATS can react to `nextTab`/`prevTab` invocations for navigation in addition to listening for <kbd>tab</kbd> and the arrow keys. Closes #7178 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] CLA signed. * [x] Documentation updates: MicrosoftDocs/terminal#107 * [x] Schema updated.
## Summary of the Pull Request ![cmdpal-icons](https://user-images.githubusercontent.com/18356694/90916410-97dada00-e3a6-11ea-9fb0-755938a68a05.gif) Adds support for setting a command's `icon`. This supports a couple different scenarios: * setting a path to an image * on `"iterateOn": "profiles"` commands, setting the icon to `${profile.icon}` (to use the profile's icon) * setting the icon to a symbol from [Segoe MDL2 Assets](https://docs.microsoft.com/en-us/windows/uwp/design/style/segoe-ui-symbol-font) * setting the icon to an emoji * setting the icon to a character (what is an emoji other than a character, after all?) ## References * Big s/o to @leonMSFT in #6732, who really did all the hard work here. ## PR Checklist * [x] Closes #6644 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Importantly, the creation of these icons must occur on the UI thread. That's why it's done in a "load the path from json", then "get the actual IconSource" structure. ## Validation Steps Performed see the gif
This is just the `noexcept` part of #7319, because the CI apparently got updated overnight.
## Summary of the Pull Request Adds support for "commandline mode" to the command palette. ![cmdpal-commandline-mode](https://user-images.githubusercontent.com/18356694/90263053-bbd17500-de14-11ea-8726-fee48fec5888.gif) This allows the user to start typing a `wt.exe` commandline directly in the command palette, to run that commandline directly in the current window. This allows the user input something like `> nt -p Ubuntu ; sp -p ssh` and open up a new tab and split it _in the current window_. ## References * cmdpal megathread: #5400 * Kinda related to #4472 * built with the `wt` action from #6537 ## PR Checklist * [x] Closes #6677 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - sure does, when the cmdpal docs are written in the first place :P ## Validation Steps Performed Tested manually
Bind the command palette to Ctrl+Shift+P by default, to enable it for all users in v1.3
Most applications with scrollable content seem to define the "large jump" distance as about a screenful of content. You can see this in long pages in Settings and documents in Notepad. We just weren't configuring ScrollBar here. Fixes #7367
Signed-off-by: Dustin Howett <duhowett@microsoft.com>
The descriptions were flipped, so I unflipped them.
This commit removes our local copy of clang-format 8 and replaces it with a newly-built nuget package containing clang-format 10. This resolves the inconsistency between our version of clang-format and the one shipped in Visual Studio. A couple minor format changes were either required or erroneously forced upon us--chief among them is a redistribution of `*`s around SAL annotations in inline class members of COM classes. Don't ask why; I couldn't figure it out. We had some aspirational goals for our formatting, which were left in but commented out. Enabling them changes our format a little more than I'm comfortable with, so I uncommented them and locked them to the format style we've been using for the past year. We may not love it, but our aspirations may not matter here any longer. Consistent formatting is better than perfect formatting.
When the console functional tests are running on OneCoreUAP, the newly-introduced (65bd4e3, #4309) FillOutputCharacterA tests will actually fail because of radio interference on the return value of GLE. Fixes MSFT-28163465
## Summary of the Pull Request Previously, if `altGrAliasing` was disabled, all `Ctrl+Alt` combinations were considered to be aliases of `AltGr` including `AltGr` itself and thus considered as key and not character events. But `AltGr` should not be treated as an alias of itself of course, as that prevents one from entering `AltGr` combinations entirely. ## PR Checklist * [x] Closes #7372 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] 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 ## Validation Steps Performed * Activate a German keyboard layout * Run `showkey -a` in WSL * **Ensure** that `AltGr+Q` produces `@` * **Ensure** that `Ctrl+Alt+Q` produces `@` * Disable `altGrAliasing` * **Ensure** that `AltGr+Q` produces `@` * **Ensure** that `Ctrl+Alt+Q` produces `^[^Q`
This fixes a regression in environment variable loading introduced as part of the new environment block creation that prevents some system-defined, volatile environment variables from being defined. ## References #7243 (comment) ## Validation Steps Performed Manually verified locally. Closes #7399
## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
Dustin L. Howett * Clear the last error before calling Mb2Wc in ConvertToW (GH-7391) * Update clang-format to 10.0 (GH-7389) * Add til::static_map, a constexpr key-value store (GH-7323) James Holderness * Refactor VT control sequence identification (CC-7304) Mike Griese * Compensate for VS 16.7, part 2 (GH-7383) * Add support for iterable, nested commands (GH-6856) Michael Niksa * Helix Testing (GH-6992) * Compensate for new warnings and STL changes in VS 16.7 (GH-7319) nathpete-msft * Fix environment block creation (GH-7401) Chester Liu * Add initial support for VT DCS sequences (CC-6328) Related work items: #28791050
`setColorScheme` should require `colorScheme` rather than `name`
Profile is now a WinRT object in the TerminalApp project. As with ColorScheme, all of the serialization logic is not exposed via the idl. TerminalSetingsModel will handle it when it's all moved over. I removed the "Get" and "Set" prefixes from all of the Profile functions. It just makes more sense to use the `GETSET_PROPERTY` macro to do most of the work for us. `CloseOnExitMode` is now an enum off of the Profile.idl. `std::optional<wstring>` got converted to `hstring` (as opposed to `IReference<hstring>`). `IReference<hstring>` is not valid to MIDL. ## References #7141 - Profile is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded Closes #7435
GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
<!-- 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 Conhost can now support OSC8 sequences (as specified [here](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda)). Terminal also supports those sequences and additionally hyperlinks can be opened by Ctrl+LeftClicking on them. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #204 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [X] Closes #204 * [ ] 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 Added support to: - parse OSC8 sequences and extract URIs from them (conhost and terminal) - add hyperlink uri data to textbuffer/screeninformation, associated with a hyperlink id (conhost and terminal) - attach hyperlink ids to text to allow for uri extraction from the textbuffer/screeninformation (conhost and terminal) - process ctrl+leftclick to open a hyperlink in the clicked region if present <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Open up a PowerShell tab and type ```PowerShell ${ESC}=[char]27 Write-Host "${ESC}]8;;https://github.com/microsoft/terminal${ESC}\This is a link!${ESC}]8;;${ESC}\" ``` Ctrl+LeftClick on the link correctly brings you to the terminal page on github ![hyperlink](https://user-images.githubusercontent.com/26824113/89953536-45a6f580-dbfd-11ea-8e0d-8a3cd25c634a.gif)
…ge (#7504) When attempting to select a text range from a different text buffer (such as a standard text range when in alt mode), conhost crashes. This PR checks for this case and returns `E_FAIL` instead, preventing this crash. ## PR Checklist * [x] Closes unfiled crash issue * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Passes manual test below * [ ] 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 ## Validation Steps Performed Ran the following lines in the NVDA Python console (NVDA+control+z) before and after this PR, and observed that Conhost no longer crashes after the change: ``` Python console >>> # SSH to a remote Linux system >>> ti=nav.makeTextInfo("caret") >>> ti.move("line", -2) -2 >>> # Switch away from the NVDA Python console, and run Nano in conhost. Then: >>> ti.updateSelection() # Calls select() on the underlying UIA text range Traceback (most recent call last): File "<console>", line 1, in <module> File "NVDAObjects\UIA\__init__.pyc", line 790, in updateSelection File "comtypesMonkeyPatches.pyc", line 26, in __call__ _ctypes.COMError: (-2147220991, 'An event was unable to invoke any of the subscribers', (None, None, None, 0, None)) ```
…heet manifest Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp dd0c54d9abd94dea1ffe956373a4c20b30a6151e Related work items: MSFT-26187783
This commit introduces Jumplist customization and an item for each profile to the Jumplist. Selecting an entry in the jumplist will pretty much just execute `wt.exe -p "{profile guid}"`, and so a new Terminal will open with the selected profile. Closes #576
* Update doc * Change last digit
This PR is about the behavior of DECSCUSR. This PR changes the meaning of DECSCUSR 0 to restore the cursor style back to user default. This differs from what VT spec says but it’s used in popular terminal emulators like iTerm2 and VTE-based ones. See #1604. Another change is that for parameter greater than 6, DECSCUSR should be ignored, instead of restoring the cursor to legacy. This PR fixes it. See #7382. Fixes #1604.
Conhost expands UIA text ranges when moved. This means that degenerate ranges become non-degenerate after movement, leading to odd behaviour from UIA clients. This PR doesn't expand degenerate ranges, but rather keeps them degenerate by moving `_end` to the newly-changed `_start`. Tested in the NVDA Python console (cases with `setEndPoint` and `compareEndPoints` described in #7342). Also ran the logic by @michaelDCurran. Closes #7342 Almost definitely addresses nvaccess/nvda#11288 (although I'll need to test with my Braille display). Also fixes an issue privately reported to me by @Simon818 with copy/paste from review cursor which originally lead me to believe the issue was with `moveEndPointByRange`.
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.
Summary of the Pull Request
References
PR Checklist
Detailed Description of the Pull Request / Additional comments