Contains:
- Delegation Configurator that can lookup/edit/save configuration information to registry
- Conhost can lookup the CLSID of a registered default
- Conhost has the ability to handoff a starting visible-window interactive session to the registered default
- Velocity key since this is a big deal and we want to be careful
- IDL for the interface
Related work items: MSFT-16458099
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 0ca55027d8180fbbaa145f2fe7a15005856c0f7c
Dustin L. Howett (3)
* Move CharToKeyEvents (and friends) into InteractivityBase (GH-9106)
* Update Cascadia Code to 2102.03 (GH-9088)
* verison: bump to 1.7 on main
Josh Soref (1)
* ci: update to Spell check to 0.0.17a (CC-9014)
Leonard Hecker (3)
* Fixed GH-5205: Ctrl+Alt+2 doesn't send ^[^@ (CC-5272)
* Fix issues in tests.xml and OpenConsole.psm1 (CC-9011)
* Fix GH-8458: Handle all Ctrl-key combinations (CC-8870)
Mike Griese (1)
* Add support for running a commandline in another WT window (GH-8898)
Michael Niksa (1)
* Teach the renderer to keep thread alive if engine requests it (GH-9091)
Lachlan Picking (1)
* Fix shader time input (CC-8994)
PankajBhojwani (1)
* Separate runtime TerminalSettings from profile-TerminalSettings (CC-8602)
Chester Liu (2)
* Add support for paste filtering and bracketed paste mode (CC-9034)
* Add support for chaining OSC 10-12 (CC-8999)
Related work items: MSFT-31692939
Due to a minor OS issue, we needed to shim PMR _even more_.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev a83daa5e2af50121d79be082d005ff2e969ad18e
Related work items: MSFT-31478342
Avoid sending mouse move / wheel / release to Terminal in the first place.
This kind of short-circuiting will prevent us reaching the
attempt to send input to connection
(that could result in the warning dialog in the read-only mode)
Closes#9074
These functions have a dependency on the "VT Redirected" versions of
VkKeyScanW, MapVirtualKeyW and GetKeyState. Those implementations depend
on the service locator and therefore the entire interactivity stack.
This meant that anybody depending on just Types had to pull in **the
entire host** worth of dependencies (!).
Since these functions are only used in places where we have or are
testing interactivity, it makes sense to consolidate them here.
(cherry picked from commit 8f73145d9d)
These functions have a dependency on the "VT Redirected" versions of
VkKeyScanW, MapVirtualKeyW and GetKeyState. Those implementations depend
on the service locator and therefore the entire interactivity stack.
This meant that anybody depending on just Types had to pull in **the
entire host** worth of dependencies (!).
Since these functions are only used in places where we have or are
testing interactivity, it makes sense to consolidate them here.
`CascadiaSettings::UpdateColorSchemeReferences` had two bugs in it:
1. we would never check/update the base layer
2. we would explicitly set the color scheme on a profile referencing the
old name
This PR fixes both of those issues by checking/updating the base layer,
and ensuring that we check if a profile has an explicit reference before
updating it.
Since the affected code is in TSM, I also created an automated local
test.
## Validation Steps Performed
Bug repro steps.
Specifically tested [DHowett's scenario] too.
Test added.
Closes#9094
[DHowett's scenario]: https://github.com/microsoft/terminal/issues/9094#issuecomment-776412781
* Currently TerminalPage registers on CmdPal key events:
* To invoke bindings when the palette is open
* Since some key combinations are not triggered by KeyDown
it registers for PreviewKeyDown
* As a result bindings might be preferred over navigation
(e.g., ctrl+v will paste into Terminal rather than into search box)
* To fix this, I moved all interactions inside the CmdPal into
PreviewKeyDown as well
* In addition, added specific handling for copy/paste
which now allow to interact with search box even if not focused
Closes#9044
Teaches renderer base to keep thread alive if engine requests it.
`DxEngine` now requests it if shaders are on.
- The render engine interface now has a true/false to return whether the
specific renderer wants another frame to immediately follow up. The
renderer base will ask for this information as it ends the paint on
any particular engine (which is the time where invalid regions are
typically cleaned up) and just poke the render thread the same as if
an invalidation request came in from outside of render-land. That will
trigger the render thread to just keep moving in the same way as any
other invalidation.
## Validation Steps Performed
- [x] Actually built it
- [x] Actually try it
I promised this in #8994
## Summary of the Pull Request
**If you're reading this PR and haven't signed off on #8135, go there first.**
This provides the basic parts of the implementation of #4472. Namely:
* We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window.
* If `window-id` is `0`, run the given commands in _the current window_.
* If `window-id` is a negative number, run the commands in a _new_ Terminal window.
* If `window-id` is the ID of an existing window, then run the commandline in that window.
* If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window.
* If `window-id` is omitted, then create a new window.
## References
* Spec: #8135
* Megathread: #5000
* Project: projects/5
## PR Checklist
* [x] Closes#4472
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - **sure does**
## Detailed Description of the Pull Request / Additional comments
Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change
There are limitations, and there are plenty of things to work on in the future:
* [ ] We don't support names for windows yet
* [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that.
* [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from.
* [ ] Basically anything else that's listed in projects/5.
I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in.
## Validation Steps Performed
I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain.
# TODOs
* [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬
- [x] `Monarch.cpp`
- [x] `Peasant.cpp`
- [x] `WindowManager.cpp`
- [x] `AppHost.cpp`
* [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully.
- Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID.
- Could we gracefully recover from such a state? maybe, probably not though.
- Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant?
- After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
1. Fix progress value not updated
2. Introduce TabStatus object and bind both TabHeaderControl and CommandPalette to it
3. Add support for read-only mode indicator
<!-- 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
The TerminalSettings object we create from profiles no longer gets passed into the control, instead, a child of that object gets passed into the control. Any overrides the control makes to the settings then live in the child. So, when we do a settings reload, we simply update the child's parent and the overrides will remain.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing
## Summary of the Pull Request
Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality:
- a reset button next to the header
- tooltips and automation properties for the setting being wrapped
- a comment stating if you are currently overriding a setting
## References
[Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md)
#8804 - removes the ambiguity of leaving a setting blank
#6800 - Settings UI Epic
#8899 - Automation properties for Settings UI
#8768 - Keyboard Navigation
## PR Checklist
* [X] Closes#8804
## Detailed Description of the Pull Request / Additional comments
A few highlights in this PR:
- CommonResources.xaml:
- we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template.
- Profiles.cpp:
- view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value
- `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly
- Profiles.xaml:
- basically wrapped all of the settings we want to be inheritable in there
- `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error.
- Resources.resw:
- had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately.
- `SettingContainer` files
- This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate`
- We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there.
- Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml.
- Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model.
## Demo
## Validation Steps Performed
- Verified correct binding behavior with the following generic setting controls:
- radio buttons
- toggle switch
- text block
- slider
- settings with browse buttons
- the background image alignment control
- controls with special check boxes (starting directory and background image)
## Next Steps
- The automation properties have been verified using NVDA. This is a part of resolving #8899.
- The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
## Summary of the Pull Request
Introduces read-only panes.
When pane is marked as read-only:
1. Attempt to provide user input results in a warning
2. Attempt to close pane - shows dialog
3. Attempt to close hosting tab shows dialog
4. The hosting tab has no close button
## PR Checklist
* [x] Closes#6981
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated - not yet.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
1. The readonly logic implemented in `TermControl`
(and prevents any send input)
2. Special handling is required to allow key-bindings
3. The "close-readonly" protections are in TerminalPage.
4. The indication that the pane is readonly is done using lock glyph
5. The indication that the tab contains readonly pane
is done by hiding the close button of the tab
6. The readonly mode is enabled by keyboard shortcut
(the followup might add this to the context menu)
## Validation Steps Performed
## Summary of the Pull Request
Fixes#5205, by replacing another use of `MapVirtualKeyW` with `ToUnicodeEx`.
The latter just seems to be much more consistent at translating key combinations in general.
In this particular case though it fixes the issue, because there's no differentiation in `MapVirtualKeyW` for whether it failed to return a character (`'\0'`) or succeeded in turning `^@` into `'\0'`.
`ToUnicodeEx` on the other hand returns the success state separately from the translated character.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#5205
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #5205
## Detailed Description of the Pull Request / Additional comments
This PR changes the behavior of the `Ctrl+Alt+Key` handling slightly:
⚠️ `ToUnicodeEx` returns unshifted characters. ⚠️
For instance `Ctrl+Alt+a` is now turned into `^[^a`. Due to how ASCII works this is essentially the same though because `'A' & 0b11111` and `'a' & 0b11111` are the same.
## Validation Steps Performed
* Run `showkey -a`
* Ensured `Ctrl+Alt+Space` as well as `Ctrl+Alt+Shift+2` are turned into `^[^@`
* Ensured other, random `Ctrl+Alt+Key` combination behave identical to the current master
This adds "paste filtering" & "bracketed paste mode" to the Windows
Terminal.
I've moved the paste handling code in `TerminalControl` to
`Microsoft::Console::Util` to be able to easily test it, and the paste
transformer from `TerminalControl` to `TerminalCore`.
Supersedes #7508
References #395 (overall bracketed paste support request)
Tests added. Manually tested.
The command palette is ephemeral and is dismissed if the focus
moves to an element which is not the palette's descendant.
Unfortunately, this breaks the (right-click) context menu,
as it is not a child of the palette
(popups are hosted on a separate root element).
- Fixes empty app title when `showTerminalTitleInTitlebar` is false
- Fixes Tab title propagation to Window title when
`showTerminalTitleInTitlebar` is false
- Fixes Tab title propagation to Window - title doesn't update when
Window is unfocused
1. There were a missing
`_settings.GlobalSettings().ShowTitleInTitlebar()` check. Because of
this Title update event was being fired even when
`showTerminalTitleInTitlebar` is false. This results in empty tab
title to propagate to Window title. Also then after switching tabs
back and forth, tab title propagates to window title. These shouldn't
propagate when `showTerminalTitleInTitlebar` is false. I added the
`showTerminalTitleInTitlebar` check in relevant logic to fix the
behavior.
2. Code was checking `tab.FocusState() != FocusState::Unfocused` , but
when the whole terminal window is not in focus, the active tab is
also in Unfocused state. This was preventing tab title to propagate
to window title when application is unfocused. I added the logic of
checking matching selected tabs' index. This fixes the issue.
## Validation Steps Performed
I did the reproduce steps descripted in the issue to reproduce the bugs.
After applying the fixes, the bugs don't appear anymore while doing the
reproduce steps.
Closes#8704
"disabledProfileSources" is saved to `CascadiaSettings` _not_
`GlobalAppSettings` (and, even then, it's only read when it's used,
never saved). This PR specifically detects if it was defined in
settings.json, and copies it over when the settings are serialized.
## Validation Steps Performed
1. Added "disabledProfileSources" to settings.json, then serialized. -->
"disabledProfileSources" is now maintained.
2. Updated `CascadiaSettings` serialization test
Closes#9032
## Summary of the Pull Request
Fix for #9021
Turns out that what was happening is that the _parent_ pane's `Closed` event was being caught by the tab, and parent panes always have `nullopt` as their id. So now the `Pane::Id()` call always returns an optional, allowing us to check if it has a value before we access it.
## PR Checklist
* [x] Closes#9021
## Validation Steps Performed
No more crash
This PR fixes the parsing of OSC 9;9 sequences with path surrounded by
quotation marks.
Original OSC 9;9 PR: #8330
Unit test added. Manually tested with oh-my-posh.
Closes#8930
This adds the support for chaining OSC 10-12, allowing users to set all
of them at once.
**BREAKING CHANGE**
Before this PR, the OSC 10/11/12 command will only be dispatched iff the
first color is valid. This is no longer true. The new implementation
strictly follows xterm's behavior. Each color is treated independently.
For example, `\e]10;invalid;white\e\\` is effectively `\e]11;white\e\\`.
## Validation Steps Performed
Tests added. Manually tested.
Main OSC color tracking issue: #942
OSC 4 & Initial OSC 10-12 PR: #7578
Closes one item in #942
### Plurals and paste tenses
In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were
automatically tolerated. This turned out to be a bad design choice on my
part.
The basic example is that `potatos` would sometimes be treated as a
mistake and sometimes not (depending on the presence of `potato`).
You can see in this PR, that this logic resulted in `Applys` being
accepted as a word along with `AppContainered` -- there's nothing
intrinsically wrong w/ the latter, but unfortunately in order to screen
out the former, my shortcut just couldn't stick around. This means that
the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as
you can see, not really by much.
This is also why `thereses` (a user) was accepted as a word in the past
(therese is in the base dictionary, so `therese` + `s` was acceptable).
### Pull requests
When GitHub initially introduced GitHub Actions, the event for
`pull_request` was created without enough permission for a tool like
this to work properly. I worked around that by using the `schedule`
event. In 2020, they introduced a replacement event
`pull_request_target` which has enough permission. This means that I can
stop relying on the `schedule` event.
### Miscellaneous
* I've folded together some `expect/` files since now is as good a time
as any.
* I've included a hint about `excludes.txt` (I added a similar one for
our primary repo recently, and it came up this week in
`microsoft/terminal` -- @zadjii-msft)
* I've standardized on a default of `.github/actions/spelling` to make
the out of the box experience easier for new adopters, so I'm applying
that change here -- if you're attached to the old directory name,
specifying it is still supported. -- note the directory rename may
cause a merge conflict for people with open PRs and changes to the
contents, this shouldn't be a big problem.
The settings.json was not regenerated if WT was already open. This resulted in the `ShellExecute` from trying to open the settings to pop up Notepad and say that this file didn't exist. We now detect if the settings.json was deleted to kick off loading the settings.
Closes#8955
Pressing Ctrl+\ produces `^\` using the US keyboard layout, thanks to Ctrl-key mappings inside the keyboard layout, whereas some layouts, like the UK extended layout, don't contain those. This causes the character value to be zero and previously caused no VT sequence to be generated under these situations. This PR employs `MapVirtualKeyW` to infer the missing characters.
As a side effect this PR effectively causes _all_ major keys on the keyboard to produce Ctrl+combinations now.
## PR Checklist
* [x] Closes#8458
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests passed
## Validation Steps Performed
Compared all major keys in combination with Ctrl with the app store version of Terminal using `showkey` in WSL. All keys that previously worked still appear to continue to work.
Correctly sets the time input on the pixelShaderSettings struct, which was previously hard-coded to `0.0f`.
## PR Checklist
* [x] Closes#8935
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #8935
## Detailed Description of the Pull Request / Additional comments
I added a private field to `DxEngine` to store the timestamp for when a custom shader is first loaded. The field is initialized in `_SetupTerminalEffects()`, and the calculated time value (seconds since the timestamp) passed to the actual shader is set in `_ComputePixelShaderSettings()`.
There remains an issue with with jerky animation due to the renderer not repainting when the window contents are not updated (see discussion in the original issue).
This is basically my first time writing C++; constructive review is enthusiastically welcomed 🙂
## Validation Steps Performed
I manually tested using a variety of simple shaders that rely on time input for animation.
## Summary of the Pull Request
Oops, winrt `IVector`s need to be manually initialized, when default-constructed `std::vector`s didn't. Simple oversight.
## PR Checklist
* [x] Closes#8986
* [x] I work here
* [x] A test would be great but ain't nobody got time for that.
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Ran the terminal with
```json
"schemes" :
[ {} ]
```
First the crash repro'd, now it doesn't.
If there is data being output when a tab is closed, that can sometimes
result in the application crashing, because the renderer may still be in
use at the time is it destroyed. This PR attempts to prevent that from
happening by adding a lock in the `TermControl::Close` method.
What we're trying to prevent is the connection thread still being
active, and potentially accessing the renderer, after it has been
destroyed. So by acquiring the terminal lock in `TermControl::Close`,
after we've stopped accepting new output, we can be sure that the
connection thread is no longer active (it holds the lock while it is
processing output). So once we've acquired and released the lock, it
should be safe to tear down and destroy the renderer.
## Validation Steps Performed
While this crash is difficult to reproduce in general usage, it occurred
quite frequently when testing my `DECPS` implementation (there is some
tricky thread synchronisation, which seems more likely to trigger the
issue). With this patch applied, though, those crashes have stopped
occurring.
I've also stepped through the shutdown code in the debugger, manually
freezing threads to get them aligned in the right way to trigger the
crash (as explained in issue #8734). Again with the patch applied, I can
no longer get the crash to occur.
Closes#8734
Fix a bug brought in with PR: #8638
see,
#8936#8638
* [x] Closes#8936
* [x] CLA signed
* [x] Tests passed
With the help from @nc-x, the issue is reproduced and fixed by this patch.
CLSCTX_IN_PROCESS is not good enough for all cases to create IShellWindows interface.
Put a CLSCTX_ALL fixes the issue.
Another debugging warning dialogs for reusing not null com_ptr in the loop is fixed too.
(This was shown in debug builds only)
## Summary of the Pull Request
Properly binds `CurrentLaunchMode` and `CurrentTabSwitcherMode` in the Settings UI. The default mode is `OneTime`, resulting in the setting never being set.
I performed a regex search of all "SelectedItem" bindings and these were the only two that were not properly bound.
## References
#6800 - Settings UI Epic
## Validation Steps Performed
Modified tab switcher mode and launch mode via the settings UI. Then saved. Before, the settings would revert back and not get applied. Now they got applied.
Closes#8947
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/8975
* [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
* We dismiss the edit each time `HeaderRenamerTextBox` loses focus
* Unfortunately, this applies also to scenario where the context menu
(copy, paste, select, etc.) is open with the right-click
* The fix is to ignore focus loss if `HeaderRenamerTextBox().ContextFlyout()` is open.
* We can do it as upon the fly-out dismiss the text box regains the focus.
Watson reports show that an "ArgumentException" is being thrown due to `renderSize`
not being valid. Added a check for renderSize before attempting to resize.
This is an extension of #8885. A lot of users have grown accustomed to
using `closePane` to close a tab. This adds `closePane` to the list of
keybindings accepted by #8885, and modifies the `closePane` code to
close the Settings UI if we are in a `SettingsTab`.
## References
#6800: Settings UI Epic
#8885: PR - Settings UI should respect key bindings (temporary solution)
#8882: Issue - Settings UI should respect key bindings
## Summary of the Pull Request
Apparently, we don't need this `TargetRuntime`. That's what was causing VS to think that we were a C# project, and give us that warning. This is the solution we got from the owner of the `.wapproj` plugin.
## References
* Introduced in c33883d852, in PR #8062
## PR Checklist
* [x] Closes#8301
* [x] I work here
Build and ran it fine. Changed TermControl, built and ran it fine. Now let's hope CI likes it.
This reverts the revert in #8838.
The problem was that the `Profile` in the singleton nav state would be
updated before the binding fired, so we'd end up modifying the _new_
profile, because both the old page and the new page would be pointing at
the _new_ profile already.
Instead of using a singleton instance of the profile nav state, we'll
create a new one each time. The new nav state attempt to steal the
selected pivot from the last instance of the nav state, if the profiles
are the same. This means that
This means that we won't end up modifying the new profile. The old
page's nav state will still have the old profile, so it'll still end up
modifying the old `ProfileViewModel`.
## PR Checklist
* [x] I work here
* [x] Tested manually
* [x] Fixes the first point in #8769, again
This PR adds support for the `DECID` (Identify Device) escape sequence,
which allows for querying the terminal type in a way that is backwards
compatible with VT52 terminals.
This simply checks for the `ESC Z` sequence in the `ActionEscDispatch`
method of output state machine, and forwards the query to the existing
`DeviceAttributes` dispatch method, since the expected response is
identical to a `DA` report.
## Validation Steps Performed
I've added an output engine test that verifies that the `ESC Z` sequence
is correctly interpreted as a `DA` query when in ANSI mode, and as a
VT52 identification query when in VT52 mode.
Closes#8857
When we emit a BEL (visual or audible), show an indicator in the tab
header
If the tab the BEL is coming from is not focused when the BEL is raised,
the indicator in its header will be removed when the tab gains focus. If
the tab was already focused when the BEL was emitted, then the indicator
goes away after 2 seconds.
Closes#8106
Make the "use parent process directory" checkbox rely on a computed
property in the ProfileViewModel. It will be enabled when the starting
directory is empty and disabled when it's not. When it's unchecked, the
last-used value will be restored. If there is no last-used value, it
will be set to %USERPROFILE%.
Closes#8805
This adds a "Name" text box to the Profile page in the Settings UI.
Any changes to the name/icon are propagated to the relevant
NavigationViewItem.
Base Layer does not have a "Name".
## References
#6800 - Settings UI Epic
