This PR adds a `searchWeb` command to search the selected text on the web.
Arguments:
- `queryUrl`: URL of the web page to launch (the selected text will be
inserted where the first `%s` is found in the query string)
To make the search text more "compact" and handle multi-line selections,
I'm concatenating the selected lines and replacing consecutive
whitespaces with a single space (we may change this with something more
clever in case).
## Validation Steps Performed
Manual testing with single, multi-line, block selections.
Closes#10175
---------
Co-authored-by: Marco Pelagatti <marco.pelagatti@iongroup.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
Oklab by Björn Ottosson is a color space that has less irregularities
than the CIELAB color space used for ΔE2000. The distance metric for
Oklab (ΔEOK) is defined by CSS4 as the simple euclidian distance.
This allows us to drastically simplify the code needed to determine
a color that has enough contrast. The new implementation still lacks
proper gamut mapping, but that's another and less important issue.
I also made it so that text with the dim attribute gets adjusted just
like regular text, since this is an accessibility feature after all.
The new code is so much faster than the old code (12-125x) that I
dropped any caching code we had. While this increases the CPU overhead
when printing lots of indexed colors, the code is way less complex now.
"Increases" in this case however means something in the order of 15-60ns
per color change (as measured on my CPU). It's possible to further
improve the performance using explicit SIMD instructions, but I've
left that as a future improvement, since that will make the code quite
a bit more verbose and I didn't want to hinder the initial review.
Finally, these new routines are also used for ensuring that the
AtlasEngine cursors remains visible at all times.
Closes#9610
## Validation Steps Performed
* When `adjustIndistinguishableColors` is enabled
colors are distinguishable ✅
* An inverted cursor on top of a `#7f7f7f` foreground & background
is still visible ✅
* A colored cursor on top of a background with identical color
is still visible ✅
* Cursors on a transparent background are visible ✅
This MR introduces `activeOnly ` for the `showCloseButton` theme option
causing the close button only to appear on the active tab.
This is more or less following the approach explained here
https://github.com/orgs/microsoft/projects/686/views/2?pane=issue&itemId=19775774
which indeed just works 😄 .
You notice when switching theme the close buttons is back on all tabs
again as well.
Closes#13672
I didn't check specific unit tests for this. I hope by making this MR
the pipeline will show if I broke something. Or just let me know if you
want me to add something specific for this.
Existing environment variables can be referenced by enclosing the name
in percent characters (e.g. `%PATH%`).
Resurrects #9287 by @christapley.
Tests added and manually tested.
Closes#2785Closes#9233
Co-authored-by: Chris Tapley <chris.tapley.81@gmail.com>
## Summary
_In the days of old, the windows were sundered, each with its own
process, like the scattered stars in the sky. But a new age hath dawned,
for all windows now reside within a single process, like the bright gems
of a single crown._
_And lo, there came the `WindowEmperor`, a new lord to rule over the
global state, wielding the power of hotkeys and the beacon of the
notification icon. The `WindowManager` was cast aside, no longer needed
to seek out other processes or determine the `Monarch`._
_Should the `WindowEmperor` determine that a new window shall be raised,
it shall set forth a new thread, born from the ether, to govern this new
realm. On the main thread shall reside a message loop, charged with the
weighty task of preserving the global state, guarded by hotkeys and the
beacon of the notification icon._
_Each window doth live on its own thread, each guarded by the new
`WindowThread`, a knightly champion to hold the `TerminalWindow`,
`AppHost`, and `IslandWindow` in its grasp. And so the windows shall run
free, no longer burdened by their former ways._
All windows are now in a single process, rather than in one process per
window. We'll add a new `WindowEmperor` class to manage global state
such as hotkeys and the notification icon. The `WindowManager` has been
streamlined and no longer needs to connect to other processes or
determine a new `Monarch`. Each window will run on its own thread, using
the new `WindowThread` class to encapsulate the thread and manage the
`TerminalWindow`, `AppHost`, and `IslandWindow`.
* Related to #5000
* Related to #1256
## Windows Terminal Process Model 3.0
Everything is now one process. All the windows for a single Terminal
instance live in a singular Terminal process. When a new terminal
process launches, it will still attempt to communicate with an existing
one. If it finds one, it'll pass the commandline to that process and
exit. Otherwise, it'll become the "monarch" and create a new window.
We'll introduce a new abstraction here, called the `WindowEmperor`.
`Monarch` & `Peasant` will still remain, for facilitating cross-window
communication. The Emperor will allow us to have a single dedicated
class for all global state, and will now always represent the "monarch"
(rather than our previously established non-deterministic monarchy to
elevate a random peasant to the role of monarch). We still need to do a
very minimal amount of x-proc calls. Namely, one right on startup, to
see if another `Terminal.exe` was already running. If we find one, then
we toss our commandline at it and bail. If we don't, then we need to
`CoRegister` the Monarch still, to prepare for subsequent launches to
send commands to us.
`WindowManager` takes the most changes here. It had a ton of logic to
redundantly attempt to connect to other monarchs of other processes, or
elect a new one. It doesn't need to do any of that anymore, which is a
pretty dramatic change to that class.
This creates the opportunity to move some lifetime management around.
We've played silly games in the past trying to have individual windows
determine if they're the singular monarch for global state.
`IslandWindow`s no longer need to track things like global hotkeys or
the notification icon. The emperor can do that - there's only ever one
emperor. It can also own a singular copy of the settings model, and hand
out references to each other thread.
Each window lives on separate threads. We'll need to separately
initialize XAML islands for each thread. This is totally fine, and
actually supported these days. We'll use a new class called
`WindowThread` to encapsulate one of these threads. It'll be responsible
for owning the `TerminalWindow`, `AppHost` and `IslandWindow` for a
single thread.
This introduces new classes of bugs we'll need to worry about. It's now
easier than ever to have "wrong thread" bugs when interacting with any
XAML object from another thread. A good case in point - we used to stash
a `static` `Brush` in `Pane`, for the color of the borders. We can't do
that anymore! The first window will end up stashing a brush from its
thread. So now when a second window starts, the app explodes, because
the panes of that window try to draw their borders using a brush from
the wrong thread.
_Another fun change_: The keybinding labels of the command palette.
`TerminalPage` is the thing that ends up expanding iterable `Command`s.
It does this largely with copies - it makes a new `map`, a new `vector`,
copies the `Command`s over, and does the work there before setting up
the cmdpal.
Except, it's not making a copy of the `Command`s, it's making a copy of
the `vector`, with winrt objects all pointing at the `Command` objects
that are ultimately owned by `CascadiaSettings`.
This doesn't matter if there's only one `TerminalPage` - we'll only ever
do that once. However, now there are many Pages, on different threads.
That causes one `TerminalPage` to end up expanding the subcommands of a
`Command` while another `TerminalPage` is ALSO iterating on those
subcommands.
_Emperor message window_: The Emperor will have its own HWND, that's
entirely unrelated to any terminal window. This window is a
`HWND_MESSAGE` window, which specifically cannot be visible, but is
useful for getting messages. We'll use that to handle the notification
icon and global hotkeys. This alleviates the need for the IslandWindow
to raise events for the tray icon up to the AppHost to handle them. Less
plumbing=more good.
### Class ownership diagram
_pretend that I know UML for a second_:
```mermaid
classDiagram
direction LR
class Monarch
class Peasant
class Emperor
class WindowThread
class AppHost
Monarch "1" --o "*" Peasant: Tracks
Emperor --* "1" AppLogic:
Monarch <..> "1" Emperor
Peasant "1" .. "1" WindowThread
Emperor "1" --o "*" WindowThread: Tracks
WindowThread --* AppHost
AppHost --* IslandWindow
AppHost --* TerminalWindow
TerminalWindow --* TerminalPage
```
* There's still only one `Monarch`. One for the Terminal process.
* There's still many `Peasant`s, one per window.
* The `Monarch` is no longer associated with a window. It's associated
with the `Emperor`, who maintains _all_ the Terminal windows (but is not
associated with any particular window)
* It may be relevant to note: As far as the `Remoting` dll is concerned,
it doesn't care if monarchs and peasants are associated with windows or
not. Prior to this PR, _yes_, the Monarch was in fact associated with a
specific window (which was also associated with a window). Now, the
monarch is associated with the Emperor, who isn't technically any of the
windows.
* The `Emperor` owns the `App` (and by extension, the single `AppLogic`
instance).
* Each Terminal window lives on its own thread, owed by a `WindowThread`
object.
* There's still one `AppHost`, one `IslandWindow`, one `TerminalWindow`
& `TerminalPage` per window.
* `AppLogic` hands out references to its settings to each
`TerminalWindow` as they're created.
### Isolated Mode
This was a bit of a tiny brainstorm Dustin and I discussed. This is a
new setting introduced as an escape watch from the "one process to rule
them all" model. Technically, the Terminal already did something like
this if it couldn't find a `Monarch`, though, we were never really sure
if that hit. This just adds a setting to manually enable this mode.
In isolated mode, we always instantiate a Monarch instance locally,
without attempting to use the `CoRegister`-ed one, and we _never_
register one. This prevents the Terminal from talking with other
windows.
* Global hotkeys won't work right
* Trying to run commandlines in other windows (`wt -w foo`) won't work
* Every window will be its own process again
* Tray icon behavior is left undefined for now.
* Tab tearout straight-up won't work.
### A diagram about settings
This helps explain how settings changes get propagated
```mermaid
sequenceDiagram
participant Emperor
participant AppLogic
participant AppHost
participant TerminalWindow
participant TerminalPage
Note Right of AppLogic: AL::ReloadSettings
AppLogic ->> Emperor: raise SettingsChanged
Note left of Emperor: E::...GlobalHotkeys
Note left of Emperor: E::...NotificationIcon
AppLogic ->> TerminalWindow: raise SettingsChanged<br>(to each window)
AppLogic ->> TerminalWindow:
AppLogic ->> TerminalWindow:
Note right of TerminalWindow: TW::UpdateSettingsHandler
Note right of TerminalWindow: TW::UpdateSettings
TerminalWindow ->> TerminalPage: SetSettings
TerminalWindow ->> AppHost: raise SettingsChanged
Note right of AppHost: AH::_HandleSettingsChanged
```
Adds a global setting `compatibility.reloadEnvironmentVariables` with a
default value of `true`. When set, during connection creation a new
environment block will be generated to ensure it has the latest
environment variables.
Closes#1125
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Does what it says in the title. After this commit you can customize the height
and width of the terminal's cells. This commit supports parts of CSS'
`<length-percentage>` data type: Font-size relative sizes as multiples (`1.2`),
percentage (`120%`), or advance-width relative (`1.2ch`), as well as absolute
sizes in CSS pixels (`px`) or points (`pt`).
This PR is neither bug free in DxEngine, nor in AtlasEngine.
The former fails to implement glyph advance corrections (for instance #9381),
as well as disallowing glyphs to overlap rows. The latter has the same
overlap issue, but more severely as it tries to shrink glyphs to fit in.
Closes#3498Closes#14068
## Validation Steps Performed
* Setting `height` to `1` creates 12pt tall rows ✅
* Setting `height` to `1ch` creates square cells ✅
* Setting `width` to `1` creates square cells ✅
* Setting `width` or `height` to `Npx` or `Npt` works ✅
* Trailing zeroes are trimmed properly during serialization ✅
* Patching the PR to allow >100 line heights and entering "100.123456"
displays 6 fractional digits ✅
What it says on the tin.
I finally figured out the right way to validate schema updates in VsCode, which made this a lot faster. Tossed notes in the wiki for next time I do this.
Closes#14560
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/2634-broadcast-input/doc/specs/drafts/%232634%20-%20Broadcast%20Input/%232634%20-%20Broadcast%20Input.md) ⇐
## Summary of the Pull Request
This is supposed to be a quick and dirty spec to socialize the various different options for Broadcast Input mode with the team. Hopefully we can come up with a big-picture design for the feature, so we can unblock #9222.
### Abstract
> With a viable prototype in #9222, it's important that we have a well-defined
> plan for how we want this feature to be exposed before merging that PR. This
> spec is intended to be a lighter-than-usual spec to build consensus on the
> design of how the actions should be expressed.
...
> _**Fortunately**_: All these proposals actually use the same set of actions. So
> it doesn't _really_ matter which we pick right now. We can unblock #9222 as
> the implementation of the `"tab"` scope, and address other scopes in the future.
> We should still decide long-term which of these we'd like, but the actions seem
> universal.
## PR Checklist
* [x] Specs: #2634
* [x] References: #9222, #4998
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
_\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
The release of Windows Terminal has served as a way to reinvigorate the command-line ecosystem on Windows by providing a modern experience that is consistently updated. This experience has caused faster innovation in the Windows command-line ecosystem that can be seen across various areas like expanded virtual terminal sequence support and enhanced accessibility. Command-line apps can now leverage these innovations to create a better experience for the end-user.
Since accessibility is a very broad area, this document is intended to present recent innovations in the accessibility space for the command-line ecosystem. Furthermore, it will propose additional improvements that can be made alongside key stakeholders that could benefit from such changes.
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie%2Fs%2F642-logging/doc/specs/drafts/%23642%20-%20Buffer%20Exporting%20and%20Logging/%23642%20-%20Buffer%20Exporting%20and%20Logging.md) ⇐
## Summary of the Pull Request
This is an intentionally brief spec to address the full scope of #642. The
intention of this spec is to quickly build consensus around all the features we
want for logging, and prepare an implementation plan.
### Abstract
> A common user need is the ability to export the history of a terminal session to
> a file, for later inspection or validation. This is something that could be
> triggered manually. Many terminal emulators provide the ability to automatically
> log the output of a session to a file, so the history is always captured. This
> spec will address improvements to the Windows Terminal to enable these kinds of
> exporting and logging scenarios.
## PR Checklist
* [x] Specs: #642
* [x] References: #5000, #9287, #11045, #11062
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
_\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
## Open Discussion
* [ ] What formatting string syntax and variables do we want to use?
* [ ] How exactly do we want to handle "log printable output"? Do we include backspaces? Do we only log on newlines?
* [ ] > maybe consider even simpler options like just `${date}` and `${time}`, and allow for future variants with something like `${date:yyyy-mm-dd}` or `${time:hhmm}`
Implements an initial version of #1571 as it has been specified, the
only big thing missing now is the possibility to add actions, which
depends on #6899.
Further upcoming spec tracked in #12584
Implemented according to [instructions by @zadjii-msft]. Mostly
relatively straightforward, but some notable details:
- In accordance with the spec, the counting/indexing of profiles is
based on their index in the json (so the index of the profile, not of
the entry in the menu).
- Resolving a profile name to an actual profile is done in a similar
fashion as how currently the `DefaultProfile` field is populated: the
`CascadiaSettings` constructor now has an extra `_resolve` function
that will iterate over all entries and resolve the names to instances;
this same function will compute all profile sets (the set of all
profiles from source "x", and the set of all remaining profiles)
- ~Fun~ fact: I spent two whole afternoons and evenings trying to add 2
classes (which turned out to be a trivial `.vcxproj` error), and then
managed to finish the entire rest of it in another afternoon and
evening...
## Validation Steps Performed
A lot of manual testing; as mentioned above I was not able to run any
tests so I could not add them for now. However, the logic is not too
tricky so it should be relatively safe.
Closes#1571
[instructions by @zadjii-msft]: https://github.com/microsoft/terminal/issues/1571#issuecomment-1184851000
<!-- 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 pull request solved the problem of users not being able to set color schemes specifically for dark or light mode. Now the code has been updated to accept a dark and light color scheme in the json. The old setting is still compatible. Keep in mind if you update your color scheme through the settings UI, it will set both dark and light to the color scheme selected. This is because the settings UI update for selecting both Dark and Light color schemes is not supported yet.
This also solves the problem of the UI not using the system OS theme. Now you can select system theme and your color scheme will be selected based on if the system theme is dark or light.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4066
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4066
* [x] Closes#14050
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA.
* [x] Tests added/passed I believe so, added one test to ColorSchemeTests.cpp and I believe it passed. Also had to modify TerminalSettingsTests.cpp to accept the new ApplyAppearanceSettings function template
* [ ] 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'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: #4066 and also teams messages with @carlos-zamora
<!-- 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
-Removed ColorSchemeName from MTSMSettings.h in order to process the setting for both string and object.
-Added DarkColorSchemeName and LightColorSchemeName properties to the AppearanceConfig to replace ColorSchemeName.
-Hacked a few processes to play nice with all 3 properties listed above as in some cases around the UI, we need to still use the ColorSchemeName. Once we change the UI I believe we can go back to just Dark and LightColorSchemeName
-Added and Updated Test to align to the new code.
Acceptable Json values,
"colorScheme":
{
"dark": "Campbell",
"light": "Campbell"
}
or
"colorScheme": "Campbell"
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Individual testing along with the test case added.
Upgrades check-spelling to v0.0.21
The command to apply changes should now work on Windows (it requires
Perl, but I believe that's more or less present most of the time, and it
should walk you through the rest of the required tools).
There are a bunch of new features, the most important here are probably
being able to update the metadata from Windows. (If it doesn't work,
please @ me).
Also, candidate.patterns will automatically suggest patterns. You can
see them in patterns.txt, e.g.:
```
# Automatically suggested patterns
# hit-count: 3831 file-count: 582
# IServiceProvider
\bI(?=(?:[A-Z][a-z]{2,})+\b)
```
The metadata bits (the hit count/file count) don't have to be retained
(I hope they'll be useful in deciding whether/or not to add a pattern,
i.e. "how applicable is it?"), the comment hinting at what the pattern
does is probably worth retaining.
We've been using more or less this version for a while internally
(including talk-to-bot, and, I do have a pattern that could be used to
let people use that in forks, but, I'm going to skip that for now).
This weekend, I did some cleanup for `act` (to run check-spelling
locally), and some minor polish.
You can see the runs I made in
https://github.com/check-spelling/terminal/actions
Doc updated in response to some discussion in [#11326] and
[#7774]. In those PRs, it became clear that there needs to be a simple way of
collecting up a whole group of profiles automatically for sorting in these
menus. Although discussion centered on how hard it would be for extensions to
provide that customization themselves, the `match` statement was added as a way
to allow the user to easily filter those profiles themselves.
This was something we had originally considered as a "future consideration", but
ultimately deemed it to be out of scope for the initial spec review.
References:
* #1571
* #11326
* #7774
Fix a missing entry in the JSON schema for `intenseTextStyle`.
The JSON schema was missing an entry in the Profile section for
`intenseTextStyle`. I have added it as it appears in AppearanceConfig.
Note that this is currently duplicated in the schema -- however, this is
the pattern used already in Profile as AppearanceConfig entries have
alternate descriptions (and I have updated the description in that
section to make it clear it applies to unfocused terminals).
Longer-term, it likely makes sense to consolidate all entires into
ApperanceConfig and rely on the description for the `unfocusedApperance`
object/the name of the object to make the limited scope of those keys
clear, so that Profile can simply extend ApperanceConfig and the
duplication in the schema can be reduced.
## Validation Steps Performed
Validation with schema verifying tools including VS Code.
Partially addresses #13387
The diff between the 22000 and 22621 SDKs is fairly small, but it does include
a number of C++ correctness fixes, updates to libraries like DirectXMath and
the latest updates to DirectWrite and DXGI which I make heavy use off.
## Validation Steps Performed
* It builds ✅
This fixes#3454 by adding support for an "always" mode for the scroll bar.
This change uses a custom VisualStateManager to keep the scroll bar from collapsing if the profile is using the 'always' setting.
## Validation Steps Performed
Tried updating settings.json directly and using the UI and making sure the scroll bar behaves as expected.
Closes#3454
After this commit a user may specify fractional font sizes.
Support was only implemented for AtlasEngine however.
DxEngine continues to use rounded (integer) font sizes.
Closes#6678
## Validation Steps Performed
* Install a bitmap font that requires fractional font sizes
(e.g. Terminus TTF, https://files.ax86.net/terminus-ttf/)
* Set font size to something integer (e.g. 14pt)
Glyphs are blurry ✅
* Set font size to something fractional (e.g. 13.5pt)
Glyphs are crisp ✅
With AtlasEngine being enabled by default in 1.16 Preview it would look weird
if the `useAtlasEngine` option would still be called "experimental".
Additionally we're interested in how many users opt out of useAtlasEngine,
indicating major issues that would require us to disable it by default again.
Related to #13936
## Validation Steps Performed
* Toggling `useAtlasEngine` works as expected ✅
* Observe new event with TVPP ✅
## Summary of the Pull Request
As described in #9583, this change implements the legacy conhost "EnableColorSelection" feature.
## Detailed Description of the Pull Request / Additional comments
@zadjii-msft was super nice and provided the outline/plumbing (WinRT classes and such) as a hackathon-type project (thank you!)--a "SelectionColor" runtimeclass, a ColorSelection method on the ControlCore runtimeclass, associated plumbing through the layers; plus the action-and-args plumbing to allow hooking up a basic "ColorSelection" action, which allows you to put actions in your settings JSON like so:
```json
{
"command":
{
"action": "experimental.colorSelection",
"foreground": "#0f3"
},
"keys": "alt+4"
},
```
On top of that foundation, I added a couple of things:
* The ability to specify indexes for colors, in addition to RGB and RRGGBB colors.
- It's a bit hacky, because there are some conversions that fight against sneaking an "I'm an index" flag in the alpha channel.
* A new "matchMode" parameter on the action, allowing you to say if you want to only color the current selection ("0") or all matches ("1").
- I made it an int, because I'd like to enable at least one other "match mode" later, but it requires me/someone to fix up search.cpp to handle regex first.
- Search used an old UIA "ColorSelection" method which was previously `E_NOTIMPL`, but is now wired up. Don't know what/if anything else uses this.
* An uber-toggle setting, "EnableColorSelection", which allows you to set a single `bool` in your settings JSON, to light up all the keybindings you would expect from the legacy "EnableColorSelection" feature:
- alt+[0..9]: color foreground
- alt+shift+[0..9]: color foreground, all matches
- ctrl+[0..9]: color background
- ctrl+shift+[0..9]: color background, all matches
* A few of the actions cannot be properly invoked via their keybindings, due to #13124. `*!*` But they work if you do them from the command palette.
* If you have "`EnableColorSelection : true`" in your settings JSON, but then specify a different action in your JSON that uses the same key binding as a color selection keybinding, your custom one wins, which I think is the right thing.
* I fixed what I think was a bug in search.cpp, which also affected the legacy EnableColorSelection feature: due to a non-inclusive coordinate comparison, you were not allowed to color a single character; but I see no reason why that should be disallowed. Now you can make all your `X`s red if you like.
"Soft" spots:
* I was a bit surprised at some of the helpers I had to provide in textBuffer.cpp. Perhaps there are existing methods that I didn't find?
* Localization? Because there are so many (40!) actions, I went to some trouble to try to provide nice command/arg descriptions. But I don't know how localization works…
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#9583
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed *(what would be the right place to add tests for this?)*
* [ ] 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. *(is this needed?)*
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
Just manual testing.
## Summary of the Pull Request
Introduces a new action `expandSelectionToWord()` which expands the beginning and end of the selection to encompass the word(s) it's on. This was implemented as a conditional keybinding where the key chord is passed through to the terminal if no selection is active (similar to `copy()`).
It is not bound to anything by default.
## PR Checklist
* [x] Closes#8274
* [x] Schema updated.
## Validation Steps Performed
- Scenario in #8274:
- search for some text in the find dialog
- ESC to close the dialog
- execute `expandSelectionToWord()`
- the new selection encompasses the whole word
- mark mode
- move onto a word
- execute `expandSelectionToWord()`
- mouse selection (same as above)
- select a portion of two words --> new selection fully encompasses both words
This PR introduces a new action for closing all unfocused / other panes within a tab.
**Edit (17-08-2022):** Read-only panes are ignored when this action is being used (i.e., left open).
## Validation Steps Performed
The action was manually tested by applying it to various 'compositions' of panes. This includes tests on read-only panes.
Closes#12216
Updates the schema such that the scroll mark settings are defined as profile settings instead of global settings (because they're actually profile settings).
Separately (but still relevant), I've also updated the release notes.
Closes#13583
## Summary of the Pull Request
Adds a new mode to `CloseOnExit`: `Automatic`. In this mode, if a process handed off by defterm terminates for whatever reason, we always close (i.e. we treat the mode as `Always`), but for processes launched by Terminal we terminate as with the `Graceful` behaviour.
## PR Checklist
* [x] Closes#13325
* [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'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
- Adds a new enum value to `CloseOnExit`
- Adds a new function to `Pane`: `FinalizeConfigurationGivenDefault`: this is a function that should be called when the pane is created via default terminal handoff, and can contain any special configurations we should set given that the pane was created via handoff
## Validation Steps Performed
While working on another PR related to this I noticed that my VS
generates `.vcxproj` files that are a bit different to the ones we have.
This commit is a quick search & replace of all our project files to make
(primarily) their `ToolsVersion` more in line with what VS does itself:
No `ToolsVersion` for `.vcxproj`, `ToolsVersion="15.0"`
for `.csproj` and `ToolsVersion="4.0"` for `.filters` files.
I was messing around with trying to build & deploy from the commandline. I discovered this, which is progress. However, the inner-loop commandline build for the Terminal is still egregiously long.
* just a docs update
* is EIM work
## Summary of the Pull Request
This is a spec specifically dedicated to Mark Mode. It's an addition to the Keyboard Selection spec. I felt that it makes the most sense to make this a separate PR because there's a lot of ideas that are very specific to Mark Mode, and this gives us the space to modify some of that behavior and get a good look at how other terminal emulators designed this feature.
## References
#2840 - Keyboard Selection Spec (base spec/branch/PR)
## PR Checklist
* [X] Contributes to #715
Upgrade check-spelling to [v0.0.20](https://github.com/check-spelling/check-spelling/releases/tag/v0.0.20)
This upgrade includes a refresh of the workflow
key new features:
* the previous comment is collapsed
* duplicate words are flagged (see `alone` and `the`)
* forbidding patterns (see `nonexistent`, `preexisting`, and `greater than`)
Each of these features can be tuned
- comment collapsing is controlled by the `followup` bits in the workflow-- but I can't imagine why one would want to turn it off
- duplicate words can be masked in `patterns.txt` (see `Guid` and `that`)
- forbidding patterns (especially duplicates) is in `.github/actions/spelling/line_forbidden.patterns`
Fwiw, I'm slowly moving towards not using `.txt` in filenames, but it's a long term project and I have a bunch of other goals for the near term.
The refresh of advice is of course flexible -- I'm still evolving my default text. Note that the default now includes some `curl` and I'm still working on how I want to consume the output. I'm getting close to the point where I might be able to provide a tool that could reliably consume the output (including on Windows).
This code has been used internally for a while, but I tested it for this repository here:
https://github.com/check-spelling/terminal/pull/2
## Summary of the Pull Request
`AdjustIndistinguishableColors` can now be set to:
- `Never`: Never adjust the colors
- `Indexed`: Only adjust colors that are part of the color scheme
- `Always`: Always adjust the colors
## References
#13343
## 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'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
For legacy purposes, `true` and `false` map to `Indexed` and `Never` respectively
## Validation Steps Performed
Setting still works
<!-- 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
Added setting for for hide window when it loses focus.
Works on normal window and quake window.
<!-- 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#10660
* [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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- Enable **Settings > Appearance > Automatically hide window**
- Terminal window should be minimized on taskbar when it loses focus
- Quake window should be minimized on system tray when it loses focus
- Enable also **Settings > Appearance > Hide Terminal in the notification area when it is minimized**
- Terminal window should be minimized on system tray when it loses focus
- Quake window should be minimized on system tray when it loses focus
⚠️ This spec is going into the `specs/drafts/` folder, because it's CLEARLY not done yet.
I discussed this a bit with Dustin. We felt it would be valuable to have these thoughts committed as a durable artifact. Better to have our Mica thoughts written down somewhere, with the context they belong in. That of course includes the bigger Theming spec, which never got finished.
I don't think we need to go through the fill spec review for this. Theming is clearly still a WIP. But committing this draft should give a better picture of what the vision is.
See also:
* #3327
* #10509
### TODOs
* [ ] The many that are straight up in the doc
* [ ] The fact that there's multiple Mica's now
* [ ] GO look at MSFT:39027976
## Summary of the Pull Request
Introduces the `switchSelectionEndpoint` action which switches whichever selection endpoint is targeted when a selection is present. For example, if you are targeting "start", `switchSelectionEndpoint` makes it so that now you are targeting "end". This also updates the selection markers appropriately.
## References
Spec - #5804#13358Closes#3663
## Detailed Description of the Pull Request / Additional comments
Most of the code is just standard code of adding a new action. Other than that, we have...
- if there is no selection, the action fails and the keybinding is passed through (similar to `copy()`)
- when we update the selection endpoint, we need to also update the "pivot". This ensures that future calls of `UpdateSelection()` respect this swap.
- [Corner Case] if the cursor is being moved, we make it so that you basically "anchored" an endpoint and you don't have to hold shift anymore.
## Summary of the Pull Request
1. [copy on select] when manually copying text (i.e. kbd or right-click) while in mark/quick-edit mode, we now dismiss the selection.
2. `Enter` is now bound to copy by default.
- This works very well with mark mode and provides a more consistent behavior with conhost's selection experience overall.
- "why not hardcode `Enter` as a way to copy when in mark mode?"
- In an effort to make this as configurable as possible, I decided to make it a configurable keybinding, but am open to suggestions.
3. selection markers
a. we now hide the selection markers when multi-clicking the terminal.
b. selection markers are now properly shown when a single cell selection exists
- Prior to this PR, any single cell selection would display both markers. Now, we actually track which endpoint we're moving and display the appropriate one.
4. ensures that when you use keyboard selection to move past the top/bottom of the scroll area, we clamp it to the origin/bottom-right respectively. The fix is also better here in that it provides consistent behavior across all of the `_MoveByX` functions.
5. adds `toggleBlockSelection` to the schema
## References
#13053
## Validation Steps Performed
Did a whole flowchart of expected behavior with copy on select:
- enable `copyOnSelect`
- make a selection with the mouse
- ✅ right-click should copy the text --> clear the selection --> paste
- use keyboard selection to quick-edit the existing selection
- ✅ `copy` action should clear the selection
- ✅ right-click should copy the text --> clear the selection --> paste
Played with selection markers a bit in mark mode and quick edit mode. Markers are updating appropriately.
## Summary of the Pull Request
Introduces a non-configurable version of mark mode to Windows Terminal. It has the following interactions defined:
- <kbd>ctrl+shift+m</kbd> --> Enter Mark Mode
- when in Mark Mode...
- <kbd>ESC</kbd> --> Exit Mark Mode
- arrow keys --> move "start"
- <kbd>shift</kbd> + arrow keys --> anchor "start", move "end"
- <kbd>ctrl+a</kbd> --> select all
- when a selection is active...
When in mark mode, the cursor does not blink.
## References
#4993 - [Epic] Keyboard Selection
## PR Checklist
* [X] Closes#715
* [X] Provides a resolution for #11985
## Detailed Description of the Pull Request / Additional comments
- `TermControl`:
- `TermControl.cpp` just adds logic to prevent the cursor from blinking when in mark mode
- `ControlCore`
- in the same place we handle quick edit, we add an entry point to mark mode
- `TerminalCore`
- this leverages `UpdateSelection()` and other quick edit functions to make mark mode happen
## Validation Steps Performed
- [x] Make selection, split pane, close pane
- NOTE: A similar scenario caused a crash at one point. Really weird. Keep an eye on it.
- [x] Cursor is off when in mark mode
- [x] general movement/selection
- [x] general movement/selection that forces the viewport to move
- [x] In mark mode, selectAll...
- [x] arrow keys --> move start
- [x] shift + arrow keys --> move end
- [x] (regardless of mark mode) if selection active, enter --> copy to clipboard
Propagate show/hide window calls against the ConPTY pseudo window to the Terminal
## PR Checklist
* [x] Closes#12570
* [x] I work here
* [x] Manual Tests passed
* [x] Spec Link: →[Doc Link](https://github.com/microsoft/terminal/blob/dev/miniksa/msgs/doc/specs/%2312570%20-%20Show%20Hide%20operations%20on%20GetConsoleWindow%20via%20PTY.md)←
## Detailed Description of the Pull Request / Additional comments
- See the spec. It's pretty much everything I went through deciding on this.
## Validation Steps Performed
- [x] Manual validation against scratch application calling all of the `::ShowWindow` commands against the pseudo console "fake window" and observing the real terminal window state
<!-- 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
Specs for feature request "Theme-controlled color scheme switch".
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4066
MPela
