This adds a new feature to the Windows Terminal: "Workspaces"
Workspaces are very shamelessly inspired by Edge workspaces of the same
name.
The core idea is that when users name a window and they close that
window, we will persist that Windows layout and buffers, seperately from
the rest of window restoration. So a user can open a named window, open
some profiles, some panes, do some stuff in it, then close it, and we
will keep that state around for the next time the user opens that window
name.
Unnamed windows still behave the same. If you close an unnamed window,
and it's not the last window, then we won't persist the state of it.
To facilitate restoring named windows, we add a `openWorkspace` action.
This allows us to persist the open workspace action in the window layout
restoration path. So when we deserialize the list of tab layouts, and
open workspace action will tell us, hey, go retrieve this known
workspace from the state.json, instead of trying to serialize the window
state in two places.
As demoed in the video, we add a flyout to list the windows that the
user has open, and the named workspaces that they have saved. This
allows users to quickly reopen previously closed workspaces, as well as
quickly rename a window, thereby adding it to the list of saved
workspaces. This button can also be hidden using the theme settings.
Closes#17084
(this is a reboot of #20162, but with the event from #20311)
This adds a new feature to the Windows Terminal: "Workspaces"
Workspaces are very shamelessly inspired by Edge workspaces of the same
name.
The core idea is that when users name a window and they close that
window, we will persist that Windows layout and buffers, seperately from
the rest of window restoration. So a user can open a named window, open
some profiles, some panes, do some stuff in it, then close it, and we
will keep that state around for the next time the user opens that window
name.
Unnamed windows still behave the same. If you close an unnamed window,
and it's not the last window, then we won't persist the state of it.
To facilitate restoring named windows, we add a `openWorkspace` action.
This allows us to persist the open workspace action in the window layout
restoration path. So when we deserialize the list of tab layouts, and
open workspace action will tell us, hey, go retrieve this known
workspace from the state.json, instead of trying to serialize the window
state in two places.
As demoed in the video, we add a flyout to list the windows that the
user has open, and the named workspaces that they have saved. This
allows users to quickly reopen previously closed workspaces, as well as
quickly rename a window, thereby adding it to the list of saved
workspaces. This button can also be hidden using the theme settings.
Closes#17084
## Summary of the Pull Request
targets #20010
This adds support for the `OSC 777 ; notify ; title ; body ST` sequence.
This allows client applications to send a notification to the Terminal.
When this notification is clicked, it summons the terminal window that
sent it.
## Validation Steps Performed
```pwsh
# in PowerShell. Terminal should not be focused.
sleep 2; Write-Output "`e]777;notify;Hello;This is a notification`a"
```
## PR Checklist
- [X] Closes#7718
- [ ] Documentation updated
- [X] Schema updated (if necessary)
Heavily based on #19938
Co-authored by @zadjii-msft
This adds a `safeUriSchemes` global setting which lets you define
hyperlink URI schemes which the user considers safe. No confirmation
dialog will be shown when trying to open hyperlinks which use these
schemes.
- This solves the root issue, but doesn't introduce any UI or
documentation changes. I wanted to validate the approach and
implementation with you first.
- I closely followed the code handling the `disabledProfileSources`
setting, which is of the same type.
- This feature does not change the behavior of `http`, `https` and
`file` schemes.
Validation
I ran the dev terminal, and tested the behavior by clicking on `vscode`
hyperlinks generated by ripgrep with various `safeUriSchemes` settings:
- Setting not defined - asks for confirmation
- `["vscode"]` - does not ask for confirmation
- `["foo", "vscode"]` - does not ask for confirmation
- `["foo"]` - asks for confirmation
- `null` - asks for confirmation
- `[]` - asks for confirmation
- `[""]` - asks for confirmation
- `[{"foo": "bar"}]` - fails to deserialize (as expected)
A few uinit tests failed, but they seem unrelated to these changes:
- `KeyBindingTests` in `UnitTests_SettingsModel`, probably because I use
an AZERTY keyboard.
- A few `Conhost` tests, but I didn't touch this part
Refs #20065Closes#20191
## Summary of the Pull Request
Replaces the `warning.confirmCloseAllTabs` setting with a
`warning.confirmOnClose` enum setting that accepts the following:
- `never`: don't present a warning dialog when closing a session
- `automatic`: present a warning dialog when closing multiple tabs/panes
at once
- `always`: present a warning dialog when closing any session
The confirmation dialog contains a "don't ask me again" checkbox. When
checked, we update the setting to `never`.
This setting also affects the following actions:
- "close other tabs"
- "close tabs after"
- "close other panes"
- "quit"
The appropriate confirmation dialog is shown in these scenarios. We also
present an aggregate dialog instead of prompting the user once per
tab/pane. If there are no other tabs/panes, we don't present a dialog
and treat the key binding as unhandled (passing the key through).
## References and Relevant Issues
Iteration of #19944
## Validation Steps Performed
- closing a tab:
- ✅ 1 pane --> no dialog
- ✅ 2 panes --> dialog
- ✅ action and middle clicking tab trigger same flow
- close all other tabs:
- ✅ no other tabs --> no dialog
- ✅ 1 other tab --> dialog
- close all other panes:
- ✅ 1 pane --> no dialog
- ✅ 2 panes --> dialog
- close all tabs after the current tab:
- ✅ no tabs after --> no dialog (even if tabs before)
- ✅ 1 tab after --> dialog
- close window:
- ✅ 2 tabs --> dialog
- ✅ 2 panes --> dialog
- ✅ 1 tab with one pane --> no dialog
- Quit the Terminal:
- ✅ 3 windows --> dialog
- ✅1 window --> dialog
- ✅ "don't ask me again" checkbox checked --> setting changed to "never"
- ✅ "never" --> no dialog for scenarios above
- ✅ "always" --> dialog always appears, even when closing a single pane
## PR Checklist
Closes#5301Closes#6641
"don't ask me again" checkbox is also mentioned in #10000
Co-authored by @zadjii-msft
## Summary of the Pull Request
Targets #20010
Adds another `bellStyle` flag option. This sends a windows toast
notification to the user when a BEL is encountered
- [X] Closes#18605
- [ ] Documentation updated
Heavily based on #19936
Co-authored by @zadjii-msft
This is a refresh of spell-check-this, more or less as of
e089393b4e.
## References and Relevant Issues
A number of changes take advantage of features from
http://github.com/check-spelling/check-spelling/releases/v0.0.26
1.
[`load-config-from`](https://docs.check-spelling.dev/Configuration#load-config-from)
will allow future PRs to switch cleanly w/o the mess that this PR has --
once this merges, the `config.json` file will be used for the three
dictionary configuration elements instead of the ones in the workflow.
2. `contents: read` is no longer needed by the comment jobs as the data
is provided by the main job
Contains fixes for the following specific issues:
`without`, `with`, `with the`, `with the window`, `will be`,
`whether or not`, `where the`, `using`, `uppercase or lowercase`,
`unit testing`, `to`, `to which...`, `to which`,
`to which the view refers`, `to which the pane was moved`,
`to run a command/switch to a tab/...`,
`to retrieve the user selected command`, `time,`, `the...that the`,
`the session's initial directory`, `that`, `that will ask`, `that the`,
`that opened the first flyout`, `same as terminal,`, `results,`,
`queue,`, `please`, `pane,`, `out-of-date`, `our`, `one`, `on-screen`,
`often`, `off-screen`, `of a`, `little-endian`, `left over`,
`includes, at a minimum,`, `know of`, `its`,
`if, after the calculation,`, `if`, `if we have an`, `if dragging`,
`if commands`, `guard,`, `given process information in a list`,
`from which`, `from creating`, `for which...`, `for the axis`,
`for initializing the buffer`, `containing the cursor`, `console-wait`,
`change`, `bytes`, `be`, `baseline,`, `aumid`, `at`, `ask me *again*`,
`an`, `also need to`, `again`, `add`, `add event`, `about spelunking`,
(rewrite `Appearances::_UpdateWithNewViewModel` comment), `'a'`, and ` (`
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
## Summary of the Pull Request
This PR introduces a new profile setting, `dragDropDelimiter`, which
allows users to configure the string separator used when dragging and
dropping multiple files into the terminal. The default behavior remains
a single space (`" "`) for backward compatibility.
## References and Relevant Issues
* Closes#19565
## Detailed Description of the Pull Request / Additional comments
**Implementation Details:**
* **Settings:** Added `DragDropDelimiter` to `MTSMSettings.h` and
`Profile.idl`.
* **Control:** Wired the setting through `ControlProperties.h` so the
terminal logic can see it.
* **Logic:** Updated `TermControl::OnDrop` to use the new delimiter when
joining paths.
* **UI:** Added the text box in the Advanced Settings page and updated
the ViewModel.
## Validation Steps Performed
* **Manual Verification:**
* Verified default behavior (space separator) works as before.
* Configured `dragDropDelimiter` to `", "`, `";"`, and custom strings in
`settings.json` and from settings UI.
* Confirmed dropped files are joined correctly.
* **Build:** Validated that the solution builds cleanly.
## Notes for Reviewers
1. **Delimiter Length:** Currently, there is no limit on the maximum
length of the delimiter string. Let me know if this should be changed.
3. **Localization:** I changed only `Resources/en-US` file.
4. **ViewModel:** In `ProfileViewModel.cpp`, I added the `else if` block
for the new setting, but left it empty because no other UI logic
currently depends on it.
## PR Checklist
- [x] Closes#19565
- [ ] Documentation updated
- [x] Schema updated (if necessary)
This PR introduces `compatibility.ambiguousWidth` as a **global**
compatibility setting (`narrow` default, `wide` optional).
The default remains `narrow`.
Why global-only in this PR:
- Width detection is currently process-wide (`CodepointWidthDetector`
singleton).
- True profile-level ambiguous-width behavior would require broader
architectural changes and is intentionally deferred to a follow-up
design/PR.
What this PR guarantees:
- Terminal-side handling is consistent end-to-end for the selected
ambiguous-width policy (rendering path + ConPTY/host propagation).
Known limitation:
- Some client applications (for example PSReadLine/readline-based apps)
may still compute character widths independently.
- In such cases, cursor movement or Backspace behavior can differ from
visual cell width even when terminal-side policy is consistent.
This is a compatibility/readability trade-off feature:
- `narrow`: prioritize cross-application compatibility.
- `wide`: prioritize readability with many CJK fonts.
Closes#153Closes#370
Refs #2928
Refs #2049, #2066, #2375, #900, #5910, #5914
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
## Summary of the Pull Request
Fixes a couple of minor issues in the settings schema which can result
in erroneous settings validation failures.
## References and Relevant Issues
None
## Detailed Description of the Pull Request / Additional comments
- `answerbackMessage`
Permit `null` type (corresponds to the default value).
- `compatibility.input.forceVT`
Add missing setting (previously was `experimental.input.forceVT`).
- `rendering.graphicsAPI`
Add missing `automatic` enumeration value.
- Mark several settings as deprecated using the same format and direct
the user to the updated settings to use.
## Validation Steps Performed
Tested updated schema against configuration with above settings present.
## PR Checklist
- [X] Schema updated (if necessary)
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Fixes the terminal profile jsonschema to allow for null in the id. This
is to match the current implementation when disabling a built in default
keybind.
## Summary of the Pull Request
This PR introduces an experimental setting that allows to toggle opacity
changes with scrolling.
## References and Relevant Issues
#3793
## Detailed Description of the Pull Request / Additional comments
By default, holding Ctrl + Shift while scrolling changes the terminal's
opacity. This PR adds an option to disable that behavior.
## Validation Steps Performed
I built the project locally and verified that the new feature works as
intended.
## PR Checklist
- [x] Resolves
https://github.com/microsoft/terminal/issues/3793#issuecomment-3085684640
- [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/873
- [X] Schema updated (if necessary)
This PR adds a new global setting `scrollToZoom` that allows users to
enable font zooming with scrolling. When disabled, **this setting
prevents accidental font size changes** that can occur when users scroll
while holding the Ctrl key.
Note: after disabling this setting, users may still change font size
using `Ctrl+` and `Ctrl-` keyboard shortcuts. Other Ctrl+Scroll
functionality (like transparency adjustments) remains unaffected.
## Validation Steps Performed
- Verified the setting can be toggled in the Settings UI (Interaction
tab)
- Confirmed that when disabled, holding Ctrl and scrolling no longer
changes font size
- Validated that the setting persists across terminal restarts
---
Note: I used the existing `FocusFollowMouse` setting as a reference for
implementing this.
Closes#11710Closes#3793Closes#11906Closes#3990
## Summary of the Pull Request
Support drag-n-drop path translation in the style used by MinGW
programs. In particular for usage with shells like `ash` from busybox
(https://frippery.org/busybox/).
## Detailed Description of the Pull Request / Additional comments
Provides a new option "mingw" for "pathTranslationStyle".
Shown as "MinGW" with translation documented as `(C:\ -> C:/)` in the
UI.
As per the other modes, this translates `\` to `/` but stops there.
There is no prefix/drive translation.
## Validation Steps Performed
Run using `busybox ash` shell. Dragged directories and files from both
local disks and network shares onto terminal. All were appropriately
single quoted and had their backslashes replaced with forward slashes.
They were directly usable by the `ash` shell.
Language files containing the other options have been updated to include
the new one.
## PR Checklist
- [ ] Closes #xxx
- [ ] Tests added/passed
- [x] Documentation updated
- [Docs PR #849](https://github.com/MicrosoftDocs/terminal/pull/849)
- [ ] Schema updated (if necessary)
Co-authored-by: Adam Butcher <adam@jessamine.uk>
Before we had a Settings UI, we added support for a setting called
`startOnUserLogin`. It was a boolean, and on startup we would try to
yeet the value of that setting into the Windows API responsible for
registering us as a startup task.
Unfortunately, we failed to take into account a few things.
- Startup tasks can be independently controlled by the user in Windows
Settings or by an enterprise using enterprise policy
- This control is not limited to *disabling* the task; it also supports
enabling it!
Users could enable our startup task outside the settings file and we
would never know it. We would load up, see that `startOnUserLogin` was
`false`, and go disable the task again. 🤦
Conversely, if the user disables our task outside the app _we can never
enable it from inside the app._ If an enterprise has configured it
either direction, we can't change it either.
The best way forward is to remove it from our settings model and only
ever interact with the Windows API.
This pull request replaces `startOnUserLogin` with a rich settings
experience that will reflect the current and final state of the task as
configured through Windows. Terminal will enable it if it can and
display a message if it can't.
My first attempt at this PR (which you can read in the commit history)
made us try harder to sync the state between the settings model and the
OS; we would propagate the disabled state back to the user setting when
the task was disabled in the OS or if we failed to enable it when the
user asked for it. That was fragile and didn't support reporting the
state in the settings UI, and it seems like it would be confusing for a
setting to silently turn itself back off anyway...
Closes#12564
This PR allows users to enable the tab bar in fullscreen mode.
A new setting; "showTabsFullscreen"; has been added which accepts a
boolean value. When `true`, then the tab bar will remain visible when
the terminal app is fullscreen. If the value is `false` (default), then
the tab bar is hidden in fullscreen.
When the tab bar is visible in fullscreen, the min/max/close controls
are hidden to maintain the expected behaviour of a fullscreen app.
## Validation Steps Performed
All unit tests are passing.
Manually verified that when the "launchMode" setting is "fullscreen" and
the "showTabsFullscreen" setting is `true`, the tab bar is visible on
launch.
Manually verified that changing the setting at runtime causes the tab
bar to be shown/hidden immediately (if the terminal is currently
fullscreen).
Manually verified that the new "showTabsFullscreen" setting is honoured
regardless of whether "showTabsInTitlebar" is set to `true` or `false`.
Closes#11130
This pull request introduces a new profile setting,
`compatibility.allowOSC52`, which defaults to `true`. When disabled, it
will not allow applications to write to the clipboard.
Security-minded folks may choose to disable it.
As before, a minor refactor:
* I started off by removing the Monarch/Peasant with the goal of moving
it into and deduplicating its functionality with `WindowEmperor`.
* Since I needed a replacement for the Monarch (= ensures that there's
a single instance), I wrote single-instance code with a NT mutex
and by yeeting data across processes with `WM_COPYDATA`.
* This resulted in severe threading issues, because it now started up
way faster. The more I tried to solve them the deeper I had to dig,
because you can't just put a mutex around `CascadiaSettings`.
I then tried to seeif WinUI can run multiple windows on a single
thread and, as it turns out, it can.
So, I removed the multi- from the window threading.
* At this point I had dig about 1 mile deep and brought no ladder.
So, to finish it up, I had to clean up the entire eventing system
around `WindowEmperor`, cleaned up all the coroutines,
and cleaned up all the callbacks.
Closes#16183Closes#16221Closes#16487Closes#16532Closes#16733Closes#16755Closes#17015Closes#17360Closes#17420Closes#17457Closes#17799Closes#17976Closes#18057Closes#18084Closes#18169Closes#18176Closes#18191
## Validation Steps Performed
* It does not crash ✅
* New/close tab ✅
* New/close window ✅
* Move tabs between windows ✅
* Split tab into new window ✅
* Persist windows on exit / restore startup ✅
## Summary of the Pull Request
Added open current directory action.
## References and Relevant Issues
Need to set this:
https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
- Ensure shell has been configured
- Run "Open current working directory" action in command palette
- File explorer opens the correct directory
## PR Checklist
- [x] Closes#12859
- [ ] 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 (if necessary)
This upgrades to [check-spelling v0.0.24].
A number of GitHub APIs are being turned off shortly, so we need to
upgrade or various uncertain outcomes will occur.
There are some minor bugs that I'm aware of and which I've fixed since
this release (including a couple I discovered while preparing this PR).
There's a new accessibility forbidden pattern:
#### Should be `cannot` (or `can't`)
See https://www.grammarly.com/blog/cannot-or-can-not/
> Don't use `can not` when you mean `cannot`. The only time you're
likely to see `can not` written as separate words is when the word `can`
happens to precede some other phrase that happens to start with `not`.
> `Can't` is a contraction of `cannot`, and it's best suited for
informal writing.
> In formal writing and where contractions are frowned upon, use
`cannot`.
> It is possible to write `can not`, but you generally find it only as
part of some other construction, such as `not only . . . but also.`
- if you encounter such a case, add a pattern for that case to
patterns.txt.
```
\b[Cc]an not\b
```
[check-spelling v0.0.24]: https://github.com/check-spelling/check-spelling/releases/tag/v0.0.24
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
## Summary of the Pull Request
This extends the copy command to be able to include control sequences,
for use in tools that subsequently know how to parse and display that.
## References and Relevant Issues
https://github.com/microsoft/terminal/issues/15703
## Detailed Description of the Pull Request / Additional comments
At a high level, this:
- Expands the `CopyTextArgs` to have a `withControlSequences` bool.
- Plumbs that bool down through many layers to where we actuall get
data out of the text buffer.
- Modifies the existing `TextBuffer::Serialize` to be more generic
and renames it to `TextBuffer::ChunkedSerialize`.
- Uses the new `ChunkedSerialize` to generate the data for the copy
request.
## Validation Steps Performed
To test this I've manually:
- Generated some styled terminal contents, copied it with the control
sequences, pasted it into a file, `cat`ed the file and seen that it
looks the same.
- Set `"firstWindowPreference": "persistedWindowLayout"` and
validated that the contents of windows are saved and
restored with styling intact.
I also checked that `Invoke-OpenConsoleTests` passed.
## PR Checklist
- [x] Closes#15703
- [ ] 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/756
- [x] Schema updated (if necessary)
`pathTranslationStyle` has four options:
- `none`: Do no translation
- `wsl`: Translate `C:\` to `/mnt/c` and `\\wsl$\Foo\bar` to `/bar`
- `cygwin`: Translate `C:\` to `/cygdrive/c`
- `msys2`: Translate `C:\` to `/c`
It is intended as a broadly-supported replacement for us checking the
source every time the user drops a path.
We no longer need to push the source name all the way down to the
control.
I am hesitant to commit to using other folks' product names in our
settings model,
however, these are almost certainly more recognizable than whatever
other weird
names we could come up with.
The Git Bash fragment extension profile could conceivably use
`pathTranslationStyle`
`msys2` to make sure drag/dropped paths look right.
## Summary of the Pull Request
This PR is to allow users to set a custom icon for entries in the new tab menu for "action" and "profile" type entries.
## References and Relevant Issues
This PR is in response to #18103
## Detailed Description of the Pull Request / Additional comments
It is now possible to specify an optional "icon" setting for any "action" or "profile" type entry in the "newTabMenu" JSON settings. When specified, this icon will be used as the menu icon for that action/profile in the new tab menu. If not specified, the action/profile definition's default icon will be used instead (if present).
The Cascadia settings schema ("doc/cascadia/profiles.schema.json") has been updated to reflect this.
## Validation Steps Performed
Manually tested with multiple combinations of icon settings:
- ActionEntry:
- valid path in action definition and new tab entry (renders new tab entry icon)
- valid path in action definition but no path in new tab entry (renders action definition icon)
- no path in action definition, valid path in new tab entry (renders new tab entry icon)
- invalid path in action definition, valid path in new tab entry (renders new tab entry icon)
- valid path in action definition, invalid path in new tab entry (renders no icon)
- invalid path in both (renders no icon)
- no path in both (renders no icon)
- ProfileEntry:
- valid path in new tab entry (renders new tab entry icon)
- no path in new tab entry (renders profile's default icon)
- invalid path in new tab entry (renders no icon)
## PR Checklist
- [x] Closes#18103
- [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: [#808](https://github.com/MicrosoftDocs/terminal/pull/808)
- [x] Schema updated (if necessary)
## Summary of the Pull Request
Adds a global Compatibility page to the settings UI. This page exposes
several existing settings and introduces a few new settings:
- compatibility.allowHeadless
- compatibility.isolatedMode
- compatibility.textMeasurement
- debugFeatures
This also adds a Terminal subpage for profiles in the settings UI. This
page includes:
- suppressApplicationTitle
- compatibility.input.forceVT
- compatibility.allowDECRQCRA
- answerbackMessage
Several smaller changes were accomplished as a part of this PR:
- `experimental.input.forceVT` was renamed to
`compatibility.input.forceVT`
- introduced the `compatibility.allowDECRQCRA` setting
- updated the schema for these new settings and
`compatibility.allowHeadless` (which was missing)
- add `Feature_DebugModeUI` feature flag to control if debug features
should be shown in the SUI
Verified accessible via Accessibility Insights
A part of #10000Closes#16672
Adds the following settings to the Interaction page under a Warnings subsection:
- ConfirmCloseAllTabs
- InputServiceWarning
- WarnAboutLargePaste
- WarnAboutMultiLinePaste
This also changes the JSON keys of those settings to be in the `warning` namespace as a QOL change for JSON users. We still handle the legacy keys, don't worry 😉.
#10000
As we discussed in bug bash.
There's really no downside to us enabling it by default (and leaving
showMarksOnScrollbar: false). It'll mark lines as "prompts" when the
user hits enter. This will have a couple good side effects:
* When folks have right-aligned prompts (like, from oh-my-posh), the
`enter` will terminate where shell integration thinks the command is, so
that the right-prompt doesn't end up in the commandline history
* the scrollToMark actions will Just Work without any other shell
integration
Closes#17632
The answerback feature allows for the user to define a message that the
terminal will transmit to the host whenever an `ENQ` (enquiry) control
character is received.
## Detailed Description of the Pull Request / Additional comments
In Windows Terminal, the message can be configured at the profile level
of the settings file, as a string property named `AnswerbackMessage`.
In ConHost, the message can be configured in the registry, again as a
string value with the name `AnswerbackMessage`.
## Validation Steps Performed
I've confirmed that the control is working as intended in both Windows
Terminal and ConHost using Vttest.
Closes#11946
- Remove the `deprecated` flag for the `keybindings` array now that we
have re-added that
- Update `userDefaults` to use the correct ID for the `Copy` command
As outlined in #16816, refactor `ActionMap` to use the new action IDs
added in #16904
## Validation steps performed
- [x] Legacy style commands are parsed correctly (and rewritten to the
new format)
- [x] Actions are still layered correctly and their IDs can be used to
'overwrite' actions in earlier layers
- [x] Keybindings that refer to an ID defined in another layer work
correctly
- [x] User-defined actions without an ID have one generated for them
(and their settings file is edited with it)
- [x] Schema updated
Refs #16816Closes#17133
Noticed all these while prepping for Build:
* Promotes the stabilized features out of `experimental.`
* fixes a bug where a nested command with a `name` would match to a
`renameWindow` action, instead of a command.
* Adds the tab theme icon style
* fixes a bug where `ScrollToMarkAction` wasn't in the list of possible
args, so they would incorrectly get flagged as `moveTab`
* outright adds `experimental.rightClickContextMenu` which was missing
(?)
Due to #16821 everything about #16104 broke. This PR rights the wrongs
by rewriting all the `Font`-based code to not use `Font` at all.
Instead we split the font spec once into font families, do a lot of
complex logic to split font axes/features into used and unused ones
and construct all the UI elements. So. much. boilerplate. code.
Closes#16943
## Validation Steps Performed
There are more edge cases than I can list here... Some ideas:
* Edit the settings.json with invalid axis/feature keys ✅
* ...out of range values ✅
* Settings UI reloads when the settings.json changes ✅
* Adding axes/features works ✅
* Removing axes/features works ✅
* Resetting axes/features works ✅
* Axes/features apply in the renderer when saving ✅
This removes `VtApiRoutines` and the VT passthrough mode.
Why? While VT passthrough mode has a clear advantage (doesn't corrupt
VT sequences) it fails to address other pain points (performance,
out-of-sync issues after resize, etc.). Alternative options are
available which have less restrictions.
Why now? It's spring! Spring cleanup!
This implements `SetForceFullRepaintRendering` and adds a new
`SetGraphicsAPI` function. The former toggles `Present1` on and off
and the latter allows users to explicitly request Direct2D/3D.
On top of these changes I did a minor cleanup of the interface,
because now that DxRenderer is gone we don't need all that anymore.
Closes#14254Closes#16747
## Validation Steps Performed
* Toggling Direct2D on/off changes colored ligature support ✅
* Toggling Present1 on/off can be observed in a debugger ✅
* Toggling WARP on/off changes GPU metrics ✅
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
With AtlasEngine being fairly stable at this point and being enabled
by default in the 1.19 branch, this changeset removes DxEngine.
## Validation Steps Performed
* WT builds and runs ✅
* WpfTestNetCore ✅
* Saving the config removes the `useAtlasEngine` key ✅
This addresses the following issues:
* The JSON Schema spec doesn't actually define whether objects with
a "properties" key still require `"type": "object"` or not.
VS Code for instance largely pretends as if it's implied, but when it
encounters them inside a `oneOf` tree, then it behaves as if it isn't.
In other words, we need to always set `"type": "object"`.
* Declaring an `oneOf` containing a `"type": "string"` and an `enum`
doesn't work, because if one of the `enum` cases is given, it results
in both variants to match, since any `enum` is also a `string`.
We have to use `anyOf` instead.
* `SuggestionSource` used `"BuiltinSuggestionSource"` inside a `type`
key which doesn't work. We have to use `$ref` for that.
Closes#13387
## Validation Steps Performed
* VS Code stops complaining ✅
* https://www.jsonschemavalidator.net/✅
This PR is a few things:
* part the first: Convert the `compatibility.reloadEnvironmentVariables`
setting to a per-profile one.
* The settings should migrate it from the user's old global place to the
new one.
* We also added it to "Profile>Advanced" while I was here.
* Adds a new pair of commandline flags to `new-tab` and `split-pane`:
`--inheritEnvironment` / `--reloadEnvironment`
* On `wt` launch, bundle the entire environment that `wt` was spawned
with, and put it into the `Remoting.CommandlineArgs`, and give them to
the monarch (and ultimately, down to `TerminalPage` with the
`AppCommandlineArgs`). DO THIS ALWAYS.
* As a part of this, we’ll default to _reloading_ if there’s no explicit
commandline set, and _inheriting_ if there is.
* For example, `wt -- cmd` would inherit, and `wt -p “Command Prompt”`
would reload.[^1]
* This is a little wacky, but we’re trying to separate out the
intentions here:
* `wt -- cmd` feels like “I want to run cmd.exe (in a terminal tab)”.
That feels like the user would _like_ environment variables from the
calling process. They’re doing something more manual, so they get more
refined control over it.
* `wt` (or `wt -p “Command Prompt”`) is more like, “I want to run the
Terminal (or, my Command Prompt profile) using whatever the Terminal
would normally do”. So that feels more like a situation where it should
just reload by default. (Of course, this will respect their settings
here)
## References and Relevant Issues
https://github.com/microsoft/terminal/issues/15496#issuecomment-1692450231
has more notes.
## Detailed Description of the Pull Request / Additional comments
This is so VERY much plumbing. I'll try to leave comments in the
interesting parts.
## PR Checklist
- [x] This is not _all_ of #15496. We're also going to do a `-E foo=bar`
arg on top of this.
- [x] Tests added/passed
- [x] Schema updated
[^1]: In both these cases, plus the `environment` setting, of course.
## Summary of the Pull Request
Closes#7158
Enabling Acrylic as both an appearance setting (with all the plumbing),
allowing it to be set differently in both focused and unfocused
terminals. EnableUnfocusedAcrylic Global Setting that controls if
unfocused acrylic is possible so that people can disable that behavior.
## References and Relevant Issues
#7158 , references: #15913 , #11092
## Detailed Description of the Pull Request / Additional comments
### Allowing Acrylic to be set differently in both focused and unfocused
terminals:
#### A
#### B
#### C
#### D
``` json
"profiles":
{
"list":
[
{
"commandline": "pwsh.exe",
"name": "A",
"unfocusedAppearance":
{
"useAcrylic": true,
},
"useAcrylic": true,
},
{
"commandline": "pwsh.exe",
"name": "B",
"unfocusedAppearance":
{
"useAcrylic": false,
},
"useAcrylic": true,
},
{
"commandline": "pwsh.exe",
"name": "C",
"unfocusedAppearance":
{
"useAcrylic": true,
},
"useAcrylic": false,
},
{
"commandline": "pwsh.exe",
"name": "D",
"unfocusedAppearance":
{
},
"useAcrylic": false,
},
]
}
```
- **A**: AcrylicBlur always on
- **B**: Acrylic when focused, not acrylic when unfocused
- **C**: Why the hell not. Not Acrylic when focused, Acrylic when
unfocused.
- **D:** Possible today by not using Acrylic.
### EnableUnfocusedACrylic global setting that controls if unfocused
acrylic is possible
So that people can disable that behavior:
### Alternate approaches I considered:
Using `_InitializeBackgroundBrush` call instead of
`_changeBackgroundColor(bg) in
``TermControl::_UpdateAppearanceFromUIThread`. Comments in this function
mentioned:
``` *.cs'
// In the future, this might need to be changed to a
// _InitializeBackgroundBrush call instead, because we may need to
// switch from a solid color brush to an acrylic one.
```
I considered using this to tackle to problem, but don't see the benefit.
The only time we need to update the brush is when the user changes the
`EnableUnfocusedAcrylic ` setting which is already covered by
`fire_and_forget TermControl::UpdateControlSettings`
### Supporting different Opacity in Focused and Unfocused Appearance???
This PR is split up in two parts #7158 covers allowing Acrylic to be set
differently in both focused and unfocused terminals. And
EnableUnfocusedAcrylic Global Setting that controls if unfocused acrylic
is possible so that people can disable that behavior.
#11092 will be about enabling opacity as both an appearance setting,
allowing it to be set differently in both focused and unfocused
terminals.
### Skipping the XAML for now:
“I actually think we may want to skip the XAML on this one for now.
We've been having some discussions about compatibility settings, global
settings, stuff like this, and it might be _more- confusing to have you
do something here. We can always add it in post when we decide where to
put it.”
-- Mike Griese
## Validation Steps Performed
#### When Scrolling Mouse , opacity changes appropriately, on opacity
100 there are no gray lines or artefacts
#### When Adjusting Opacity through command palette, opacity changes
appropriately, on opacity 100 there are no gray lines or artefacts
#### When opening command palette state goes to unfocused, the acrylic
and color change appropriately
#### Stumbled upon a new bug when performing validation steps #15913
## PR Checklist
- [x] Closes#7158
- [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 (if necessary)
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
_targets #15027_
Adds a new suggestion source, `tasks`, that allows a user to open the
Suggestions UI with `sendInput` commands saved in their settings.
`source` becomes a flag setting, so it can be combined like so:
```json
{
"keys": "ctrl+shift+h", "command": { "action": "suggestions", "source": "commandHistory", "useCommandline":true },
},
{
"keys": "ctrl+shift+y", "command": { "action": "suggestions", "source": "tasks", "useCommandline":false },
},
{
"keys": "ctrl+shift+b", "command": { "action": "suggestions", "source": ["all"], "useCommandline":true },
},
```
If a nested command has `sendInput` commands underneath it, this will
build a tree of commands that only include `sendInput`s as leaves (but
leave the rest of the nesting structure intact).
## References and Relevant Issues
Closes#1595
See also #13445
As spec'd in #14864
## Validation Steps Performed
Tested manually
