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
I added some sample screenshots on the README for the pixel shader feature
Fixes#8960
## Detailed Description of the Pull Request / Additional comments
I created 4 screenshots using preview windows terminal, one for the default look, and three for the shaders mentioned in the readme.
For the first shader, `Invert.hlsl`, I put it in a table and placed a screenshot of the default next to it. I don't think it would be clear what the shader did without being able to compare it against the default.
For `Rasterbars.hlsl` I put a screenshot right after the code sample for it. I added a screenshot for `Retro.hlsl` just before the last sentence
I also created a folder named Screenshots in `terminal/samples/Pixelshaders` to hold all of the screenshots.
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
## Summary of the Pull Request
This fixes a bug where renaming/deleting a color scheme would not update profiles that referenced it.
This also adds detection for renaming a color scheme to a name that is already in use, and adds appropriate UI for that.
## References
#6800 - Settings UI Epic
## PR Checklist
* [X] Closes#8756
## Detailed Description of the Pull Request / Additional comments
`Model::CascadiaSettings` was updated to have a `UpdateColorSchemeReferences()` function that updates all profiles referencing the newly renamed color scheme.
`Editor::ColorSchemesPageNavigationState` now takes and exposes a `Model::CascadiaSettings`.
When a color scheme is renamed or deleted, we use `CascadiaSettings` to update our list of color schemes appropriately, then call `UpdateColorSchemeReferences()` to update the profiles.
The tricky part is that `Profile` does not store a direct reference to `ColorScheme`, but rather the name of the color scheme. See [this tread](https://github.com/microsoft/terminal/issues/8756#issuecomment-760375027) for a discussion on this topic.
## Validation Steps Performed
Repro steps from #8756 when renaming/deleting a referenced color scheme.
## Demo
This adds the skeleton code for "bracketed paste mode" to the Windows
Terminal. No actual functionality is implemented yet, just the wiring
for handling DECSET/DECRST 2004.
References #395
Supersedes #7508
Initialize stack variables. check return code from shell lnk loading (GH-8712)
## References
* Commit f273aa679d4d9fb516678fc7ed5fc6495a8e8532 from os repository.
## Detailed Description of the Pull Request / Additional comments
* We found and fixed this in November 2017, but I fumbled the replication and accidentally overwrote the commit. This digs it up from history and puts it back in our code.
* When the shortcut file cannot be read for whatever reason, we are setting the hotkey value to uninitialized data as we never initialize several members on the stack in this function. It just so happens that the one in the `dwHotkey` field is commonly `0x4c` or the letter `L` which is then sent into the window procedure to tell the OS to capture it as a global hotkey and foreground the `conhost.exe` that was started. We should realize the load failure and not set any hotkey at all and we should initialize the stack variables. This does both.
## Validation Steps Performed
* [x] Manual scenario running LNK file that cannot be loaded from customer report (make LNK to cmd.exe, make it inaccessible to conhost so it can't load/read it.)
* [x] Manual scenario with `mklink`'d link that makes the shortcut parser attempt to load (and fail because it isn't a LNK at all from GH-7650)
Fixes MSFT-31351620
The Windows build system doesn't support PMR yet, so we had to add a workaround. :(
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 1614b27830a07484c18628ec7d9abc5f9d9b8a0b
Related work items: MSFT-31337042
This reverts commit a7d7362b95 introduced by #8803.
Reverting this commit fixes#8836 at the expense of the profile page
remembering the last Pivot selection. The
## References
#6800 - Settings UI Epic
#8803 maintained a `ProfilePageNavigationState` in `MainPage` to remember
the pivot position. However, the two-way binding on the TextBoxes
now seem to happen too late (after the navigation occurs),
resulting in the text being applied to the wrong profile. In other
words, the sequence of events probably looks something like this:
1. user types text (_state.profile = old profile)
2. user moves to new profile
3. navigation completes (_state.profile = new profile)
4. textbox two-way binding fires, setting _state.profile.WHATEVER = value
## Validation Steps Performed
Performed repro sets from #8836. Bug no longer occurs.
Reopens#8769Closes#8836
Upon a settings reload, we would select the correct navigation item for
a profile, but navigate to the old one. As a result, you would navigate
to the old page that points to a dead profile object. This would make it
appear like you did not discard/save the changes.
This bugfix navigates to the newly created profile, ensuring that your
changes are actually applied to the settings model's clone in use.
## References
#8773 - Introduced the bug
#6800 - Settings UI Epic
## Validation Steps Performed
- Navigate to "powershell" profile
- edit "tab title" value
- discard changes
Before: changes would persist unless you discarded changes again
Now: changes are discarded
Also verified expected behavior occurs when you click "save" instead of
"discard"
Moving things out of CharRow into ROW helps us hide it as an implementation detail.
This is part one of many.
### CharRow: Hide ClearCell, use ROW::ClearColumn
### CharRow: Hide GetText, use ROW::GetText
### CharRowBaseTests: remove dead file (never used!)
### CharRow: Move DoubleBytePadded into ROW
### CharRow: Move WrapForced into ROW
### Char/AttrRow: Hide Reset, use ROW::Reset
### Remove RowCellIterator (dead code)
RCI was unused; it was replaced by TextBufferCellIterator shortly after its creation
### Move AttrRowTests to ut_textbuffer from ut_host
It had no reliance on the host.
Cleans up a ton of competing and outdated sources from our NuGet.Config to improve reliability and maintainability.
## PR Checklist
* [x] Closes an overdue-to-clean mess.
* [x] I work here.
* [x] Tests covered below.
* [x] I've discussed this with @DHowett already.
## Validation Steps Performed
- [x] - NuGet restored everything I could get my hands on (all `packages.config`) in our project before and after the change.
- [x] - The build and tests still run fine. (PR automation should check this one)
A part of the #8415.
Includes:
* Moving `TabSwitcherMode` related decisions into `CommandPalette`
(simplifying the logic of `TerminalPage::SelectNextTab`)
* Fix a bug where the index of first tab switch is incorrect
(since bindings are not updated)
* Removing redundant `CommandPalette` updates
* Preparations for tabs binding
Removes the visibility hack in `UpdateSettings` where we were hiding
Profile menu items instead of removing them. This hack was removed using
`ReplaceAll`. For an unknown reason, calling `Remove()` would result in
an out-of-bounds error in XAML code.
The "Discard" button would improperly refresh the Settings UI. Both of
the bugs were caused by holding a reference to a hidden menu item then
trying to set the `SelectedItem` to that menu item.
Additionally, 9283375 adds a check for the selected item in
`SettingsNav_ItemInvoked()`. This prevents navigation to an already
selected item. This was the heuristic used by the XAML Controls Gallery.
References #6800 - Settings UI Epic
## Validation Steps Performed
(Repeated for each menu item)
1. Select the menu item
2. click "Discard changes"
3. Verify navigated to same page
Also performed repro steps for #8747 and #8748.
Closes#8747Closes#8748
This PR adds a sample monarch/peasant application. This is a type of
application where a single "Monarch" can coordinate the actions of multiple
other "Peasant" processes, as described by the specs in #7240 and #8135.
This project is intended to be a standalone sample of how the architecture would
work, without involving the entirety of the Windows Terminal build. Eventually,
this architecture will be incorporated into `wt.exe` itself, to enable scenarios
like:
* Run `wt` in the current window (#4472)
* Single Instance Mode (#2227)
For an example of this sample running, see the below GIF:
This sample operates largely by printing to the console, to help the reader
understand how it's working through its logic.
I'm doing this mostly so we can have a _committed_ sample of this type of application, kinda like how VtPipeTerm is a sample ConPTY application. It's a lot easier to understand (& build on) when there aren't any window shenanigans, settings loading, Island instantiation, or anything else that the whole of `WindowsTerminal.exe` needs
* [x] I work here
* [x] This is sample code, so I'm not shipping tests for it.
* [x] Go see the doc over in #8135
This PR Makes sure that after you save the settings, we stay on the same part of the profiles pivot. We do this by having a singleton `ProfilesNavigationState`, a bit like the color scheme one in #8799. Hence why this PR is targeting the other.
## PR Checklist
* [x] I work here
* [x] Tested manually
* [x] Fixes the first point in #8769
## Summary of the Pull Request
This PR fixes two of the components of #8765.
> * [ ] Edit a color scheme -> Hit 'apply' -> the selected color scheme resets to the first color scheme in the list (instead of the one just edited)
This was fixed by storing the navigation state as a singleton in MainPage, and having the color schemes page update the selected scheme on that singleton. That way, a subsequent navigation to the schemes page could re-use the existing state.
> * [ ] The buttons turn gray on rollover covering up what color I'm looking at (I have dark mode)
This one was tricky. We're binding the resource for this button, to the color the button is bound to. We're also running a converter on that color, as to change the alpha slightly. This allows us to still have visual feedback on pointerover, without obscuring the color entirely.
## PR Checklist
* [x] I work here
* [x] Tested manually
`til::details::bitmap<Allocator>` will use `Allocator` for its
`dynamic_bitset`, and it will use a rebound allocator for its run storage.
Allocator should be an allocator type storing `unsigned long long`, the
backing store type for `dynamic_bitset`.
I've introduced a type alias, `til::bitmap`, which papers over the
allocator choice for all existing code. I've also introduced a second
type alias, `til::pmr::bitmap`, which lets a consumer use the C++
polymorphic allocator system.
I chatted with @miniksa about whether to keep the "full" allocator
version in `details` or not. We decided that for the simplicity of the
`til` namespace, we would. If anybody has a compelling reason to use
`til::details::bitmap<Allocator>` directly, we can re-evaluate this
decision.
