This commit adds the ability to interact with subtrees of panes.
Have you ever thought that you don't have enough regression testing to
do? Boy do I have the PR for you! This breaks all kinds of assumptions
about what is or is not focused, largely complicated by the fact that a
pane is not a proper control. I did my best to cover as many cases as I
could, but I wouldn't be surprised if there are some things broken that
I am unaware of.
Done:
- Add `parent` and `child` movement directions to move up and down the
tree respectively
- When a parent pane is selected it will have borders all around it in
addition to any borders the children have.
- Fix focus, swap, split, zoom, toggle orientation, resize, and move to
all handle interacting with more than one pane.
- Similarly the actions for font size changing, closing, read-only, clearing
buffer, and changing color scheme will distribute to all children.
- This technically leaves control focus on the original control in the
focused subtree because panes aren't proper controls themselves. This
is also used to make sure we go back down the same path with the
`child` movement.
- You can zoom a parent pane, and click between different zoomed
sub-panes and it won't unzoom you until you use moveFocus or another
action. This wasn't explicitly programmed behavior so it is probably
buggy (I've quashed a couple at least). It is a natural consequence of
showing multiple terminals and allowing you to focus a terminal and a
parent separately, since changing the active pane directly does not
unzoom. This also means there can be a disconnect between what pane is
zoomed and what pane is active.
## Validation Steps Performed
Tested focus movement, swapping, moving panes, and zooming.
Closes#10733
<!-- 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
Continuation of https://github.com/microsoft/terminal/pull/10972 to handle multiple windows, requires that to be merged first.
<!-- 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
* [x] Also closes#766
* [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
* [x] 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
Rough changelog:
Normally saving is triggered to occur every 30s, or sooner if a window is created/closed. The existing behavior of saving on last close is maintained to bypass that throttling. The automatic saving allows for crash recovery. Additionally all window layouts will be saved upon taking the `quit` action.
For loading we will check if we are the first window, that there are any saved layouts, and if the setting is enabled, and then depending on if we were given command line args or startup actions.
- create a new window for each saved layout, or
- take the first layout for our self and then a new window for each other layout.
This also saves the layout when the quit action is taken.
Misc changes
- A -s,--saved argument was added to the command line to facilitate opening all of the windows with the right settings. This also means that while a terminal session is running you can do wt -s idx to open a copy of window idx. There isn't a stable ordering of which idx each window gets saved as (it is whatever the iteration order of _peasants is), so it is just a cute hack for now.
- All position calculation has been moved up to AppHost this does mean we need to awkwardly pass around positions in a couple of unexpected places, but no solution was perfect.
- Renamed "Open tabs from a previous session" to "Open windows from a previous session". (not reflected in video below)
- Now save runtime tab color and window names
- Only enabled for non-elevated windows
- Add some change tracking to ApplicationState
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
`SettingsLoader::_parse` used to skip profiles which didn't have either a "guid"
or "name" field, due to #9962. This is however wrong for fragment loading, as
fragments can alternatively use an "updates" field instead of guid/name.
`SettingsLoader::_parse` was updated to allow profiles with this alternative
field during fragment loading.
## PR Checklist
* [x] Closes#11331
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Wrote the following to
`%LOCALAPPDATA%\Microsoft\Windows Terminal\Fragments\test\test.json`:
```json
{
"profiles": [
{
"updates": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
"background": "#FFD700"
}
]
}
```
## Summary of the Pull Request
This introduces a new TIL class that is equivalent in functionality to a `std::bitset`, but where the positions in the bitset are enum values. It also has a few additional methods allowing for setting and testing multiple positions at the same time. The idea is that this class could be used in place of the `WI_SetFlag` and `WI_IsFlagSet` macros when working with sets of flags.
## PR Checklist
* [x] Closes#10432
* [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: #10432
## Validation Steps Performed
I've added a few unit tests that verify the behaviour of all the new methods that aren't part of `std::bitset`. I've also tried it out as a replacement for the `GridLines` enum used in the renderer, and confirmed that it has all the functionality needed to replace that cleanly.
This commit fixes layering of fragment profiles without an update key.
The previous CascadiaSettings deserializer first assembled all builtin
profiles and only then parsed the user's settings.json file.
This meant that even though fragment profiles were added to `_allProfiles`
unconditionally, they did get layered properly with user profiles regardless,
as user profiles were always properly layered.
The new CascadiaSettings approach since 168d28b was a direct translation of this
approach but this is incorrect: As the new approach reads user profiles first,
all inbox profiles, including fragments, must equally use proper layering,
instead of adding profiles unconditionally.
While this commit fixes the bug it maintains a regression:
Duplicate fragment profile GUIDs will not be detected and instead fragments with
identical GUID will all be added as parents to a single user profile.
I considered to fix this regression, but felt that this new behavior is better
than the old one, since a user often can't directly control installed fragments,
and is unlikely to occur in practice. This simplifies the implementation.
## PR Checklist
* [x] Closes#11323
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Fragment layering works ✔️
Ensures that command-lines constructed to invoke `wt` are escaped properly.
## PR Checklist
* [x] Closes#11273
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
This was broken in two places - when constructing the command-line in the shell extension and in `NewTerminalArgs::ToCommandline()`.
Both places now invoke a shared method to escape the command-line arguments that require it.
## Validation Steps Performed
Added a test and additionally:
* Invoked the shell extension from `D:\Downloads\With;Semicolon`.
* Added a `newWindow` action to `settings.json` as below and ensured the new window opened without erroring.
```json
{
"command":
{
"action": "newWindow",
"tabTitle": "\";foo\\"
},
"keys": "ctrl+shift+s"
}
```
Adds a check before every UIA function call to ensure the terminal (specifically the buffer) is initialized before doing work. Both the `ScreenInfoUiaProvider` and the `UiaTextRange` are now covered.
## References
Closes#11135#10971 & #11042
## Detailed Description of the Pull Request / Additional comments
Originally, I tried applying this heuristic to all the `RuntimeClassInitialize` on `UiaTextRangeBase` with the philosophy of "a range pointing to an invalid buffer is invalid itself", but that caused a regression on [MSFT 33353327](https://microsoft.visualstudio.com/OS/_workitems/edit/33353327).
`IUiaData` also has `GetTextBuffer()` return a `TextBuffer&`, which cannot be checked for nullness. Instead, I decided to add a function to `IUiaData` that checks if we have a valid state. Since this is shared with Conhost and Conhost doesn't have this issue, I simply make that function say that it's always in a valid state.
## Validation Steps Performed
- [X] Narrator can detect newly created terminals
- [X] (On Windows Server 2022) Windows Terminal does not hang on launch
Implements the following keyboard selection non-configurable key bindings:
- shift+arrow --> move endpoint by character
- ctrl+shift+left/right --> move endpoint by word
- shift+home/end --> move to beginning/end of line
- ctrl+shift+home/end --> move to beginning/end of buffer
This was purposefully done in the ControlCore layer to make keyboard selection an innate part of how the terminal functions (aka a shared component across terminal consumers).
## References
#715 - Keyboard Selection
#2840 - Spec
## Detailed Description of the Pull Request / Additional comment
The most relevant section is `TerminalSelection.cpp`, where we define how each movement operates. It's basically a giant embedded switch-case statement. We leverage a lot of the work done in a11y to perform the movements.
## Validation Steps Performed
- General cases:
- test all of the key bindings added
- Corner cases:
- `char`: wide glyph support
- `word`: move towards, away, and across the selection pivot
- automatically scroll viewport
- ESC (and other key combos) are still clearing the selection properly
For some weird reason we sometimes receive a WM_KEYDOWN
message without vkey or scanCode if a user drags a tab.
The KeyChord constructor has a debug assertion ensuring that all KeyChord
either have a valid vkey/scanCode. This is important, because this prevents
accidential insertion of invalid KeyChords into classes like ActionMap.
## PR Checklist
* [x] Closes#11076
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Tab dragging doesn't produce assertion failures anymore ✔️
## Summary of the Pull Request
Fixes the 24 failing generated tests. 20 of them were fixed by enforcing the following rule: when moving backwards by word...
- a degenerate range moves to the beginning of the word, then to the word behind it.
- a non-degenerate range outright moves to the word behind it.
The fix was simple: if we're a degenerate range, check if we're at the beginning of the word. If not, move there. Otherwise, move to the word before it. See UiaTextRangeBase.cpp changes for implementation details.
Along the way, several misauthored tests were found:
- 2 generated tests:
- Cause: MS Word considers a line break a word delimiter. We don't use line-wrapping to distinguish two separate words.
- `MovementAtExclusiveEnd` backwards word movement tests:
- `end` will always be `writeTarget` because...
- [degenerate range case] both `start` and `end` are moved to the beginning of the word (`writeTarget`)
- [non-degenerate range case] from the `UiaTextRangeBase` bugfix, we should be moving to the word behind it.
- this misauthored test was explicitly found by fixing the bug first explained here.
## References
#10925 Word navigation testing
This commit reduces the code surface that interacts with raw JSON data,
reducing code complexity and improving maintainability.
Files that needed to be changed drastically were additionally
cleaned up to remove any code cruft that has accrued over time.
In order to facility this the following changes were made:
* Move JSON handling from `CascadiaSettings` into `SettingsLoader`
This allows us to use STL containers for data model instances.
For instance profiles are now added to a hashmap for O(1) lookup.
* JSON parsing within `SettingsLoader` doesn't differentiate between user,
inbox and fragment JSON data, reducing code complexity and size.
It also centralizes common concerns, like profile deduplication and
ensuring that all profiles are assigned a GUID.
* Direct JSON modification, like the insertion of dynamic profiles into
settings.json were removed. This vastly reduces code complexity,
but unfortunately removes support for comments in JSON on first start.
* `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced
with `FromJson`, allowing us to remove JSON-based color scheme validation.
* `Profile`s used to test their wish to layer using `ShouldBeLayered`, which
was replaced with a GUID-based hashmap lookup on previously parsed profiles.
Further changes were made as improvements upon the previous changes:
* Compact the JSON files embedded binary, saving 28kB
* Prevent double-initialization of the color table in `ColorScheme`
* Making `til::color` getters `constexpr`, allow better optimizations
The result is a reduction of:
* 48kB binary size for the Settings.Model.dll
* 5-10% startup duration
* 26% code for the `CascadiaSettings` class
* 1% overall code in this project
Furthermore this results in the following breaking changes:
* The long deprecated "globals" settings object will not be detected and no
warning will be created during load.
* The initial creation of a new settings.json will not produce helpful comments.
Both cases are caused by the removal of manual JSON handling and the
move to representing the settings file with model objects instead
## PR Checklist
* [x] Closes#5276
* [x] Closes#7421
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Out-of-box-experience is identical to before ✔️
(Except for the settings.json file lacking comments.)
* Existing user settings load correctly ✔️
* New WSL instances are added to user settings ✔️
* New fragments are added to user settings ✔️
* All profiles are assigned GUIDs ✔️
<!-- 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
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#11083#11143
<!-- 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
* [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
<!-- 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
While testing the save/quit features a number of issues were found that were caused by poor synchronization on the monarch, resulting in various unexpected crashes. Because this uses std collections, and I didn't see any builtin winrt multithreaded containers I went with the somewhat heavy-handed mutex approach.
e.g.
- https://github.com/microsoft/terminal/pull/11083#issuecomment-916218353
- https://github.com/microsoft/terminal/pull/11083#issuecomment-916220521
- https://github.com/microsoft/terminal/pull/11143/#discussion_r704738433
This also makes it so that on quit peasants don't try to become the monarch, and the monarch closes their peasant last to prevent elections from happening.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Create many windows (hold down ctrl-shift-n) then use the quit action from peasants/the monarch to make sure everything closes properly.
[Git2Git] Merged PR 6303114: Prepare command history before COOKED_READ in tests
PR !6278637 introduced a dependency from COOKED_READ_DATA on the ability
to locate a command history for a process handle (here, `nullptr`).
The tests were blowing up because no such history had been allocated.
Closes MSFT-34812916
Closes MSFT-34813774
Closes MSFT-34815941
Closes MSFT-34817558
Closes MSFT-34817540 (Watson)
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev f7517e686447fc0469f6b83df19760dc3dafd577
This is equivalent to commit 8779249b1, but reflected from the OS repository.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev a4d67e9b05039f365a1a0c58e9c63474c58073a1
Related work items: MSFT-34777060
Process exit code now shows as hex not decimal. Format specification needs length "10" not "8" because the leading '0x' generated by the # symbol counts as part of the length.
## PR Checklist
* [x] Closes annoyance at looking up process exit codes
* [x] I work here.
* [x] Checked manually
## Validation Steps Performed
- [x] Ran it, opened tab, opened another CMD tab, ran `exit <code>` and observed hex pattern
## Summary of the Pull Request
Clears selection render on paste
## PR Checklist
* [x] Closes#11227
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Detailed Description of the Pull Request / Additional comments
Added ```_renderer->TriggerSelection(); ``` similarly to the copy action few lines up in ```CopySelectionToClipboard``` function
## Validation Steps Performed
Manually tested
* this is the same thing as #10996, but with the fix that caused us to #11031
* This includes https://github.com/microsoft/microsoft-ui-xaml/pull/3769, so we had to make some adjustments to how we handle tab colors. It works the same as before.
* Should enable #11231 to be started
* [x] Closes#10508
* [x] Closes#7133
* [x] Closes#8948
* [ ] I need to finish letting my 19H1 VM boot to make sure unpackaged still works
## Summary of the Pull Request
Adds support for vintage style opacity, on Windows 11+. The API we're using for this exists since the time immemorial, but there's a bug in XAML Islands that prevents it from working right until Windows 11 (which we're working on backporting).
Replaces the `acrylicOpacity` setting with `opacity`, which is a uint between 0 and 100 (inclusive), default to 100.
`useAcrylic` now controls whether acrylic is used or not. Setting an opacity < 100 with `"useAcrylic": false` will use vintage style opacity.
Mouse wheeling adjusts opacity. Whether acrylic is used or not is dependent upon `useAcrylic`.
`opacity` will stealthily default to 50 if `useAcrylic:true` is set.
## PR Checklist
* [x] Closes#603
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/416
## Detailed Description of the Pull Request / Additional comments
Opacity was moved to AppearanceConfig. In the future, I have a mind to allow unfocused acrylic, so that'll be important then.
## Validation Steps Performed
_just look at it_
Adjust tools version for folks running on 2022
## PR Checklist
* [x] Closes annoyance that @lhecker and I have selfhosting VS2022
* [x] I work here
* [x] Solution built
* [x] @dhowett said something like "lol sure" in Teams.
## Summary of the Pull Request
Updates our `UiaTextRange` to no longer treat the end of the buffer as the "document end". Instead, we consider the "document end" to be the line beneath the cursor or last legible character (whichever is further down). In the event where the last legible character is on the last line of the buffer, we use the "end exclusive" position (left-most point on a line one past the end of the buffer).
When movement of any kind occurs, we clamp each endpoint to the document end. Since the document end is an actual spot in the buffer (most of the time), this should improve stability because we shouldn't be pointing out-of-bounds anymore.
The biggest benefit is that this significantly improves the performance of word navigation because screen readers no longer have to take into account the whitespace following the end of the prompt.
Word navigation tests were added to the `TestTableWriter` (see #10886). 24 of the 85 tests were failing, however, they don't seem to interact with the document end, so I've marked them as skip and will fix them in a follow-up. This PR is large enough as-is, so I'm hoping I can take time in the follow-up to clean some things on the side (aka `preventBoundary` and `allowBottomExclusive` being used interchangeably).
## References
#7000 - Epic
Closes#6986Closes#10925
## Validation Steps Performed
- [X] Tests pass
- [X] @codeofdusk has been personally testing this build (and others)
When we're elevated, we disable drag/dropping tabs when elevated, because of a platform limitation that causes the app to _crash_ (see #4874). However, if the user has UAC disabled, this actually works alright. So I'm adding it back in that case.
I'm not positive if this is the best way to check if UAC is disabled, but normally, you'll get a [`TokenElevationTypeFull`] when elevated, not `TokenElevationTypeDefault`. If the app is elevated, but there's not a split token, that kinda implies there's no user account separation. If I'm wrong, it's just code, let's replace this with something that does work.
## Validation Steps Performed
Booted up a Win10 VM, set `enableLUA` to `0`, rebooted, and checked if this exploded. It didn't.
References #4874
References #3581
Work done in pursuit of #11096Closes#7754
[`TokenElevationTypeFull`]: https://docs.microsoft.com/en-us/windows/win32/api/winnt/ne-winnt-token_elevation_type
This commit aligns the COM-consuming code in VsSetupInstance with best
practices such as passing COM pointers by pointer when they do not need
to be owning references and not using `const` on members, as well as
cleans up some dead code.
Leonard contributed clang-tidy fixes and some reference passing
changes.
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
This commit adds dynamic profile generators for Visual Studio Developer
Command Prompt (VS2017+) and Visual Studio Developer PowerShell
(VS2019.2+)
Tested manually by deploying locally. My local environment has four
instances of VS installed, one VS2017 and multiple channels of VS2019.
We're wrapping the COM Visual Studio Setup Configuration API to query
for VS instances and retrieve the relevant properties. Two different
namespaces are used so the end-user can turn off one or the other. For
instance, end user may prefer to always use Developer PowerShell.
## Validation Steps Performed
1. Build locally using Visual Studio 2019
2. Deploy CascadiaPackage
3. Verify entries exist in profiles menu
4. Verify entries exist in settings.json
5. Open each profile
6. Validate start-in directory
7. Validate environment variables are as expected
8. Uninstall Windows Terminal - Dev package
9. Repeat.
Closes#3821
<!-- 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
Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane.
<!-- 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
* [x] Closes#4340
* [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: #xxx
* [x] 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
"vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Split the pane using each of the new directional movements
## Summary of the Pull Request
Fixes the serialisation of the findMatch action so that the direction is stored.
## PR Checklist
* [x] Closes#11225
* [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
Added a test and tested manually.
This PR simply replaces all uses of "TrayIcon" and "Tray" with "NotificationIcon" and "NotificationArea" to be more accurate. Originally I kinda wanted to only replace all occurrences of it in settings and user facing things, but I figured I might as well make it consistent throughout all of our code.
Fix infinite loop when trying to summon a window after close.
In #10972 code was added to try to clean up state manually when a window
was closed instead of waiting for it to be detected as a dead peasant.
Unfortunately I didn't know any better and missed cleaning up
`_mruPeasants` as well. The result is there would be an infinite loop
in `_getMostRecentPeasant` since `_getPeasant` will only clean up ids if
it finds a peasant, not if it doesn't find anything. This is the minimal
change to get this working, but it might be a good idea to make
`_getPeasant` be more thorough about cleanup.
## Validation Steps Performed
Tested that before the change we infinitely loop, and after the change
we summon correctly.
Closes#11215
This pull request moves us to Microsoft.Windows.CppWinRT 2.0.210825.3.
Notable improvements from 2.0.210309.3:
* Restored Windows 7 functionality
* C++20 ranges support
* `capture` now works with a raw pointer
* `hstring::starts_with` and `hstring::ends_with` (C++20)
Unit/Functional Tests:
Summary: Total=7728, Passed=7571, Failed=10, Blocked=0, Not Run=0, Skipped=147
Local Tests:
Summary: Total=163, Passed=158, Failed=5, Blocked=0, Not Run=0, Skipped=0
The above failures are (1) in UIA tests for conhost/WT (which do not work here) or
(2) in already known-broken local tests.
## Summary of the Pull Request
Basically undoes #10988 in favour of implementing it as described in #11018
## PR Checklist
* [x] Closes#11018
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [X] 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: #xxx
* [X] Schema updated.
* [x] I work here
## Validation Steps Performed
- alt+space opens the system menu by default
- when alt+space is bound, the keys do not get send to terminal
- right-click on the tab bar didn't break (still opens system menu at the location of the cursor)
## Summary of the Pull Request
* Introduces info bar shown upon session failure,
that guides the user how to configure termination behavior
* Allows this info bar to be dismissed permanently (choice stored in state)
* Allows "keyboard service" info bar to be dismissed permanently
## PR Checklist
* [x] Closes#10798, #8699
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
UI:
* Introduce an additional info bar for "close on exit" configuration tip
* Stack this bar after "keyboard service" bar
* Add "Don't show again" button to both bars
Dismiss Permanently:
* Introduce a set of "dismissed messages" to the Application State
* Add verification the message is not dismissed before showing an info bar
* "Don't show again" persists the choice under "dismissed messages"
Wiring the Info Bar:
* Register `TerminalPage` on `TermControl`'s `ConnectionStateChanged` event
* Once event is triggered check whether the state is failure
* If so and the message was not dismissed permanently, show the info bar
Add the ability to quit all terminal instances. Doing this separately from the window layout saving ones to lessen the number of 1k+ line monsters I make y'all review.
## References
#11083
## PR Checklist
* [x] Closes#11081
* [ ] 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.
## Detailed Description of the Pull Request / Additional comments
- Warn the user before they do so to give a chance to cancel
- Percolate a QuitAll event up to the monarch who then directs each peasant to clsoe.
- Leave a window-layout-saving-sized hole to add that feature on top
## Validation Steps Performed
- quit with one window (from the monarch)
- quit from the monarch with multiple windows
- quit from a peasant
- cancel the quit dialog
This PR adds support for the `DECRQSS` (Request Selection or Setting)
escape sequence, which is a standard VT query for reporting the state of
various control functions. This initial implementation only supports
queries for the `DECSTBM` margins, and the `SGR` graphic rendition
attributes.
This can be useful for certain forms of capability detection (#1040). As
one example in particular, it can serve as an alternative to the
`COLORTERM` environment variable for detecting truecolor support
(#11057).
Of the settings that can be queried by `DECRQSS`, the only other one
that we could be supporting at the moment is `DECSCUSR` (Cursor Style).
However, that would require passing the query through to the conpty
client, which is a lot more complicated, so I thought it best to leave
for a future PR.
For now this gets the basic framework in place, so we are at least
responding to queries, and even just supporting the `SGR` attributes
query is useful in itself.
Validation
----------
I've added a unit test verifying the reports for the `DECSTBM` and `SGR`
settings with a range of different parameters. I've also tested the
`DECSTBM` and `SGR` reports manually in _Vttest_, under menu 11.2.5.3.6
(Status-String Reports).
This commit adds initial support for saving window layout on application
close.
Done:
- Add user setting for if tabs should be maintained.
- Added events to track the number of open windows for the monarch, and
then save if you are the last window closing.
- Saves layout when the user explicitly hits the "Close Window" button.
- If the user manually closed all of their tabs (through the tab x
button or through closing all panes on the tab) then remove any saved
state.
- Saves in the ApplicationState file a list of actions the terminal can
perform to restore its layout and the window size/position
information.
- This saves an action to focus the correct pane, but this won't
actually work without #10978. Note that if you have a pane zoomed, it
does still zoom the correct pane, but when you unzoom it will have a
different pane selected.
Todo:
- multiple windows? Right now it can only handle loading/saving one
window.
- PR #11083 will save multiple windows.
- This also sometimes runs into the existing bug where multiple tabs
appear to be focused on opening.
Next Steps:
- The business logic of when the save is triggered can be adjusted as
necessary.
- Right now I am taking the pragmatic approach and just saving the state
as an array of objects, but only ever populate it with 1, that way
saving multiple windows in the future could be added without breaking
schema compatibility. Selfishly I'm hoping that handling multiple
windows could be spun off into another pr/feature for now.
- One possible thing that can maybe be done is that the commandline can
be augmented with a "--saved ##" attribute that would load from the
nth saved state if it exists. e.g. if there are 3 saved windows, on
first load it can spawn three wt --saved {0,1,2} that would reopen the
windows? This way there also exists a way to load a copy of a previous
window (if it is in the saved state).
- Is the application state something that is planned to be public/user
editable? In theory the user could since it is just json, but I don't
know what it buys them over just modifying their settings and
startupActions.
Validation Steps Performed:
- The happy path: open terminal -> set setting to true -> close terminal
-> reopen and see tabs. Tested with powershell/cmd/wsl windows.
- That closing all panes/tabs on their own will remove the saved
session.
- Open multiple windows, close windows and confirm that the last window
closed saves its state.
The generated file stores a sequence of actions that will be executed to
restore the terminal to its saved form.
References #8324
This is also one of the items on microsoft/terminal#5000Closes#766
## Summary of the Pull Request
Make sure to always synchronously set the selected tab. This way when changing tabs while running multiple actions further calls to _GetFocusedTab will return the correct one.
**Edit** #11146 discovered while trying to test this so while I fixed the case I wanted, things seem to be broken generally so it is hard for me to test if I broke anything else.
## References
## PR Checklist
* [x] Closes#11107
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Validation Steps Performed
Ran the command specified in the issue and confirmed that the correct tab was focused and that the correct pane was zoomed.
## Summary of the Pull Request
Disables autocorrect for command, path and find text inputs. Does not disable it for profile names, tab titles or colour scheme names.
## PR Checklist
* [x] Closes#11133
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Validation Steps Performed
Manually typed `bash -i -l` into the profile command text input and found it no longer auto-capitalised the I.
## Summary of the Pull Request
This adds a new action, `clearBuffer`. It accepts 3 values for the `clear` type:
* `"clear": "screen"`: Clear the terminal viewport content. Leaves the scrollback untouched. Moves the cursor row to the top of the viewport (unmodified).
* `"clear": "scrollback"`: Clear the scrollback. Leaves the viewport untouched.
* `"clear": "all"`: (**default**) Clear the scrollback and the visible viewport. Moves the cursor row to the top of the viewport (unmodified).
"Clear Buffer" has also been added to `defaults.json`.
## References
* From microsoft/vscode#75141 originally
## PR Checklist
* [x] Closes#1193
* [x] Closes#1882
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is a bit tricky, because we need to plumb it all the way through conpty to clear the buffer. If we don't, then conpty will immediately just redraw the screen. So this sends a signal to the attached conpty, and then waits for conpty to draw the updated, cleared, screen back to us.
## Validation Steps Performed
* works for each of the three clear types as expected
* tests pass.
* works even with `ping -t 8.8.8.8` as you'd hope.
<!-- 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
Make it so you can navigate pane focus without unzooming.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#7215
* [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
- Slight refactor to bring the MRU pane logic into the `NavigateDirection` function
- The actual zoom behavior was not a problem, the only issue is that because most of the panes weren't in the UI tree I had to disable using the actual sizes. There is nothing wrong with that, since the synthetic sizing is required anyways, but I'm curious what other peoples' thoughts are.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
Remove those imports as they are unnecessary, _template.py_ contains these too but I guess it's fine since it's a template after all
## Summary of the Pull Request
**Naive implementation** of exporting the text buffer of the current pane
into a text file triggered from the tab context menu.
**Disclaimer: this is not an export of the command history,**
but rather just a text buffer dumped into a file when asked explicitly.
## References
Should provide partial solution for #642.
## Detailed Description of the Pull Request / Additional comments
The logic is following:
* Open a file save picker
* The location is Downloads folder (should be always accessible)
* The suggest name of the file equals to the pane's title
* The allowed file formats list contains .txt only
* If no file selected stop
* Lock terminal
* Read all lines till the cursor
* Format each line by removing trailing white-spaces and adding CRLF if not wrapped
* Asynchronously write to selected file
* Show confirmation
As the action is relatively fast didn't add a progress bar or any other UX.
As the buffer is relatively small, holding it entirely in the memory rather than
writing line by line to disk.
<!-- 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 new action that can contain multiple other actions.
<!-- 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
* [x] Closes#3992
* [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
* [x] 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
Creates a shortcut action that allows a list of actions to be specified as arguments. Steals a bunch of the serialization code from my other pr. Overall, because I had the serialization code written already, this was remarkably easy.
I can't think of any combined action to be added to the defaults, so I think this is just a thing for the documentation unless someone else has a good example. I know there are lot of times when the recommended workaround is "make an action with commandline wt.exe ..." and this could be a good replacement for that, but that is all personalized.
I didn't add this to the command line parsing, since the command line is already a way to run multiple actions.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Created a new command, confirmed that "Move right->down" showed up in the command palette, and that running it did the correct behavior (moving right one pane, then down one pane).
```
{
"command": {
"action": "multipleActions",
"name": "Move right->down",
"actions": [
{"action": "moveFocus", "direction": "right" },
{"action": "moveFocus", "direction": "down" },
]
}
}
```
The first time you open commandline mode, `recentCommands` doesn't exist yet. However, we immediately try to read the `Size()` in a couple places. This'll A/V and we'll crash 😨
The fix is easy - don't try and read the size of the non-existent `recentCommands`
Found this while playing with #11069
Regressed in #11030
Didn't bother filing an issue for it when I have the fix in hand
This is on me. When I got rid of the `_updatePatternLocations` `ThrottledFunc` in the `TermControl`, I didn't add a matching call to `_updatePatternLocations->Run()` in this method.
In #9820, in `TermControl::_ScrollPositionChanged`, there was still a call to `_updatePatternLocations->Run();`. (TermControl.cpp:1655 on the right) https://github.com/microsoft/terminal/pull/9820/files#diff-c10bb023995e88dac6c1d786129284c454c2df739ea547ce462129dc86dc2697R1654#10051 didn't change this
In #10187 I moved the `_updatePatternLocations` throttled func from termcontrol to controlcore. Places it existed before:
* [x] `TermControl::_coreReceivedOutput`: already matched by ControlCore::_connectionOutputHandler
* [x] `TermControl::_ScrollbarChangeHandler` -> added in c20eb9d
* [x] `TermControl::_ScrollPositionChanged` -> `ControlCore::_terminalScrollPositionChanged`
## Validation Steps Performed
Print a URL, scroll the wheel: it still works.
Closes#11055
This commit adds the ability to target the first pane in the tree,
always.
I wasn't able to find an existing issue for this, it is just a personal
feature for me. I won't be heartbroken if it does not get merged.
As motivation, I frequently have setups where the thing I am primarily
working on is a large pane on the left and everything else is in smaller
panes positioned elsewhere. I like to have one hotkey where I can go to
any pane and then make it the "primary" pane if I am changing what I am
working on or need to focus on another set of code/documentation/etc.
## Validation Steps Performed
Confirmed that the move focus and swap pane variants both affect the
correct pane.
When moving a pane to a new tab previously we removed the event handlers
on it as if we were closing it, but we are just moving it so we need to
keep them.
I tried really hard to make sure all of the events were hooked up
correctly, but I guess I missed these originally since they are normally
created in the Pane constructor.
Closes#11035
## Validation Steps Performed
created panes, moved them to new tabs, confirmed that they close and
ding appropriately.
This pull request introduces our first use of the "base" profile as an
actual profile. Incoming commandlines from `wt foo` *and* default
terminal handoffs will be hosted in the base profile.
**THIS IS A BREAKING CHANGE** for user behavior.
The original behavior where commandlines were hosted in the "default"
profile (in most cases, Windows PowerShell) led to user confusion: "why
does cmd use my powershell icon?" and "why does the title say
PowerShell?". Making this change unifies the user experience so that we
can land commandline detection in #10952.
Users who want the original behavior can get it back for commandline
invocation by specifying a profile using the `-p` argument, as in `wt -p
PowerShell -- cmd`.
As a temporary stopgap, users who attempt to duplicate the base profile
will get their specified default profile until we land #5047.
This feature is hidden behind the same feature flag that controls the
visibility of base/"Defaults" in the settings UI.
Fixes#10669
Related to #6776
Only focus if there is a control to focus (which may be null if e.g. the focused tab is being destroyed)
Closes#11037
## Additional comments
I tried to remove the _activePane = nullptr in `TerminalTab::DetachPane` but that actually completely broke being able to focus the control at all making the tab completely unusable. Focus does seem to transfer just fine here with this change.
## Validation Steps Performed
Used the command execution to move panes to and from existing panes, including new tabs and destroying tabs.
- When deciding whether to call `_AnalyzeFontFallback`, also check if the user set any font axes
- Do not use the user set weight if we are setting the weight due to the bold attribute
- When calling `FontFaceWithAttribute`, check if the user set the italic axis as well as the text attribute
* [x] Closes#10852
* [x] Closes#10853
It was insufficient to only promote commandline components to titles
during commandline parsing, because we also have a whole complement of
actions that contain NewTerminalArgs. The tests caught me out a little
too late (sorry!). I decided it was better move promotion down to
TerminalSettings.
Fixes#6776
Re-implements #10998
During startup we do not have real dimensions, so we have to guess what
our dimensions should be based off of the splits.
We'll augment the state of the pane search to also have a size in each
dimension that gets incrementally upgraded as we recurse through the
tree.
References #10978
If both of the following are true
1. alt+space is not explicitly unbound
2. alt+space is not bound to a command
Then the window procedure will handle the alt+space to open up the context menu.
In this case, we need to make sure we don't send the keys to terminal.
Closes#10935
## Summary of the Pull Request
Follow-up for #10886. The new UIA movement tests found some failing cases. This PR fixes UiaTextRangeBase to have movement match that of MS Word. In total, this fixes 64 tests.
## PR Checklist
* [X] Closes#10924
* [X] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
Root causes include...
1. if we were a non-degenerate range and we failed to move, we should still expand to enclose the unit
2. non-degenerate ranges are treated as if they already encompassed their given unit.
- this one is a bit difficult to explain. Consider these examples:
1. document movement
- state: you have a 1-cell wide range on the buffer, and you try to move by document
- result: move by 0 (there is no next/prev document), but the range now encompasses the entire document
2. line movement
- state: you have a 1-cell wide range on a line, and you try to move back by a line
- result: you go to the previous line (not the beginning of this line)
- conversely, a degenerate range successfully moves to the beginning/end of the current unit (i.e. document/line)
- this (bizarre) behavior was confirmed using MS Word
As a bonus, occasionally, Narrator would get stuck when navigating by line. This issue now seems to be fixed.
## Updates to existing tests
- `CanMoveByCharacter`
- `can't move backward from (0, 0)` --> misauthored, result should be one character wide.
- `can't move past the last column in the last row` --> misauthored and already covered in generated tests
- `CanMoveByLine`
- `can't move backward from top row` --> misauthored, end should be on next line. Already covered by generated tests
- `can't move forward from bottom row` --> misauthored, end should be on next line
- `can't move backward when part of the top row is in the range` --> misauthored, should expand
- `can't move forward when part of the bottom row is in the range` --> misauthored, degenerate range moves to end of buffer
- `MovementAtExclusiveEnd`
- populate the text buffer _before_ we do a move by word operation
- update to match the now fixed behavior
This PR converts the WSL distro generator to use the registry to lookup
WSL distros instead of trying to parse the results of `wsl.exe`.
`wsl.exe` sometimes takes a very long time to launch the WSL service,
which means that on the first launch of the Terminal, WSL distros can
sometimes be missing entirely!
## References
* Also related is #6160, but I feel that deserves a separate PR for
warning when the default profile is a dynamic profile who's source
indicated it was gone.
## PR Checklist
* [x] Closes#9905
* [x] Closes#7199
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is maybe a little BODGY, but hey we get tons of reports of this
root cause.
## Validation Steps Performed
Ran it locally, it did well. Ran a `wsl --shutdown`, then booted the
terminal - seemed to do well. I never was able to repro the slowness
myself, but I'd suspect this'll fix it.
## Summary of the Pull Request
Since the days immemorial of the Terminal, the TermControl has auto-focused itself when it finalizes its layout. This has led to the problem that `wt ; sp ; sp ; sp...` ends up focusing one of these panes at random.
This PR fixes this issue by getting rid of the auto-focusing. Panes now manually get focused when created. We manually focus the active pane when a commandline is dispatched. since we're internally tracking "active" separate from "focused", this ends up working as you'd hope.
## References
## PR Checklist
* [x] Closes#6586
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I also had to turn the cursor off by default. Most `TermControl`s would never get the `LostFocus` event, so their cursors would get left `On`, and that's not right.
## Validation Steps Performed
I've run the following things a bunch of times to make sure they work:
* `wtd sp ; sp ; sp`
* `wtd sp ; sp ; sp ; fp -t 0`
* `newTab`
* `splitPane`
* use the command palette to do the above as well
Where the result used to be random (cases 1 & 2), the result is exactly what you'd expect now.
It doesn't work at all for
```
wtd sp ; sp ; sp ; mf left
```
Presumably because we can't `move-focus` directionally during startup. However, that doesn't work _today_ either, so it's not making it worse. Just highlights that single scenario doesn't work right.
* Perform the handling of partial code points in the `u8u16` and `u16u8`
conversion functions without preparation in a preliminary buffer.
* Simplify partials handling in `u8u16` (perf).
* Declare the parameters for the incoming data as referenced
string_views.
* Simplify templatization.
* Simplify exception handling.
We complete the partial codepoint in the 4-bytes long cache and convert
it separately. This makes the cache ready for capturing the next
partials before the remaining string is converted. This way, we neither
need to copy the whole string into a buffer which contains complete
codepoints, nor do we need to allocate an unnecessarily long buffer
which exists for the life time of the state class instance.
Finding and capturing of partials is performed in a more linear code
using the evaluation of the length of a code point.
The parameters for the incoming data are now explicitely declared to be
referenced string_views.
`CATCH_RETURN` is used to improve the readability of the code.
## Validation Steps Performed
* manually tested
* unit tests passed
Closes#10946
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Re-enables the delete button for generated profiles in the settings UI.
Additionally fixes "Startup Profiles" to only list active profiles.
Profiles are considered deleted if they're absent from settings.json, but their
GUID has been encountered before. Or in other words, from a user's perspective:
Generated profiles are added to the settings.json automatically only once.
Thus if the user chooses to delete the profile (e.g. using the delete button)
they aren't re-added automatically and thus appear to have been deleted.
Meanwhile those generated profiles are actually only marked as "hidden"
as well as "deleted", but still exist in internal profile lists.
The "hidden" attribute hides them from all existing menus. The "deleted" one
hides them from the settings UI and prevents them from being written to disk.
It would've been preferrable of course to just not generate and
add deleted profile to internal profile lists in the first place.
But this would've required far more wide-reaching changes.
The settings UI for instance requires a list of _all_ profiles in order to
allow a user to re-create previously deleted profiles. Such an approach was
attempted but discarded because of it's current complexity overhead.
## References
* Part of #9997
* A sequel to 5d36e5d
## PR Checklist
* [x] Closes#10960
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* "Startup Profiles" doesn't list deleted profiles ✔️
* Manually removing an item from settings.json removes the profile ✔️
* Removing cmd.exe and saving doesn't create empty objects (#10960) ✔️
* "Add a new profile" lists deleted profiles ✔️
* "Duplicate" recreates previously deleted profiles ✔️
* Profiles are always created with GUIDs ✔️
The original code for settings reload iterated the entire tree of panes
for every profile in the new settings (O(mn)) and constructed a
TerminalSettings object for every profile even if it later went unused.
This implementation:
1. Collects all new profiles keyed by guid
1.a. Adds the "defaults" profile to the map
2. Iterates every pane, just once, and updates its profile if it shows
up in the list by GUID.
I've merged all of the per-tab code into a single loop.
Because of 1.a., this code can now update panes that are hosting the
"base" profile.
Right now, we store GUIDs in panes and most of the functions for interacting
with profiles on the settings model take GUIDs and look up profiles.
This pull request changes how we store and look up profiles to prefer profile
objects. Panes store strong references to their originating profiles, which
simplifies settings lookup for CloseOnExit and the bell settings. In fact,
deleting a pane's profile no longer causes it to forget which CloseOnExit
setting applies to it. Duplicating a pane that is hosting a deleted profile
(#5047) now duplicates the profile, even though it is otherwise unreachable.
This makes the world more consistent and allows us to _eventually_ support panes
hosting profiles that do not have GUIDs that can be looked up in the profile
list. This is a gateway to #6776 and #10669, and consolidating the profile
lookup logic will help with #10952.
PR #10588 introduced TerminalSettings::CreateWithProfile and made
...CreateWithProfileByID a thin wrapper over top it, which looked up the profile
by GUID before proceeding. It has also been removed, as its last caller is gone.
Closes#5047
This supports a future world where we give commandline-only invocations
their own tabs. It was easier to promote the commandline to a title at
the time of argument parsing, rather than later, but I am happy to
change this if anyone disagrees.
Add support for acrylic in the titlebar
## PR Checklist
* [x] CLA signed
## Detailed Description of the Pull Request / Additional comments
This seems to be a highly requested feature and seeing as #5772 was closed I thought it made sense to make a PR for this.
## Validation Steps Performed
Checked that acrylic works in both dark and light modes and switching between them still works. Also checked that acrylic in the tab row still works when tabs in titlebar is disabled.
Currently, the monarch window will show itself when opening the tray icon context menu. This is because a window must be set as the foreground window when the context menu opens, otherwise the menu won't be able to be dismissed when clicking outside of the context menu.
This PR makes the tray icon create a non visible/interactable window for the sole purpose of being set as the foreground window when the tray icon's context menu is opened. Then none of the terminal windows should be set as the foreground window when opening the context menu.
Closes#10936
## Summary of the Pull Request
Pretty straightforward. Check if the scroll event is a horizontal movement. If it is, ignore it. We don't have a horizontal scrollbar.
## References
* obviously, revisit this if we ever do #1860
## PR Checklist
* [x] Closes#10329
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* scrolled ↑/↓ with slaptop trackpad: terminal scrolls.
* scrolled ←/→ with slaptop trackpad: terminal doesn't scroll.
* Scrolling _slightly more vertically than horizontally_ still scrolls.
* Scrolling _slightly more horizontally than vertically_ doesn't scroll.
When our text buffer is full, newlines cause the buffer to scroll underneath the viewport (rather than the viewport moving down). This was causing selections made during text output to scroll down. To solve this, when we increment the circular buffer, we decrement the y-coordinates of the current selections by 1. We also invalidate the previous selection rects.
Closes#10319
This commit moves us from MUX 2.5 to MUX 2.6. I have temporarily
disabled the new control styles in `TerminalApp\App.xaml` by setting
`ControlsResourcesVersion` to `Version1`. There is no significant expected
visual impact.
Closes#10508
This commit partially reverts d465a47 and introduces an alternative approach by adding Hash and Equals methods to the KeyChords class. Those methods will now favor any existing Vkeys over ScanCodes.
## PR Checklist
* [x] Closes#10933
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Added a new test, which is ✔️
* Various standard commands still work ✔️
* Hash() returns the same value for all KeyChords that are Equals() ✔️
Introduces a new methodology to maintain tests for UI Automation. This includes...
- `UiaTests.csv`: an excel spreadsheet designed to store UIA movement tests in a compact format
- `GeneratedTests.ps1`: a PowerShell script that imports `UiaTests.csv` and outputs a C++ TEST_METHOD for `UiaTextRangeTests.
This new system can be used to easily add more UIA movement tests.
Read https://github.com/microsoft/terminal/blob/dev/cazamor/a11y-7000/testing/tools/TestTableWriter/README.md for more details.
Follow-up work items:
- #10924 **Failing Tests**: this found some failing tests. We should make them not fail.
- #10925 **Missing Tests: Word navigation**: Word navigation is missing.
- #10926 **MoveEndpoint Tests**: an additional column can be added to the CSV "EndpointTarget", which can be "start", "end", or "both". This will allow us to test `MoveEndpoint` in addition to `Move`.
Some followups to #10368:
- Accidentally reverted a defapp change where the Monarch should not by default register itself as a handoff server.
- Destroy the tray icon if we're a monarch otherwise if we're a quake window we request the monarch to hide the icon.
When creating `startupAction` use `TabSwitcherMode::Disabled` in action args
to disable the tab switcher and prevent MRU logic to be applied.
Closes#10070
## Summary of the Pull Request
The bug was that Narrator would still read the content of the old tab/pane although a new tab/pane was introduced. This is caused by the automation peer not being created when XAML requests it. Normally, we would prevent the automation peer from being created if the terminal was not fully initialized.
This change allows the automation peer to be created regardless of the terminal being fully initialized by...
- `TermControl`: `_InitializeTerminal` updates the padding (dependent on the `SwapChainPanel`) upon full initialization
- `ControlCore`: initialize the `_renderer` in the ctor so that we can attach the UIA Engine before `ControlCore::Initialize()` is called (dependent on `SwapChainPanel` loading)
As a bonus, this also fixes a locking issue where logging would attempt to get the text range's text and lock twice. The locking fix is very similar to #10937.
## PR Checklist
Closes [MSFT 33353327](https://microsoft.visualstudio.com/OS/_workitems/edit/33353327)
## Validation Steps Performed
- New pane from key binding is announced by Narrator
- New tab from key binding is announced by Narrator
Adds new in-order traversal for MoveFocus and SwapPane actions.
Refactors the Pane methods to share a `NavigateDirection`
implementation.
Closes#10909
A large amount of the churn here is just renaming some of the things for
directional movement to reflect that it might not always be based on the
focused pane. `NextPane` and `PreviousPane` are the functions that
actually select the next/previous pane respectively and are the core
component of this PR.
VALIDATION
Created multiple panes on a tab, and tried both forward and backwards
movements with move-focus and swap-pane.
## Summary of the Pull Request
This adds a new setting `intenseTextStyle`. It's a per-appearance, control setting, defaulting to `"all"`.
* When set to `"all"` or `["bold", "bright"]`, then we'll render text as both **bold** and bright (1.10 behavior)
* When set to `"bold"`, `["bold"]`, we'll render text formatted with `^[[1m` as **bold**, but not bright
* When set to `"bright"`, `["bright"]`, we'll render text formatted with `^[[1m` as bright, but not bold. This is the pre 1.10 behavior
* When set to `"none"`, we won't do anything special for it at all.
## references
* I last did this in #10648. This time it's an enum, so we can add bright in the future. It's got positive wording this time.
* ~We will want to add `"bright"` as a value in the future, to disable the auto intense->bright conversion.~ I just did that now.
* #5682 is related
## PR Checklist
* [x] Closes#10576
* [x] I seriously don't think we have an issue for "disable intense is bright", but I'm not crazy, people wanted that, right? https://github.com/microsoft/terminal/issues/2916#issuecomment-544880423 was the closest
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/381
## Validation Steps Performed
<!--  -->
Yea that works. Printed some bold text, toggled it on, the text was no longer bold. hooray.
### EDIT, 10 Aug
```json
"intenseTextStyle": "none",
"intenseTextStyle": "bold",
"intenseTextStyle": "bright",
"intenseTextStyle": "all",
"intenseTextStyle": ["bold", "bright"],
```
all work now. Repro script:
```sh
printf "\e[1m[bold]\e[m[normal]\e[34m[blue]\e[1m[bold blue]\e[m\n"
```
## Summary of the Pull Request
BODGY!
This solution was suggested in https://github.com/microsoft/microsoft-ui-xaml/issues/4554#issuecomment-887815332.
When the window moves, or when a ScrollViewer scrolls, dismiss any popups that are visible. This happens automagically when an app is a real XAML app, but it doesn't work for XAML Islands.
## References
* upstream at https://github.com/microsoft/microsoft-ui-xaml/issues/4554
## PR Checklist
* [x] Closes#9320
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Unfortunately, we've got a bunch of scroll viewers in our SUI. So I did something bodgyx2 to make our life a little easier.
`DismissAllPopups` can be used to dismiss all popups for a particular UI element. However, we've got a bunch of pages with scroll viewers that may or may not have popups in them. Rather than define the same exact body for all their `ViewChanging` events, the `HasScrollViewer` struct will just do it for you!
Inside the `HasScrollViewer` stuct, we can't get at the `XamlRoot()` that our subclass implements. I mean, _we_ can, but when XAML does it's codegen, _XAML_ won't be able to figure it out.
Fortunately for us, we don't need to! The sender is a UIElement, so we can just get _their_ `XamlRoot()`.
So, you can fix this for any SUI page with just a simple
```diff
- <ScrollViewer>
+ <ScrollViewer ViewChanging="ViewChanging">
```
```diff
- struct AddProfile : AddProfileT<AddProfile>
+ struct AddProfile : public HasScrollViewer<AddProfile>, AddProfileT<AddProfile>
```
## Validation Steps Performed
* the window doesn't close when you move it
* the popups _do_ close when you move the window
* the popups close when you scroll any SUI page
Let's say a user doesn't know that they need to write `"hidden": true` in
order to prevent a profile from showing up (and a settings UI doesn't exist).
Naturally they would open settings.json and try to remove the profile object.
This section of code recognizes if a profile was seen before and marks it as
`"hidden": true` by default and thus ensures the behavior the user expects:
Profiles won't show up again after they've been removed from settings.json.
## References
#8324 - Application State
## PR Checklist
* [x] Closes#8270
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* settings.json/state.json are created if they don't exist ✔️
* Removing any profile from settings.json doesn't cause it to appear again ✔️
* Hitting save in SUI creates profiles with `"hidden": true` ✔️
* Removing a default profile and hitting save in SUI works ❌
An empty object is added instead.
Fixes a bug where interacting with Windows Terminal when using Narrator causes Windows Terminal to hang.
`UiaTextRangeBase::Move()` locks, but later calls `UiaTextRangeBase::ExpandToEnclosingUnit()` which attempts to lock again. The workaround for this is to introduce a `_expandToEnclosingUnit()` that _does not_ lock the console. Then, `Move()` calls this new method, thus only allowing one lock to be established at a time.
This bug is observed to be in v1.11.2221.0 and _not_ in v1.9.1942.0.
A brief summary of the behavior of the tray icon:
- There will only ever be one tray icon representing all windows.
- Left-Click on a Tray Icon brings up the MRU window.
- Right-Click on a Tray Icon brings up a Context Menu:
```
Focus Terminal
----------------
Windows --> Window ID 1 - <unnamed window>
Named Window
Named Window Again
```
- Focus Terminal will bring up the MRU window.
- Clicking on any of the Window "names" in the submenu will summon the window.
## Settings Changes
Two new global settings are introduced: `alwaysShowTrayIcon` and `minimizeToTray`. Here's a chart explaining the behavior with the two settings.
| | `alwaysShowTrayIcon:true` | `alwaysShowTrayIcon:false` |
|----------------------|------------------------------------------------------------------|------------------------------------------------------------------|
| `minimizeToTray:true` | tray icon is always shown. minimize button will hide the window. | tray icon is always shown. minimize button will hide the window. |
| `minimizeToTray:false` | tray icon is always shown. | tray icon is not shown ever. |
Closes#5727
## References
[Spec for Minimize to Tray](https://github.com/microsoft/terminal/blob/main/doc/specs/%23653%20-%20Quake%20Mode/%23653%20-%20Quake%20Mode.md#minimize-to-tray)
Docs PR - MicrosoftDocs/terminal#352
#10448 - My list of TODOs
Improve WriteCharsLegacy performance by increasing LocalBuffer size, allowing
longer runs of characters to be submitted to the remaining parts of conhost.
References #10563 -- vtebench tracking issue
## Validation Steps Performed
* Ran `cat big.txt`, vtebench and termbench and
noted ~5% performance improvements
WriteUTF8FileAtomic overrides the content of the file "atomically"
by creating a temp file and then renaming it to the original path.
The problem arises when the original path is symbolic link,
as the link itself gets overridden by a file (rather than the link target).
This PR introduces a special handling of the symlinks:
if the path as a symlink we resolve the path and use:
1. target's directory to create a temp-file in
2. target itself to be replaced with the tempfile.
Symlink resolution is problematic when the target path does not exist,
as there is no good utility that resolves such link (canonical() fails).
In this corner case we skip the "atomic" approach of renaming the file
and write the link target directly.
Closes#10787
<!-- 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 functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#7075
* [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: #xxx
* [x] 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
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
The quake mode keybinding is bound to a scancode. This made it
impossible to override it with a vkey-based one like "win+\`".
This commit fixes the issue by making sure that a `KeyChord` always has a vkey,
and leveraging this fact inside ActionMap, which now ignores the scan-code.
## PR Checklist
* [x] Closes#10875
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* quake mode and other keybinding still work ✔️
* Repro settings from #10875 work correctly ✔️
## Summary of the Pull Request
This isn't a fix for #10875, but it is logging that help identify the root cause here. The logging may additionally be helpful for some of the other issues we're seeing elsewhere in the repo, namely #10340.
@lhecker is actually working on the fix for #10875, so hopefully this test will help validate.
## References
* Regressed in #10666.
* logging for #8888
## PR Checklist
* [x] Closes nothing
* [x] I work here
* [x] Tests added, and they absolutely fail, but they're localtests, so ¯\\\_(ツ)_/¯
* [n/a] Requires documentation to be updated
## details
While I was here, I noticed that `KeyBindingsTests::KeyChords` has been broken for some time now. So I fixed that too.
My first approach to solve #10875 failed.
This PR contains the most useful change as a separate commit.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* quake mode keybinding works ✔️
* command palette still works ✔️
## Summary of the Pull Request
This was missed in #10051. We need to make sure that the UIA provider can immediately know about the padding in the control, not just after the settings reload.
## PR Checklist
* [x] Closes #9955.e
* [x] Additionally, this just closes#9955. The only remaining box in there never repro'd, so probably wasn't even root caused by #9820. I think we can close that issue for now, and reactivate if something else was broken.
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Checked before/after in Accessibility Insights. Before the row rectangles were the full width of the control initially. Now they're properly padded.
<!-- 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 implements/solves #7125. Concretely: two requests regarding alt+space were posted there:
1. Disabling the alt+space menu when the keychord explicitly unbound - and forwarding the keystroke to the terminal
2. Disabling the alt+space menu when the keychord is bound to an action
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
Not that I know
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#7125
* [x] CLA signed.
* [x] Tests added/passed
* [x] Documentation updated. N/A
* [x] 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.
The issue was marked Help-Wanted. I am happy to change the implementation to better fit your (planned) architecture.
<!-- 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
While researching the solution, I noticed that the XAML system was always opening the system menu after Alt+Space, even when explicitly setting the event to be handled according to the documentation. The only solution I could find was to hook into the "XAML bypass" already in place for F7 KeyDown, and Alt KeyUp keystrokes. This bypass sends the keystroke to the AppHost immediately. This bypass method will "fall back" to the normal XAML routing when the keystroke is not handled.
The implemented behaviour is as follows:
- Default: same as normal; system menu is working since the bypass does not handle the keystroke
- Alt+Space explicitly unbound: bypass passes the keystroke to the terminal and marks it as handled
- Alt+Space bound to command: bypass invokes the command and marks it as handled
Concretely, added a method to the KeyBindings and ActionMap interfaces to check whether a keychord is explicitly unbound. The implementation for `_GetActionByKeyChordInternal` already distinguishes between explicitly unbound and lack of binding, however this distinction is not carried over to the public methods. I decided not to change this existing method, to avoid breaking other stuff and to make the API more explicit.
Furthermore, there were some checks against Alt+Space further down in the code, preventing this keystroke from being entered in the terminal. Since the check for this keystroke is now done at a "higher" level, I thought I could safely remove these checks as otherwise the keystroke could never be sent to the terminal itself. Please correct me if I'm wrong.
Note that when alt+space is bound to an action that opens the command pallette (such as tab search), then a second press of the key combination does still open the system menu. This is because at that point, the "bypass" is cancelled (called "not a good implementation" in #4031). I don't think this can easily be solved for now, but this is a very minor bug/inconvenience.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Added tests for the new method. Performed manual checking:
* [x] Default configuration still opens system menu like normal
* [x] Binding alt+space to an action performs the action and does not show the system menu
* [x] Explicitly unbinding alt+space no longer shows the system menu and sends the keystroke to the terminal. I was unable to run the debug tap (it crashed my instance - same thing happening on preview and release builds) to check for sure, but behaviour was identical to native linux terminals.
## Summary of the Pull Request
This PR causes the Terminal to combine taskbar states at the tab and window level, according to the [MSDN docs for `SetProgressState`](https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-itaskbarlist3-setprogressstate#how-the-taskbar-button-chooses-the-progress-indicator-for-a-group).
This allows the Terminal's taskbar icon to continue showing progress information, even if you're in a pane/tab that _doesn't_ have progress state. This is helpful for cases where the user may be running a build in one tab, and working on something else in another.
## References
* [`SetProgressState`](https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-itaskbarlist3-setprogressstate#how-the-taskbar-button-chooses-the-progress-indicator-for-a-group)
* Progress mega: #6700
## PR Checklist
* [x] Closes#10090
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This also fixes a related bug where transitioning from the "error" or "warning" state directly to the "indeterminate" state would cause the taskbar icon to get stuck in a bad state.
## Validation Steps Performed
<details>
<summary><code>progress.cmd</code></summary>
```cmd
@echo off
setlocal enabledelayedexpansion
set _type=3
if (%1) == () (
set _type=3
) else (
set _type=%1
)
if (%_type%) == (0) (
<NUL set /p =]9;4
echo Cleared progress
)
if (%_type%) == (1) (
<NUL set /p =]9;4;1;25
echo Started progress (normal, 25^)
)
if (%_type%) == (2) (
<NUL set /p =]9;4;2;50
echo Started progress (error, 50^)
)
if (%_type%) == (3) (
@rem start indeterminate progress in the taskbar
@rem this `<NUL set /p =` magic will output the text _without a newline_
<NUL set /p =]9;4;3
echo Started progress (indeterminate, {omitted})
)
if (%_type%) == (4) (
<NUL set /p =]9;4;4;75
echo Started progress (warning, 75^)
)
```
</details>
## Summary of the Pull Request
Apparently the exception handler in TerminalApi is far too talkative. We're apparently throwing in `TerminalApi::CursorLineFeed` way too often, and that's caused an internal bug to be filed on us.
This represents making the event less talkative, but doesn't actually fix the bug. It's just easier to get the OS bug cleared out quick this way.
## References
* MSFT:33310649
## PR Checklist
* [x] Fixes the **A** portion of #10882, which closes MSFT:33310649
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Summary of the Pull Request
Turns out, we'd only ever use the non-client size to calculate the size of the window, but not the actual position. As we learned in #10676, the nonclient area extends a few pixels past the visible borders of the window.
## PR Checklist
* [x] Closes#10583
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* [x] Works with the `IslandWindow`
* [x] Works with the `NonClientIslandWindow`
## Summary of the Pull Request
Do not invoke terminal resize logic if view port dimensions didn't change
## PR Checklist
* [x] Closes#10857
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
Short-circuit `ControlCore::_doResizeUnderLock` if the dimensions of the
required view port are equal to the dimensions of the current view port
#### ⚠️ targets #10051
## Summary of the Pull Request
This updates our `ThrottledFunc`s to take a dispatcher parameter. This means that we can use the `Windows::UI::Core::CoreDispatcher` in the `TermControl`, where there's always a `CoreDispatcher`, and use a `Windows::System::DispatcherQueue` in `ControlCore`/`ControlInteractivity`. When running in-proc, these are always the _same thing_. However, out-of-proc, the core needs a dispatcher queue that's not tied to a UI thread (because the content proces _doesn't have a UI thread!_).
This lets us get rid of the output event, because we don't need to bubble that event out to the `TermControl` to let it throttle that update anymore.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] This is a part of #1256
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Fortunately, `winrt::resume_foreground` works the same on both a `CoreDispatcher` and a `DispatcherQueue`, so this wasn't too hard!
## Validation Steps Performed
This was validated in `dev/migrie/oop/the-whole-thing` (or `dev/migrie/oop/connection-factory`, I forget which), and I made sure that it worked both in-proc and x-proc. Not only that, _it wasn't any slower_!This reverts commit 04b751faa7.
This PR adds conhost support for downloadable soft fonts - also known as
dynamically redefinable character sets (DRCS) - using the `DECDLD`
escape sequence.
These fonts are typically designed to work on a specific terminal model,
and each model tends to have a different character cell size. So in
order to support as many models as possible, the code attempts to detect
the original target size of the font, and then scale the glyphs to fit
our current cell size.
Once a font has been downloaded to the terminal, it can be designated in
the same way you would a standard character set, using an `SCS` escape
sequence. The identification string for the set is defined by the
`DECDLD` sequence. Internally we map the characters in this set to code
points `U+EF20` to `U+EF7F` in the Unicode private use are (PUA).
Then in the renderer, any characters in that range are split off into
separate runs, which get painted with a special font. The font itself is
dynamically generated as an in-memory resource, constructed from the
downloaded character bitmaps which have been scaled to the appropriate
size.
If no soft fonts are in use, then no mapping of the PUA code points will
take place, so this shouldn't interfere with anyone using those code
points for something else, as along as they aren't also trying to use
soft fonts. I also tried to pick a PUA range that hadn't already been
snatched up by Nerd Fonts, but if we do receive reports of a conflict,
it's easy enough to change.
## Validation Steps Performed
I added an adapter test that runs through a bunch of parameter
variations for the `DECDLD` sequence, to make sure we're correctly
detecting the font sizes for most of the known DEC terminal models.
I've also tested manually on a wide range of existing fonts, of varying
dimensions, and from multiple sources, and made sure they all worked
reasonably well.
Closes#9164
`VkKeyScanW` as well as `MapVirtualKeyW` are used throughout
the project, but are input method sensitive functions.
Since #10666 `win+sc(41)` is used as the quake mode keybinding,
which is then mapped to a virtual key in order to call `RegisterHotKey`.
This mapping is highly dependent on the input method and the quake mode
key binding will fail to work once the input method was changed.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#10729
* [x] I work here
* [ ] Tests added/passed
## Validation Steps Performed
* win+` opens quake window before & after changing keyboard layout ✔️
* keyboard layout changes while WT is minimized trigger reloaded ✔️
- Monarch no longer sets itself up as a `CTerminalHandoff` multi instance server by default
- In fact, `CTerminalHandoff` will only ever be a single instance server
- When COM needs a `CTerminalHandoff`, it launches `wt.exe -embedding`, which gets picked up by the Monarch and then gets handed off to itself/peasant depending on user settings.
- Peasant now recognizes the `-embedding` commandline and will start a `CTerminalHandoff` single instance listener, and receives the connection into a new tab.
Closes#10358
<!-- 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
Adds the Split Tab option to the tab context menu.
Clicking this option will `auto` split the active pane of the tab into a duplicate pane.
Clicking on an unfocused tab and splitting it will bring that tab into focus and split its active pane.
We could make this a flyout from the context menu to let people choose horizontal/vertical split in the future if it's requested.
I'm also wondering if this should be called Split Pane instead of Split Tab?
<!-- 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#5025
* [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
https://user-images.githubusercontent.com/48369326/127691919-aae4683a-212a-4525-a0eb-a61c877461ed.mp4
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
When switching from the alt buffer back to the main buffer, we need to copy certain cursor attributes from the one to the other. However, this copying was taking place after the alt buffer had been freed, and thus could result in the app crashing. This PR simply moves that code up a bit so it's prior to the buffer being freed.
## References
PR #10843 added the code that introduced this problem.
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] 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
I was able to reproduce the crash when using a debug build, and confirmed that the crash no longer occurred after this PR was applied. I also checked that the cursor attributes were still being correctly copied back when returning from the alt buffer.
Shortly before adding the SSE2 variant I "improved" it by using
`_mm_packs_epi32`, but failed to test it again afterwards.
## PR Checklist
* [x] Closes#10866
* [x] I work here
## Validation Steps Performed
* `printf "\e[mNORMAL \e[1mBOLD\n"` results in correct bold white glyphs ✔️
## Validation Steps Performed
Clicked around, validated that settings still behave the same (as far as
I can tell with my limited terminal configuration expertise)
Closes#10387
Fixes dragging and dropping drive letters onto the '+' button.
Manually tested - dragging and dropping the `C:\` drive onto the '+' button works when creating a new tab, splitting or creating a new window. Dragging and dropping a regular directory still works.
Closes#10723
<!-- 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 the ability to toggle a pane's split direction
- Switch from horizontal to vertical split (and vice versa)
- Propogate new borders through to children.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#10665
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#10665
* [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
* [x] 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Ran terminal, created multiple panes in different orientations, ran command through command palate and verified that they displayed properly in the new orientation.
When the `SetContoleTitle` API is called with a title containing control
characters, we need to filter out those characters before we can forward
the title change over conpty as an escape sequence. If we don't do that,
the receiving terminal will end up executing the control characters
instead of updating the title. We were already filtering out the C0
control characters, but with this PR we're now filtering out C1 controls
characters as well.
I've simply updated the sanitizing routine in `DoSrvSetConsoleTitleW` to
filter our characters in the range `0x80` to `0x9F`. This is in addition
to the C0 range (`0x00` to `0x1F`) that was already excluded.
## Validation Steps Performed
I've added a conpty unit test that calls `DoSrvSetConsoleTitleW` with
titles containing a variety of C0 and C1 controls characters, and which
verifies that those characters are stripped from the title forwarded to
conpty.
I've also confirmed that the test case in issue #10312 is now working
correctly in Windows Terminal.
Closes#10312
The `_invalidMap` size is dependent on both `clientSize` as well
as `glyphCellSize` and must be resized when either changes.
## PR Checklist
* [x] Closes#10855
* [x] I work here
## Validation Steps Performed
* Changing font size with Ctrl+Mousewheel in fullscreen works ✔️
This commit introduces a hack to ConptyConnection for launching WSL.
When we detect that WSL is being launched (either "wsl" or "wsl.exe",
unqialified or _specifically_ from the current OS's System32 directory),
we will promote the startingDirectory specified at launch time into a
commandline argument.
Why do we want to switch to `--cd`?
With the current design of ConptyConnection and WSL, there are some
significant limitations:
* `startingDirectory` cannot be a WSL path, which forces users to
use weird tricks such as setting the starting directory to
`\\wsl$\Distro\home\user`.
* WSL occasionally fails to launch in time to handle a `\\wsl$` path,
which makes us spawn in a strange location (or no location at all).
(This fix will only address the second one until a WSL update is
released that adds support for `--cd $LINUX_PATH`.)
We will not do the promotion if any of the following are true:
* the commandline contains `--cd` already
* the commandline contains a bare `~`
* This was a commonly-used workaround that forced wsl to start in the
user's home directory. It conflicts with --cd.
* wsl is not spelled properly (`WSL` and `WSL.EXE` are unacceptable)
* an absolute path to wsl outside the system32 directory is provided
We chose the do this trick in the connection layer, the latest possible
point, because it captures the most use cases.
We could have done it earlier, but the options were quite limiting.
They are:
* Generate WSL profiles with startingDirectory set to the home folder
* We can't do this because we do not know the user's home folder
path.
* Generate WSL profiles with `--cd` in them.
* This only works for unmodified profiles.
* This only works for generated profiles.
* Users cannot override the commandline without breaking it.
* Users cannot specify a startingDirectory (!) since the one on the
commandline wins.
* Set a flag on generated WSL profiles to request this trick
* This only works for generated profiles. Users who create their own
WSL profiles couldn't set startingDirectory and have it work the
same.
Patching the commandline, hacky though it may be, seemed to be the most
compatible option. Eventually, we can even support `wt -d ~ wsl`!
## Validation Steps Performed
Manual validation for the following cases:
```c++
// MUST MANGLE
auto a01 = _tryMangleStartingDirectoryForWSL(LR"(wsl)", L"SENTINEL");
auto a02 = _tryMangleStartingDirectoryForWSL(LR"(wsl -d X)", L"SENTINEL");
auto a03 = _tryMangleStartingDirectoryForWSL(LR"(wsl -d X ~/bin/sh)", L"SENTINEL");
auto a04 = _tryMangleStartingDirectoryForWSL(LR"(wsl.exe)", L"SENTINEL");
auto a05 = _tryMangleStartingDirectoryForWSL(LR"(wsl.exe -d X)", L"SENTINEL");
auto a06 = _tryMangleStartingDirectoryForWSL(LR"(wsl.exe -d X ~/bin/sh)", L"SENTINEL");
auto a07 = _tryMangleStartingDirectoryForWSL(LR"("wsl")", L"SENTINEL");
auto a08 = _tryMangleStartingDirectoryForWSL(LR"("wsl.exe")", L"SENTINEL");
auto a09 = _tryMangleStartingDirectoryForWSL(LR"("wsl" -d X)", L"SENTINEL");
auto a10 = _tryMangleStartingDirectoryForWSL(LR"("wsl.exe" -d X)", L"SENTINEL");
auto a11 = _tryMangleStartingDirectoryForWSL(LR"("C:\Windows\system32\wsl.exe" -d X)", L"SENTINEL");
auto a12 = _tryMangleStartingDirectoryForWSL(LR"("C:\windows\system32\wsl" -d X)", L"SENTINEL");
auto a13 = _tryMangleStartingDirectoryForWSL(LR"(wsl ~/bin)", L"SENTINEL");
// MUST NOT MANGLE
auto a14 = _tryMangleStartingDirectoryForWSL(LR"("C:\wsl.exe" -d X)", L"SENTINEL");
auto a15 = _tryMangleStartingDirectoryForWSL(LR"(C:\wsl.exe)", L"SENTINEL");
auto a16 = _tryMangleStartingDirectoryForWSL(LR"(wsl --cd C:\)", L"SENTINEL");
auto a17 = _tryMangleStartingDirectoryForWSL(LR"(wsl ~)", L"SENTINEL");
auto a18 = _tryMangleStartingDirectoryForWSL(LR"(wsl ~ -d Ubuntu)", L"SENTINEL");
```
We don't have anywhere to put TerminalConnection unit tests :|
Closes#592.
When switching to the alt buffer, the starting cursor position, style,
and visibility is meant to be inherited from the main buffer. Similarly,
when returning to the main buffer, any changes made to those attributes
should be copied back (with the exception of the cursor position, which
is restored to its original state). This PR makes sure we handle that
cursor state correctly.
At some point I'd like to move the cursor state out of the
`SCREEN_INFORMATION` class, which would make this inheritance problem a
non-issue. For now, though, I've just made it copy the state from the
main buffer when creating the alt buffer, and copy it back when
returning to the main buffer.
## Validation Steps Performed
I've added some unit tests to verify the cursor state is inherited
correctly when switching to the alt buffer and back again. I also had to
make a small change to one of the existing alt buffer test that relied
on the initial cursor position being at 0;0, which is no longer the
case.
I've verified that the test case in issue #3545 is now working
correctly. I've also confirmed that this fixes a problem in the
_notcurses_ demo, where the cursor was showing when it should have been
hidden.
Closes#3545
## Summary of the Pull Request
<kbd>win+shift+arrows</kbd> can be used to move windows to adjacent monitors. When that happens, we'll new re-calculate the size of the window for the new monitor.
## References
* megathread: #8888
## PR Checklist
* [x] Closes#10274
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
In `WM_WINDOWPOSCHANGING`, the OS says "hey, I'm about to do {something} to your window. You cool with that?". We handle that message by:
1. checking if the window was _moved_ as a part of this message
2. getting the monitor that the window will be moved onto
3. If that monitor is different than the monitor the window is currently on, then
* calculate how big the quake window should be on that monitor
* tell the OS that's where we'd like to be.
## Validation Steps Performed
* <kbd>win+shift+arrows</kbd> works right now
* normal quake summoning still works right
I was watching a video about vectorized instructions and I wanted to
try out some new things, as I had never written AVX code before.
This commit is the result of this tiny Thursday morning detour into
AVX land. It improves performance of `TextColor::GetColor` by about 3x.
## Validation Steps Performed
* Default colors are still properly shifted +8 ✔️
Sets the tooltip text on the '+' button based on the keyboard modifiers
when dragging and dropping.
## Validation Steps Performed
Manually tested - dragged a directory onto the '+ button and saw that
* The text changed when `shift` was pressed
* The text changed when `alt` was pressed
* The text changed back when `shift` or `alt` were released
Closes#10722
## Summary of the Pull Request
This fixes two bugs related to dragging into the bounds of the `TermControl`. Although the fixes are fairly small, I'm batching them up, because I don't want to stack 2 more PRs on top of #10051.
* #9109
- This is fixed by only starting an autoscroll if the click&drag actually started within the bounds of the control.
* #4603
- Building on the above change, only modify the selection when the drag started in the control.
## References
* srsly go read #10051.
## PR Checklist
* [x] Closes#9109
* [x] Closes#4603
* [x] I work here
* [x] Test added
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is kind of annoying that the auto-scrolling is handled by the TermControl, but it uses a timer that's still a WinUI construct.
We only want to start the auto-scrolling behavior when the drag started _inside_ the control. Otherwise, in the tab drag scenario, dragging into the bounds of the TermControl will trick it into thinking it should start a scroll.
## Summary of the Pull Request
When we're restoring from fullscreen, we do a little adjustment to make sure to clamp the window bounds within the bounds of the active monitor. We unfortunately didn't account for the size of the non-client area (the invisible borders around our 1px border). This didn't matter most of the time, but if the window was within ~8px of the side of the monitor (any side), then restoring from fullscreen would actually move it to the wrong place.
As it turns out, the `_quake` window is within ~8px of the edges of the monitor _very often_.
## References
* regressed in #9737
## PR Checklist
* [x] Closes#10199
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
The repro in the bug was fairly straightforward. It doesn't happen anymore.
For inexplicable reasons, the top row of pixels on our tabs, new tab
button, and caption buttons is totally unclickable. The mouse simply
refuses to interact with them. So when we're maximized, on certain
monitor configurations, this results in the top row of pixels not
reacting to clicks at all.
To obey Fitt's Law, we're gonna hackily shift the entire island up one
pixel. That will result in the top row of pixels in the window actually
being the _second_ row of pixels for those buttons, which will make them
clickable. It's perhaps not the right fix, but it works.
After discussion, we think this is a fine fix for this. We don't think
anyone's going to miss the top row of pixels on the TabView. The original
bug is painful enough for the subset of users it impacts that this is an
acceptable trade. Should a better fix be found, we can absolutely do that
instead.
Closes#7422
<!-- 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
Implementation of #6219 with a small tweak, not just passing the keys when no panes are present, but passing on the keys when there is no other pane to move to. This enables another usecase: 2 panes in terminal split vertically; in one of these panes running tmux with two panes that are split horizontally. This allows the user to still navigate between tmux panes even though they have terminal panes open.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
Not that I know of
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#6219
* [x] CLA signed.
* [x] Tests added/passed
* [x] Documentation updated. I don't think that's necessary
* [x] Schema updated. N/A
* [ ] 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.
<!-- 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
Implementation by propagating the boolean indicating success of moving focus all the way to the action handler, where this result will determine whether the action will be considered handled or not. When the action is not handled, the keychord will be propagated to the terminal.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing; all relevant unit tests still work
<!-- 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
Fixes/implements #10058 according to directions in that issue: added support for browser navigation keys to be used in actions.
<!-- 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
* [x] Closes#10058
* [x] CLA signed.
* [x] 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: https://github.com/MicrosoftDocs/terminal/pull/371
* [x] Schema updated.
* [x] I've discussed this with core contributors already. According to instructions in #10058
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
The mouse back/forward keys do not correspond to the keys added here. That would be a nice (but more complicated) addition, I'll add an issue for it.
<!-- 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
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
The `+=` operator is an extremely hot path under heavily output load. This PR aims to optimize its speed.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Supports #10563
* [ ] 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- For tabs started from the Terminal, the initial sizing information is
passed into the connection and used to establish the PTY. Those
parameters are given over to the `OpenConsole.exe` acting as PTY to
establish the initial buffer/window size.
- However, for tabs started from outside, the PTY is created with some
default buffer information FIRST as the Terminal hasn't even been
involved yet. As such, when the Terminal gets that connection, it must
tell the PTY to resize just as it connects to match the window size
it's about to use.
- Ongoing resize operations in the Terminal did and still work fine
because they transmitted the updated size with the
`ResizePseudoConsole` API.
## Validation Steps Performed
- [x] Confirmed existing tabs opening have correct initial size in PTY
(like with CMD `mode con` command)
- [x] Confirmed inbound cmd tabs have correct initial size in PTY via
`mode con` command per bug repro
Closes#9811
Turns out, DWrite will automatically turn some features on even if they weren't included in the feature vector passed into it. Remove these features from our default list for easier readability.
This commit fixes the UseDx mode for conhost.
In order to add support for UseDx without calling `SetWindowSize`,
responsibility for resizing `_invalidMap` has been moved to occur
only when the renderer itself recognizes a new size. Furthermore
`InvalidateAll` is now the central point to invalidate `_invalidMap`.
## Validation Steps Performed
* Enabling `UseDx` enables the DxEngine for conhost ✔️
* Resizing windows in conhost works ✔️
* Resizing windows in WT works ✔️Closes#5455
## Summary of the Pull Request
Uses the new logic to find visual neighbors of a pane to find which pane is the target when the move-focus commands are used.
## References
It sounds like this logic will be refined later to meet #4692
## PR Checklist
* [x] Closes#2398
* [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
## Validation Steps Performed
Created a grid of panes and confirmed that focus movement went to the right quadrant instead of just the first child of the sibling.
Adds support for users to be able to set font features and axes (see the spec for more details!)
## Detailed Description
**CustomTextLayout**
- Asks the `DxFontRenderData` for the font features when getting glyphs
- _If any features have been set/updated, we always skip the "isTextSimple" shortcut_
- Asks the `_formatInUse` for any font axes when mapping characters in `_AnalyzeFontFallback`
**DxFontRenderData**
- Stores a map of font features (initialized to the [standard feature list])
- Stores a map of font axes
- Has methods to add font features/axes to the map or update existing ones
- Has methods to retrieve the font features/axes
- Sets the font axes in the `IDWriteTextFormat` when creating it
## Validation Steps Performed
It works!
[standard feature list]: ac5aef67d1/DrawableObject.ixx (L802)
Specified in #10457
Related to #1790Closes#759Closes#5828
## Summary of the Pull Request
When we perform a `focusTab` action, we currently do nothing if the parameter was greater than the number of tabs. This PR changes that behavior. Now, `focus-tab -t 999999` will always focus the last tab, instead of silently doing nothing.
## PR Checklist
* [x] Closes#9369
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* [x] ran tests
* [x] validated commandline manually
Related work items: MSFT-32957145
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev bdb25dc99dcb2f1ee483dffe883d0178ea9d18dc
<!-- 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 functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
This work potentially touches on: #1000#2398 and #4922
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality)
* [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
* [x] 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
Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes.
Work currently done:
- Add boilerplate/infrastructure for argument parsing, hotkeys, event handling
- Adds the `MovePane` function that finds the focused pane, and then tries to find
a pane that is visually adjacent to according to direction.
- First pass at the `SwapPanes` function that swaps the tree location of two panes
- First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus`
that search the tree for the currently focused pane, and then climbs back up the tree
to try to find a sibling pane that is adjacent to it.
- An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction.
Next steps:
- Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function.
- Do we want default hotkeys for the new actions?
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
Pass inbound handoff message via heap so it cannot race out of scope by the time it reaches the ConsoleIoThread
## PR Checklist
* [x] Closes#10251
* [x] I work here.
* [x] Manually verified somewhat
## Detailed Description of the Pull Request / Additional comments
- `OpenConsole.exe` is started in response to the OS `conhost.exe` request for a handoff and prepares an Out Of Proc Multithreaded COM server.
- A COM thread from the pool inside `OpenConsole.exe` picks up the inbound message and allocates some stack space for the `CONSOLE_API_MSG` coming in
- That COM thread calls down to set up the I/O thread that will pump the console driver handle and passes a pointer to the stack-allocated `CONSOLE_API_MSG` as the `LPVOID` parameter for starting the thread.
Now one of two things happen:
1. The I/O thread is scheduled pretty much immediately (or soon enough that the COM thread hasn't messed with the stack space), picks up the pointer to the COM thread's stack with `CONSOLE_API_MSG`, and processes the initial message correctly.
2. The COM thread continues and finalizes the handoff message to `conhost.exe` declaring success. It then pops stack and "frees" the memory space. If it doesn't manage to overwrite it, we're still good. If it does, then things go crazy.
This fix changes it so that the `CONSOLE_API_MSG` is sent into the heap before being passed to the other thread so it's in a known location that won't be freed or overwritten unexpectedly.
## Validation Steps Performed
- [x] - Confirmed that many handoffs from the run box seem to work alright on my system after this change.
- [x] - Confirmed that many tab creations/splits seem to work alright on my system after this change.
- [x] - Would prefer if @ianjoneill could try to F5 this branch to build/deploy it, set it as default, and see if it makes it go away completely... but I'm pretty confident it is this based on the dumps provided either way.
## Summary of the Pull Request
We no longer automatically write the 'hidden' field for profile stubs we create
**Note**: This does not retroactively remove the automatically generated hidden fields in current settings files
## PR Checklist
* [x] Closes#10539
* [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.
* [x] I work here
## Validation Steps Performed
Deleted the ubuntu stub in my settings file, booted up terminal, new created stub did not have the hidden field. Created a fragment that overrides the hidden field and it worked.
As identified by Michael Niksa, our MDE heuristics for understanding relationship between conhost and related processes was incorrect. Exposing trace here to assist in correlation.
Related work items: MSFT-32957145
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 3c886da66d77d1aa36b52794929e388af292539c
The `_CONSOLE_API_MSG` buffer is resized to cover an entire message.
Later on any UTF-8 data is cached in a separate temporary
buffer inside `til::u8state` to prevent lone surrogate pairs.
Both cases are problematic as neither buffer is freed after the read
has finished. Passing a 100MB buffer to conhost once will thus cause it
to continue using ~220MB of physical memory until the conhost process exits.
This change releases unneeded memory as soon as the requested buffer
size has halved. In practice this means that once a command has returned
all buffers will shrink, as the shell commonly sends very small messages.
## PR Checklist
* [x] Closes#10731
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Buffers aren't reallocated during printing ✔️
* Buffers shrink after printing finished ✔️
This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`.
Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts.
## PR Checklist
* [x] Closes#7539, Closes#10203
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
The following was tested both on US and DE keyboard layouts:
* Ctrl+, opens settings ✔️
* Win+` opens quake mode window ✔️
* Ctrl+plus/minus increase/decrease font size ✔️
## Summary of the Pull Request
Adjust the y-coordinate of the mouse coordinates we send based on how much the viewport has been scrolled
## Validation Steps Performed
Validated: cannot repro the issue in #10190Closes#10190
## Summary of the Pull Request
We were making the quake window exactly the width of the monitor it was on, but that didn't account for the 1px of border on either side.
## References
* megathread: #8888
## PR Checklist
* [x] Closes#10201
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
It happened before, it doesn't anymore.
## Summary of the Pull Request
Add an explicit background color to part of the settings UI to prevent animation overflow. The previous solution (adding a ScrollViewer) caused problems.
## References
#10619 adds a ScrollViewer for one of the issues in #10609
## PR Checklist
* [x] Closes#10664
* [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
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
Visually confirmed the animation doesn't overflow, changed the theme and confirmed the colors are responsive. Confirmed the extra scrollbar is gone.
Visual Studio 2022 Preview recently released the v143 toolchain.
C4189 is now flagging several unused variables, which breaks our build.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* CascadiaPackage builds ✔️
* All tests build ✔️
## Summary of the Pull Request
When the quake window is moved to another monitor, re-evaluate it's size for that monitor.
## References
* megathread: #8888
* Similar, but not the same: #10274
## PR Checklist
* [x] Closes#10182
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
We'll probably need to do this in a few more places, but I'm breaking PRs into small chunks for easier reviews.
## Validation Steps Performed
Summoned the window to a bunch of different resolutions. Where it would use the wrong size before, it no longer does.
As discussed in team sync. Is this a mysterious dark pattern we didn't know about?
* [x] closes#10721
* [x] I work here
* [x] doesn't need tests
* [x] doesn't need docs
* see also #10160
#### ⚠️ targets #10051
## Summary of the Pull Request
This PR does one big, primary thing. It removes all the constructors from any TerminalConnections, and changes them to use an `Initialize` method that accepts a `ValueSet` of properties.
Why?
For the upcoming window/content process work, we'll need the content process to be able to initialize the connection _in the content process_. However, the window process will be the one that knows what type of connection to make. Enter `ConnectionInformation`. This class will let us specify the class name of the type we want to create, and a set of settings to use when initializing that connection.
**IMPORTANT**: As a part of this, the constructor for a connection must have 0 arguments. `RoActivateInstance` lets you just conjure a WinRT type just by class name, but that class must have a 0 arg ctor. Hence the need for `Initialize`, to actually pass the settings.
We're using a `ValueSet` here because it's basically a json blob, with more steps. In the future, when extension authors want to have custom connections, we can always deserialize the json into a `ValueSet`, pass it to their connection's `Initialize`, and let then get what they need out of it.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760298
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
`ConnectionInformation` was included as a part of this PR, to demonstrate how this will eventually be used. `ConnectionInformation` is not _currently_ used.
## Validation Steps Performed
It still builds and runs.
<!-- 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 implements the ability to drop directories/files on the '+' button which in turn will open the tab/pane/window in the given starting path.
In order to do this, I refactored the click's lambda into a method and re-used it
Sadly I wasn't able to add note about the alt/shift feature (any ideas how to do this?)
Also most of the code is "look-a-like" from other places within the project, as I don't have much experience in windows development.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
implements #10073
## PR Checklist
* [ ] Closes#10073
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
** tests were done manually both of the old feature (alt/shift+click) on the '+' and on the profiles
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
** no idea what to add there, if any.
* [ ] 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
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
tested manually.
<!-- 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
<!-- 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
* [X] Supports #10563
* [ ] 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
