Our existing preview text was not very helpful in learning how different
settings impacted the display of text in Terminal.
This new preview text contains:
* Bold text, which is controlled by intenseTextStyle
* Colors
* Emoji
* A cursor, which overlaps a single character to show inversion behavior
Some of these were reundant, and some didn't feel right when I read
them.
Oh, and I got rid of all of these particularly unhelpful or non-additive
resources:
```
Color Scheme [ v ]
Is a color scheme
```
This PR introduces two new escapes sequences: `DECLRMM` (Left Right
Margin Mode), which enables the horizontal margin support, and `DECSLRM`
(Set Left and Right Margins), which does exactly what the name suggests.
A whole lot of existing operations have then been updated to take those
horizontal margins into account.
## Detailed Description of the Pull Request / Additional comments
The main complication was in figuring out in what way each operation is
affected, since there's a fair amount of variation.
* When writing text to the buffer, we need to wrap within the horizontal
margins, but only when the cursor is also within the vertical margins,
otherwise we just wrap within the boundaries of the screen.
* Not all cursor movement operations are constrained by the margins, but
for those that are, we clamp within both the vertical and horizontal
margins. But if the cursor is already outside the margins, it is just
clamped at the edges of the screen.
* The `ICH` and `DCH` operations are constrained by the horizontal
margins, but only when inside the vertical margins. And if the cursor is
outside the horizontal margins, these operations have no effect at all.
* The rectangular area operations are clamped within the horizontal
margins when in the origin mode, the same way they're clamped within the
vertical margins.
* The scrolling operations only scroll the area inside both horizontal
and vertical margins. This includes the `IL` and `DL` operations, but
they also won't have any effect at all unless the cursor is already
inside the margin area.
* `CR` returns to the left margin rather than the start of the line,
unless the cursor is already left of that margin, or outside the
vertical margins.
* `LF`, `VT`, `FF`, and `IND` only trigger a scroll at the bottom margin
if the cursor is already inside both vertical and horizontal margins.
The same rules apply to `RI` when triggering a scroll at the top margin.
Another thing worth noting is the change to the `ANSISYSSC` operation.
Since that shares the same escape sequence as `DECSLRM`, they can't both
be active at the same time. However, the latter is only meant to be
active when `DECLRMM` is set, so by default `ANSISYSC` will still work,
but it'll no longer apply once the `DECLRMM` mode is enabled.
## Validation Steps Performed
Thanks to @al20878, these operations have been extensively tested on a
number of DEC terminals and I've manually confirmed our implementation
matches their behavior.
I've also extended some of our existing unit tests to cover at least the
basic margin handling, although not all of the edge cases.
Closes#14876
Overhangs for box glyphs can produce unsightly effects, where the
antialiased edges of horizontal and vertical lines overlap between
neighboring glyphs and produce "boldened" intersections.
This avoids the issue in most cases by simply clipping the glyph to the
size of a single cell. The downside is that it fails to work well for
custom line heights, etc.
## Validation Steps Performed
* With Cascadia Code, printing ``"`u{2593}`n`u{2593}"`` in pwsh
doesn't produce a brightened overlap anymore ✅
* ``"`e#3`u{2502}`n`e#4`u{2502}"`` produces a fat vertical line ✅
_targets #15280_
When ctrl+clicking on a profile, pre-evaluate the starting directory of
that profile, and stash that in the commandline we pass to elevate shim.
So in the case of something like "use parent process directory", we'll
run `elevate-shim new-tab -p {guid} -d "C:\\the path\\of\\terminal\\."`
Closes#15173
---------
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
`TermControl` cannot change the text rendering engine after its
construction. Fix the issue by deferring the construction until
after we got the initial profile settings.
## Validation Steps Performed
* A line height of 0.5 shows up with overlapping rows ✅
We need to avoid calling `Present1()` with an empty dirty rect, but the
backends are what determines the resulting dirty rect, so we need to
first run the backend code and then decide if we `Present1()` or not.
## Validation Steps Performed
* `Animate_scan.hlsl` shows a smoothly animated line ✅
This commit ensures that we pass the user's locale to `MapCharacters`.
## Validation Steps Performed
See: https://heistak.github.io/your-code-displays-japanese-wrong/
After modifying the `userLocaleName` to contain `ja-JP`, `zh-CN` and
`zh-TW`, printing "刃直海角骨入" produces the expected, localized result.
This commit fixes 3 bugs that I found while working on another feature:
* `GetGlyphIndices` doesn't return an error when the codepoint couldn't
be found, it simply returns a glyph index of 0.
* `_resetGlyphAtlas` failed to reset the `linear_flat_set` "load" to 0
which would result in an unbounded memory growth over time.
* `linear_flat_set` was missing move constructors/operators, which
would've led to crashes, etc., but thankfully we haven't made use
of these operators yet. But better fix it now than never.
XAML/WinUI may pump the event loop internally. One of the functions
that does this right now is `DesktopWindowXamlSource::Close()`.
This is problematic in the previous code, because we'd set `_window`
to `nullptr` before calling `Close()` and so any of the `IslandWindow`
callbacks may be invoked during shutdown, which then try to potentially
access `_window` and end up crashing. This commit fixes the issue by
simply not nulling out the `_window` and calling `Close()` directly.
Furthermore, `NonClientIslandWindow` may directly access WinUI
objects in its message handlers which also crashes.
I've had this happen roughly ~1% of my test exits in a debug build
and every single time on a (artificial) very slow CPU.
## Validation Steps Performed
* Closing a window destroys the rendering instance ✅
This PR adds support for the ANSI Line Feed/New Line mode (`LNM`), which
determines whether outputting a linefeed control should also trigger a
carriage return, and whether the `Return` key should generate an `LF` in
addition to `CR`.
## Detailed Description of the Pull Request / Additional comments
In ConHost, there was already a console mode which handled the output
side of things, but I've now also added a `TerminalInput` mode that
controls the behavior of the `Return` key. When `LNM` is set, both the
output and input modes are enabled, and when reset, they're disabled.
If they're not already matching, then `LNM` has no effect, and will be
reported as unknown when queried. This is the typical state for legacy
console applications, which expect a linefeed to trigger a carriage
return, but wouldn't want the `Return` key generating both `CR`+`LF`.
As part of this PR, I've also refactored the `ITerminalApi` interface to
consolidate what I'm now calling the "system" modes: bracketed paste,
auto wrap, and the new line feed mode. This closes another gap between
Terminal and ConHost, so both auto wrap, and line feed mode will now be
supported for conpty pass through.
## Validation Steps Performed
I've added an `LNM` test that checks the escape sequence is triggering
both of the expected mode changes, and added an additional `DECRQM` test
covering the currently implemented standard modes: the new `LNM`, and
the existing `IRM` (which wasn't previously tested). I've also extended
the `DECRQM` private mode test to cover `DECAWM` and Bracketed Paste
(which we also weren't previously testing).
I've manually tested `LNM` in Vttest to confirm the keyboard is working
as expected.
Closes#15167
`WindowEmperor` would exit as soon as the last window would enter
`RundownForExit()`, which is too early and triggers leak checks.
This commit splits up the shutdown up into deregistering the window from
the list of windows and into actually decrementing the window count.
Closes#15306
## Validation Steps Performed
* D2D leak warnings seem to disappear ✅
We don't need to recreate the `MediaPlayer` to avoid the influence of
media keys if we simply opt out of media key controls.
## Validation Steps Performed
* Set a random .wav as the bell sound
* Bell is audible ✅
* Media keys have no effect while the sound plays ✅
`ControlCore` contained two bugs:
* Race condition on access of the 3 throttled funcs which may now
be `reset()` during tear out
* The `ScrollPositionChanged` event emitter was written incorrectly
and would emit the event from the background thread without
throttling during tear out
I found that in all our Helix runs, we had a pesky dialog sitting on top
of the Terminal. Probably the entire time.
This will, as a side effect, PGO the nearby font loader.
Before process model v3, each Terminal window was running in its own process, each with its own CWD. This allowed `startingDirectory: .` to work relative to the terminal's own CWD. However, now all windows share the same process, so there can only be one CWD. That's not great - folks who right-click "open in terminal", then "Use parent process directory" are only ever going to be able to use the CWD of the _first_ terminal opened.
This PR remedies this issue, with a theory we had for another issue. Essentially, we'll give each Terminal window a "virtual" CWD. The Terminal isn't actually in that CWD, the terminal is in `system32`. This also will prevent the Terminal from locking the directory it was originally opened in.
* Closes#5506
* There wasn't a 1.18 issue for "Use parent process directory is broken" yet, presumably selfhosters aren't using that feature
* Related to #14957
Many more notes on this topic in https://github.com/microsoft/terminal/issues/4637#issuecomment-1531979200
> **Warning**
> ## Breaking change‼️
This will break a profile like
```json
{
"commandline": "media-test.exe",
"name": "Use CWD for media-test",
"startingDirectory": "."
},
```
if the user right-clicks "open in terminal", then attempts to open that profile. There's some theoretical work we could do in a follow up to fix this, but I'm inclined to say that relative paths for `commandline`s were already dangerous and should have been avoided.
After retrieving the items via `GetStorageItemsAsync()` inside a try
clause it fails to check if the pointer is actually non-null.
Apart from this this commit fixes the unsafe use of `this` by properly
using `get_weak()`. Finally it allows >1 paths to be dropped.
## Validation Steps Performed
* Dropping >1 file works ✅
* Dropping >1 directory works ✅
Tl;dr: Conpty would flush a frame whenever it encountered a FTCS mark.
Combine that with the whole-line redrawing that nushell does, and the
Terminal would get the prompt in two frames instead of one, causing a
slight flickering. This fixes that by rendering the frame, but not
flushing to the pipe when we encounter one of these sequences.
Closes#13710
A complication here: there are some sequences that we passthrough
_immediately_ when we encounter them. For example, `\x1b[ 2q`. we need
to also not flush when we encounter one of these sequences. nushell
emits one of these as a part of the prompt, and that would force the
buffered frame to get written _anyways_, before writing that to the
pipe.
Adds support for CSI 18t to report the buffer screen size in characters.
This pull request adds support for **CSI 18t**. When submitted to the
terminal, it will respond with **"\033[8;{A};{B}t"** where **A** is
equal to the **height** and **B** is equal to the **width** of the
screen buffer in the number of characters (not pixels).
## Validation Steps Performed
Manual tests against PowerShell 7 and ConHost.
Added adapterTest
Closes#13944
Adds
```
{ "command": "showContextMenu", "keys": "menu" },
```
as a default action. This will manually invoke the control context menu
(from #14775), even with the setting disabled.
As discussed with Dustin.
We need to act like a ConPTY just a little earlier in startup. My relevant notes start here: https://github.com/microsoft/terminal/issues/15245#issuecomment-1536150388.
Basically, we'd create the first screen buffer with 9001 rows, because it would be created _before_ VtIo would be in a state to say "yes, we're a conpty". Then, if a CLI app emits an entire screenful of text _before_ the terminal has a chance to resize the conpty, then the conpty will explode during `_DoLineFeed`. That method is absolutely not expecting the buffer to get resized (and the old text buffer deallocated).
Instead, this will treat the console as in ConPty mode as soon as `VtIo::Initialize` is called (this is during `ConsoleCreateIoThread`, which is right at the end of `ConsoleEstablishHandoff`, which is before the API server starts to process the client connect message). THEORETICALLY, `VtIo` could `Initialize` then fail to create objects in `CreateIoHandlers` (which is what we used to treat as the moment that we were in conpty mode). However, if we do fail out of `CreateIoHandlers`, then the console itself will fail to start up, and just die. So I don't think that's needed.
This fixes#15245. I think this is PROBABLY also the solution to #14512, but I'm not gonna explicitly mark closed. We'll loop back on it.
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 commit makes a few changes to avoid bugs, but they basically boil
down to: When we scroll by an entire viewport worth of content, we must
ensure that the scroll offset is 0, because otherwise the scroll rect
(that's basically the viewport, but excluding the scroll offset) will
end up being empty, which the `Present1` API chokes on. This commit
avoids this situation by shuffling around some code to first calculate
the dirty rows, _then_ check if it affects all of them and in that case
sets the scroll offset to 0, and only then finally actually does any
scrolling if there's still something to scroll.
## Validation Steps Performed
* Start pwsh
* Zoom in twice with Ctrl+Scrollwheel
* Print a few viewports worth of text
* Press Ctrl+L
* No errors ✅
Get the locale from `GetUserDefaultLocaleName` and pass it to
DirectWrite's `GetGlyphs` / `GetGlyphPlacements`.
This change is very important for some fonts, which heavily depend on
the locl table, like Source Han Sans for instance.
Closes#13685
## Validation Steps Performed
* Set font to Cascadia Code
* Set locale to "pl-PL"
* Type "Ć"
* The acute is less angled and almost vertical ✅
## Summary of the Pull Request
This was a fever dream I had last July. What if, instead of `WINRT_PROPERTY` magic macros everywhere, we had actual templated versions you could debug into.
So instead of
```c++
WINRT_PROPERTY(bool, Deleted, false);
WINRT_PROPERTY(OriginTag, Origin, OriginTag::None);
WINRT_PROPERTY(guid, Updates);
```
you'd do
```c++
til::property<bool> Deleted{ false };
til::property<OriginTag> Origin{ OriginTag::None };
til::property<guid> Updates;
```
.... and then I just kinda kept doing that. So I did that for `til::event`.
**AND THEN LAST WEEK**
Raymond Chen was like: ["this is a good idea"](https://devblogs.microsoft.com/oldnewthing/20230317-00/?p=107946)
So here it is.
## Validation Steps Performed
Added some simple tests.
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
`IDWriteFontSetBuilder` is super expensive (~40ms of CPU for building a
single font set on a high-end CPU from ~2021). Let's avoid the cost,
by only constructing it if Cascadia Code is actually missing.
To not overcomplicate the code and to support any additional fonts we
might ship in the future, I'm not checking for the font name, and
instead I just construct the font set whenever any font is missing.
Part of #5907
## Validation Steps Performed
* Breakpoints in FontCache aren't hit ✅
* App doesn't crash ✅
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.
## Summary of the Pull Request
When the screen is resized in ConHost via a VT escape sequence, the
active text attributes could end up being corrupted if they were set to
something that the legacy console APIs didn't support (e.g. RGB colors).
This PR fixes that issue.
## Detailed Description of the Pull Request / Additional comments
The way a resize is implemented is by retrieving the buffer information
with `GetConsoleScreenBufferInfoEx`, updating the size fields, and then
writing the data back out again with `SetConsoleScreenBufferInfoEx`.
However, this also results in the active attributes being updated via
the `wAttributes` field, and that's only capable of representing legacy
console attributes.
We address this by saving the full `TextAttribute` value before it gets
corrupted in the `SetConsoleScreenBufferInfoEx` call, and then restore
it again afterwards.
## Validation Steps Performed
I've added a unit test to verify the attributes are correctly preserved
for all VT resize operations, and I've also manually confirmed the test
case in #2540 is now working as expected.
## PR Checklist
- [x] Closes#2540
- [x] Tests added/passed
- [ ] Documentation updated
- [ ] Schema updated (if necessary)
Basically, just make sure that we register our `SettingsChanged` handler
in `TerminalWindow` _after_ `TerminalWindow` is actually ready to handle
it. _duh_.
Closes#15209
If you were really fast, and closed one window, and then tried to drag
the only tab out of the last remaining window, the Terminal could
explode. It'd attempt to restore the previous window state, and explode.
Easy way to stop this (also, be more robust): just don't attempt to
restore windows during tear-out. That's obvious.
This is a part of #14957
A resurrection of the original nested "Close" menu from #7728. We
discovered that nested flyouts crash in #8238. Those are fixed now
though! So we can bring this back.
This also includes the "Close Pane" item from #15198.
Adds an action for immediately restarting the connection. I suspect
most folks that wanted #3726 will be happy just with the
<kbd>enter</kbd> solution from #14060, but this will work without having
to `exit` the client. Just, relaunch whatever the commandline is. Easy
peasy.
Closes#3726.
Obsoletes #14549
A different take on #14548.
> We didn't love that a connection could transition back in the state
diagram, from Closed -> Start. That felt wrong. To remedy this, we're
going to allow the ControlCore to...
ASK the app to restart its connection. This is a much more sensible
approach, than leaving the ConnectionInfo in the core and having the
core do the restart itself. That's mental.
Cleanup from #14060Closes#14327
Obsoletes #14548
This PR gives the atlas engine an attempt to retry a couple operations
where it asks for debug flags when we're in debug mode. If you don't
have the Graphics debugger and GPU profiler for DirectX installed, then
these calls will fail, and we end up blowing up the renderer. Instead,
just try again.
Originally, I actually thought I had hit #14082, but after sorting this
out, it was just #14316.
closes#14316
Adds support to jump list generation for icon paths that include an
indirect reference e.g. `c:\windows\system32\shell32.dll,214`
If given a path that has an indirect icon reference parse the path into
component parts `filePath` and `iconIndex` and use
`IShellLinkW::SetIconLocation` to set the Icon for the entry. Otherwise
do what we always do.
This PR also introduces `til::to_int`, which is based on `til::to_ulong`
and supports signed integers.
## Validation Steps Performed
Icons were visible in the jump list and in terminal next to the
profiles.
Closes#15205
## Summary of the Pull Request
Adding a 'Close Pane' menu item in the context menu.
## References and Relevant Issues
#13580
## Detailed Description of the Pull Request / Additional comments
If a user decides to split a tab to create multiple panes through the
context menu, they should be able to then close the pane via the context
menu too. This PR introduces a new context menu item, 'Close Pane', that
only appears when a user has 2 or more panes in a tab. When a user
clicks close pane, the _active_pane will be closed.
## Validation Steps Performed
As it's my first PR, I still need to understand how to go through the
testing suite.
## PR Checklist
- [x] Closes#13580
- [ ] 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)
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
This is an update of our Primary Device Attributes report, which better
indicates the feature extensions that we now support.
## Detailed Description of the Pull Request / Additional comments
This first parameter of the response is 61, representing a conformance
level of 1. The subsequent parameters identify the supported feature
extensions.
1 = 132 column mode
6 = Selective erase
7 = Soft fonts
22 = Color text
23 = Greek character sets
24 = Turkish character sets
28 = Rectangular area operations
32 = Text macros
42 = ISO Latin-2 character set
Most of these features are handled entirely within `AdaptDispatch`, so
they apply to all clients. However, 132 column mode is only supported by
ConHost, so we don't report that for conpty clients.
And note that soft fonts won't necessarily work in all conpty clients,
but we don't have an easy way of determining that, so we just report
soft font support for everyone.
## Validation Steps Performed
I've manually verified that the `DA1` report is returning the expected
response in Vttest, both from ConHost and Windows Terminal.
I've also updated the `DeviceAttributesTests` in the adapter tests to
account for the new expected response.
Closes#14491
This adds support for XTerm's "bracketed paste" mode in ConHost. When
enabled, any pasted text is bracketed with a pair of escape sequences,
which lets the receiving application know that the content was pasted
rather than typed.
## References and Relevant Issues
Bracketed paste mode was added to Windows Terminal in PR #9034.
Adding it to ConHost ticks one more item off the list in #13408.
## Detailed Description of the Pull Request / Additional comments
This only applies when VT input mode is enabled, since that is the way
Windows Terminal currently works.
When it comes to filtering, though, the only change I've made is to
filter out the escape character, and only when bracketed mode is
enabled. That's necessary to prevent any attempts to bypass the
bracketing, but I didn't want to mess with the expected behavior for
legacy apps if bracketed mode is disabled.
## Validation Steps Performed
Manually tested in bash with `bind 'set enable-bracketed-paste on'` and
confirmed that pasted content is now buffered, instead of being executed
immediately.
Also tested in VIM, and confirmed that you can now paste preformatted
code without the autoindent breaking the formatting.
Closes#395
This is practically a from scratch rewrite of AtlasEngine.
The initial approach used a very classic monospace text renderer, where
the viewport is subdivided into cells and each cell is assigned one
glyph texture, just like how real terminals used to work.
While we knew that it would have problems with overly large glyphs,
like those found in less often used languages, we didn't expect the
absolutely massive number of fonts that this approach would break.
For one, the assumption that monospace fonts are actually mostly
monospace has turned out to be a complete lie and we can't force users
to use better designed fonts. But more importantly, we can't just
design an entire Unicode fallback font collection from scratch where
every major glyph is monospace either. This is especially problematic
for vertical overhangs which are extremely difficult to handle in a
way that outperforms the much simpler alternative approach:
Just implementing a bog-standard, modern, quad-based text renderer.
Such an approach is both, less code and runs faster due to a less
complex CPU-side. The text shaping engine (in our case DirectWrite)
has to resolve text into glyph indices anyways, so using them directly
for text rendering allows reduces the effort of turning it back into
text ranges and hashing those. It's memory overhead is also reduced,
because we can now break up long ligatures into their individual glyphs.
Especially on AMD APUs I found this approach to run much faster.
A list of issues I think are either obsolete (and could be closed)
or resolved with this PR in combination with #14255:
Closes#6864Closes#6974Closes#8993Closes#9940Closes#10128Closes#12537Closes#13064Closes#13527Closes#13662Closes#13700Closes#13989Closes#14022Closes#14057Closes#14094Closes#14098Closes#14117Closes#14533Closes#14877
## PR Checklist
* Enabling software rendering enables D2D mode ✅
* Both D2D and D3D:
* Background appears correctly ✅✅
* Text appears correctly
* Cascadia Code Regular ✅✅
* Cascadia Code Bold ✅✅
* Cascadia Code Italic ✅✅
* Cascadia Code block chars leave (almost) no gaps ✅✅
* Terminus TTF at 13.5pt leaves no gaps between block chars ✅✅
* ``"`u{e0b2}`u{e0b0}"`` in Fira Code Nerd Font forms a square ✅✅
* Cursor appears correctly
* Legacy small/medium/large ✅✅
* Vertical bar ✅✅
* Underscore ✅✅
* Empty box ✅✅
* Full box ✅✅
* Double underscore ✅✅
* Changing the cursor color works ✅✅
* Selection appears correctly ✅✅
* Scrolling in various manners always renders correctly ✅✅
* Changing the text antialising mode works ✅✅
* Semi-transparent backgrounds work ✅✅
* Scroll-zooming the font size works ✅✅
* Double-size characters work ✅✅
* Resizing while text is printing works ✅✅
* DWM `+Heatmap_ShowDirtyRegions` shows that only the cursor
region is dirty when it's blinking ✅✅
* D2D
* Margins are filled with background color ❌
They're filled with the neighboring's cell background color for
convenience, as D2D doesn't support `D3D11_TEXTURE_ADDRESS_BORDER`
* D3D
* Margins are filled with background color ✅
* Soft fonts work ✅
* Custom shaders enable continous redraw if time constant is used ✅
* Retro shader appears correctly ✅
* Resizing while a custom shader is running works ✅
The AppInitialized latency metric logs how long the application needs
to initialize the UI. 5b434dc broke this metric, because it was now
executing the code outside of the `Initialized` callback.
It's the difference between a "latency" of ~50ms and ~350ms.
As an added bonus it moves the `_ApplyStartupTaskStateChange` task
into the `Initialized` callback as well, because why not.
## Validation Steps Performed
* Breakpoint into "AppInitialized" - latency is now correct ✅
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
## Summary of the Pull Request
There are certain escape sequences that use the `VTParameters::subspan`
method to access a subsection of the provided parameter list. When the
parameter list is empty, that `subspan` call can end up using an offset
that is out of range, which causes the terminal to crash. This PR stops
that from happening by clamping the offset so it's in range.
## References and Relevant Issues
This bug effected the `DECCARA` and `DECRARA` operations introduced in
PR #14285, and the `DECPS` operation introduced in PR #13208.
## Validation Steps Performed
I've manually confirmed that the sequences mentioned above are no longer
crashing when executed with an empty parameter list, and I've added a
little unit test that checks `VTParameters::subspan` method is returning
the expected results when passed an offset that is out of range.
## PR Checklist
- [x] Closes#15234
- [x] Tests added/passed
- [ ] Documentation updated
- [ ] Schema updated (if necessary)
We had a report in a mail thread that someone's Terminal windows were
getting created hidden, and never showing themselves.
As a theory, I'm guessing that dwFlags didn't say that we should
actually use `wShowWindow`. So, to be more correct, let's actually obey
that.
I'm gonna send this package to them to see if it fixes them.
Related to #14957.
Likely regressed in #13838.
This bug causes AtlasEngine to render buffer contents with an incorrect
`cellCount`, which may either cause it to draw the contents only
partially, or potentially access the TextBuffer contents out of bounds.
`EnablePainting` sets the `_viewport` to the current viewport for some
unfortunate (and quite buggy/incorrect) caching purposes, which causes
`_CheckViewportAndScroll()` to think that the viewport hasn't changed
in the new window. We can ensure `_CheckViewportAndScroll()` works
by also setting `_forceUpdateViewport` to `true`.
Part of #14957
## PR Checklist
* Tear out a tab from a smaller window to a larger window
* Renderer contents adept to the larger window size ✅
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
It seemed dangerous to just have places all over Pane where we
manipulate the whole cadre of TermControl events. Seemed ripe for a
copypasta error. This moves that around, so there's only two methods for
messing with the TermControl callbacks: `_setupControlEvents` and
`_removeControlEvents`.
Closes: nothing. This was an off-the-cuff commit that seemed valuable.
Original bug report #15049
Relates to feature #1571
MenuFlyoutSubItem, when collapsing from profile selection, move focus
back to the titlebar.
An extra Closing event handler is needed to keep focus on the command
shell.
Closes#15049
The ability to build and run Terminal as a UWP application was removed
in #12119. We left some of its vestiges around, but now there is no need
for them.
See
https://github.com/microsoft/terminal/issues/14957#issuecomment-1520522722.
I think there's a race here that lets the WindowEmperor muck around with
the window after it's done, but before we remove it from our list of
threads.
This _should_ remove the thread from the list, _then_ null out the
AppHost, then flush the XAML queue, preventing the A/V.
Closes MSFT:43995981
Adds a "Select command" and a "Select output" entry to the right-click
context menu when the user has shell integration enabled. This lets the
user quickly right-click on a command and select the entire commandline
or all of its output.
This was a "I'm waiting for reviews" sorta idea. Seemed like a
reasonable combination of features. Related to #13445, #11000.
Tested manually.
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
`WINRT_LEAN_AND_MEAN` removes a bunch of less often used parts of the
C++/WinRT headers:
- `std::hash` specializations for every object
- `operator <<(ostream)` overloads for any `IStringable`
- Interface producers for interfaces that are marked "exclusive"
There's only one place where we were using even one of these.
Enabling this saves us (optimistically) 30 seconds of build time on the
CI agents and shrinks our largest PCH (TerminalApp, x64, Debug) by about
150MiB.
It's not huge, but it's not nothing.
Just changing the Theme also doesn't seem to work by itself - there
seems to be a way for the tab to set the deselected foreground onto
itself as it becomes selected. If the mouse isn't over the tab, that can
result in mismatched fg/bg's
Regressed around #15078Closes#15184
Default to XamlRoot when unable to find a focused object in
DirectKeyEvents
This may not be the most appropriate "fix" for this. Certainly open to
criticism and feedback. We are trapping the alt+space key chord on the
win32 side and forwarding it to the xaml side. There we try to find a
focused object by walking the xaml tree. If we are unable to find a
focused object we return false and do nothing. I suspect that the area
that has focus that prevents this from working normally is on the win32
side. Since we want to handle the system menu anyway and are explicitly
trapping that key combo and forwarding it on I thought this was the best
approach. If we cant find a focused object default to the xaml root.
## Validation Steps Performed
System menu opens as it should.
Closes#14397
Set the padding to the default TabViewHeaderPadding (8,0,0,0), but with
-1 on the bottom. This prevents a small 1px gap that can appear on 150%
scale displays between the tab item and the content. The 1 on top helps
keep
the tab the correct relative height within the tab row.
Regressed in #15078
See also MSFT:40692364
Add automation heading level 1 to fix the about dialog by adding an
automation property.
Allows screen reader to pick up that this is a heading and read
properly.
Closes#11912
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
This PR adds a convenience feature to New-UnpackagedTerminalDistribution
that produces an unpackaged layout from an already-unpacked AppX, like
the one Visual Studio registers.
```powershell
New-UnpackagedTerminalDistribution `
-TerminalLayout path\to\bin\x64\Debug\AppX `
-XamlAppX path\to\xaml\2.8.appx
```
The output item when you build an unpackaged layout is the temp folder
in which the distribution was built. It will not make a zip file for
you.
## Summary of the Pull Request
Add an infobar warning when a non-monospaced font is selected.
## References and Relevant Issues
#13389
## Detailed Description of the Pull Request / Additional comments
I initially had the `IsOpen` property of the infobar bound to the
`ShowAllFonts` checkbox property. However, I felt we could do better by
adding a property for it since there was already a method defined to
inspect whether the selected font was in the `MonoSpaceFontList`.
## Validation Steps Performed
Warning shows up when a non-monospaced font is selected either globally
or on individual profiles. All existing tests continue to pass.
<img width="868" alt="image"
src="https://user-images.githubusercontent.com/2086722/232594214-cd42397b-ce9d-499c-aa73-3feaa45e850e.png">
## PR Checklist
- [x] Closes#13389
- [x] Tests added/passed
- [ ] Documentation updated
- If checked, please file a pull request on [our docs
repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
- [ ] Schema updated (if necessary)
Adds two new commands, `selectOutput` and `selectCommand`. These don't
do much without shell integration enabled, unfortunately. If you do
enable it, however, you can use these commands to quickly navigate the
history to select whole commands (or their output).
Some sample JSON:
```json
{ "keys": "ctrl+shift+<", "command": { "action": "selectCommand", "direction": "prev" } },
{ "keys": "ctrl+shift+>", "command": { "action": "selectCommand", "direction": "next" } },
{ "keys": "ctrl+shift+[", "command": { "action": "selectOutput", "direction": "prev" } },
{ "keys": "ctrl+shift+]", "command": { "action": "selectOutput", "direction": "next" } },
```
**Demo gifs** in
https://github.com/microsoft/terminal/issues/4588#issuecomment-1352042789closes#4588
Tested manually.
<details>
<summary>CMD.exe user? It's dangerous to go alone! Take this.</summary>
Surely, there's a simpler way to do it, this is adapted from my own
script.
```cmd
prompt $e]133;D$e\$e]133;A$e\$e\$e]9;9;$P$e\$e[30;107m[$T]$e[97;46m$g$P$e[36;49m$g$e[0m$e[K$_$e[0m$e[94m%username%$e[0m@$e[32m%computername%$e[0m$G$e]133;B$e\
```
</details>
This fixes 3 sources for animations:
* `TabView`'s `EntranceThemeTransition` causes tabs to slowly slide in
from the bottom. Removing the transition requires you to override the
entire list of transitions obviously, which is a global change. Nice.
Am I glad I don't need to deal with the complexity of CSS. /s
* `TabBase`, `SettingsTab` and `TerminalTab` were using a lot of
coroutines with `resume_foreground` even though almost none of the
functions are called from background tabs in the first place. This
caused us to miss the initial XAML drawing pass, which resulted in
animations when the tab icons would asynchronously pop into existence.
It also appears as if `resume_foreground`, etc. have a very high CPU
cost attached, which surprises me absolutely not at all given WinRT.
The improvement is difficult to quantify because the run to run
variation is very high. But it seems like this shaves about 10% off
of the ~500ms startup delay on my PC depending on how you measure it.
Part of #5907
## PR Checklist
* It starts when it should ✅
* It doesn't "exit" when it shouldn't ✅
(Scrolling, Settings reload, Bell `\a`, Progress `\e]9;4;2;80\e\\`)
This sets `x:Load` to `false` for the two elements.
On my system, with Windows Defender disabled, this reduces CPU
usage by 15ms and the visual delay during launch by 40ms.
Part of #5907
## Validation Steps Performed
* Ctrl+Shift+P opens command palette ✅
* Context menu opens command palette ✅
* Context menu opens about dialog ✅
`WM_ACTIVATE` is sent on window creation, whereas `WM_SHOWWINDOW` is
sent when the window is shown. Before we call `Peasant::ActivateWindow`
in the `WM_ACTIVATE` handler, we try to get the virtual desktop GUID of
our window, but since it's not shown yet during startup, there's also
no GUID that can be retrieved. This results in an error log message and
an all 0 GUID to be sent via `Peasant::ActivateWindow`.
The GUID of the window that actually spawned on the other hand is never
reported until the first time you reactivate it again, leading to a
number of subtle bugs around window activity.
Additionally, this commit fixes a race condition and pointer unsafety,
by pulling all relevant member variables onto the coroutine's stack,
before it yields itself to a background thread.
## Validation Steps Performed
- Set a trace breakpoint on `_peasantNotifyActivateWindow`
- GUID is non-zero ✅
## Summary of the Pull Request
Add subtext that lets the user know why Always show tabs is not
toggleable in SUI. Also adds some additional information to the comment
for this value that points to the Globals_ShowTitlebar.Header setting.
## References and Relevant Issues
#13984
## Detailed Description of the Pull Request / Additional comments
Simple updates to the resources that add some additional helpful
information for the user.
## Validation Steps Performed
Verified the updates show in the SUI and that they render correctly.
## PR Checklist
- [ ] Closes#13984
- [ ] 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)
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
Original description, pre-process model v3:
> This is just the `SHOWDEFAULT` bit from #12979. This seems to also
work now, but I'm PR'ing it separately so it can be a separate revert
from #13811, if it is problematic.
More accurately:
This PR enables terminal windows to use the `wShowCmd` from the
STARTUPINFO passed to `windowsterminal.exe` to set the initial
visibility of the window. We can't just use `SW_SHOWDEFAULT`, because
all the windows are running in the initial process! After the first
window, the subsequent ones would ignore any params passed to their
originating `windowsterminal.exe` processes. To mitigate, we pass that
`wShowCmd` info from the source process, to the actual running terminal
process. That accounts for most of the delta here.
Closes#9053
This doesn't do the same for defterm-initiated connections. This is
because we don't need to! Defterm very explicitly rejects handoff for
minimized console apps. This is probably for the best! I put an attempt
in 66f8b25ec before I forgot that it was filtered long before the
Terminal. NOT doing this for /min saves us all sorts of "what happens if
`start /min cmd` tries to glom?" or "what if someone does `start /min
cmd && start /max cmd` and they glom together?".
<hr>
Also closes#15193, which was introduced as a part of this.
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
* make the list of MenuItems observable, so the nav view can actually
listen for changes to it
* Use the MenuItemsSource to find the index to add at, rather than the
MenuItems (which isn't accurate anymore)
* Stash a single observable vector as the menuitemsource, and modify
that whenever we need to do modifications.
* I attempted to create a new vector, then copy into the new one, then
replace the MenuItemsSource with the new vector, but that _refused_ to
work. So let's just... not.
Regressed in #14630Closes#15140
Manually validated that this and #13673 are still fixed
This pull request adds the requirement for the shift key to be pressed
in addition to the control key.
References #14810
Implemented in #14873
This is follow up work from my last pull request that was merged that
only required the control key to be pressed to launch the terminal as
admin from the shell context menu. After some discussion it was decided
that the shift key should be required as well as that is the norm on
Windows.
## Validation Steps Performed
Tested all combinations of shift+ctrl and verified that the terminal
only requests elevation when a shift and control key are pressed
together. The shell launches regularly if not.
This fixes the BreadcrumbBar issue that would crash into the debugger
anytime you open the SUI on a second thread.
See #14957.
Maybe also tracked in #15144 - let's have @j4james test when this
merges.
TL;DR: we stopped getting `TabView.TabItemsChanged`. This meant that the
tab view would change its apparent order, but we wouldn't change the
backing tab order.
I'm fixing this by grabbing the index of the tab that starts the drag,
and the index of the tab view item at the end of the drag, and using
that to reorder our backing list.
Closes#15121
Upstream https://github.com/microsoft/microsoft-ui-xaml/issues/8388
Regressed in #15078 - I'm pretty confident about this, since I've got a
1.18.931 build of the Terminal with tear-out, but not MUX 2.8.
The code changes are mostly self-explanatory: Just skip glyphs
that can never be inserted. I implemented it slightly incorrectly
(a newline will be inserted every time you write such a wide glyph),
but it's a niche issue and I think the simplicity of the fix is
more important than its exact correctness.
It also contains a fix for some severe log spam due to
`_PrepareForDoubleByteSequence` complaining in this situation.
The spam is so bad that it freezes the app for a few seconds
during text buffer reflow.
Closes#7416
## Validation Steps Performed
* Open an extra pane and run `TerminalStress.exe` in there
* Resize to 1 column
* Doesn't hang ✅
Hides the cursor when null, shows it when not.
Clear the screen any time the connection is changed.
This prevents the WPF Control from crashing when set back to null, clears
the console and hides the mouse as well.
It sends 3 VT sequences as well now:
1) When the Connection is set to null the cursor is hidden (reflects
what the default state is)
2) When the Connection is set to a value and it was null before we show
the cursor (not a breaking change as requires it to have been null which
previously would cause a crash, except for for set)
3) When the Connection is changed the terminal is reset. A breaking
change officially although not sure if there are use cases where this
behavior is not desired. For added safety we could make sure we are not
being set to the same value we currently are.
None of the ansi commands are needed, users could do it all themselves
as well, the behavior largely seemed natural though. I didn't see any
ansi constants anywhere so they are just hard coded with comments, but
not sure if there is an established better practice.
Closes#15061
## Summary of the Pull Request
This pull request updates the implementation of the copy assignment
operator for Pane::LayoutSizeNode to a more efficient version and
eliminates the need for the _AssignChildNode code block.
## References and Relevant Issues
#11965#11963
## Detailed Description of the Pull Request / Additional comments
My understanding of the discussion and intent of the two linked issues
is that this is a more efficient way to implement the copy assignment
operator for Pane.LayoutSizeNode and eliminates the need for the code
block _AssignChildNode. Since both were relatively small changes, I
combined the two in one PR. If that is not desirable, I can separate
them. All existing tests continue to pass.
<img width="769" alt="image"
src="https://user-images.githubusercontent.com/2086722/231326683-8f685f58-5748-4d49-8a38-80ef5db3d5a2.png">
## Validation Steps Performed
All existing tests pass. No visible changes in behavior of the terminal.
## PR Checklist
- [x] Closes#11963
- [x] Closes#11965
- [x] Tests added/passed
- [ ] Documentation updated
- If checked, please file a pull request on [our docs
repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
- [ ] Schema updated (if necessary)
As discussed in #6507
Newer builds of Windows do this automatically. However, this was spotted
in the wild on 1.18. It's possible the threading changes created a
situation where the OS-side fix no longer applied to us. So let's just
do it manually. It doesn't have any side effects.
I saw this once on Win11, but couldn't repro it this morning when I
tried to add this fix. I'm just gonna assume this worked, despite the
fact that I can't repro it on win11 anymore.
closes#6507
See also #14957
## detailed description
> `WindowsXamlManager::XamlCore::Initialize` calls
`ConfigureCoreWindow`, which creates a `CoreWindow` on the thread
> Problem is, we're calling that on the main thread (which doesn't have
_any_ windows), and then eventually creating a `DesktopWindowXamlSource`
on a second thread for the actual window
> It's not that it "manages a window", it's that it "manages xaml on
Windows OS". just use ICoreWindowInterop -- QI for ICoreWindowInterop
and call get_WindowHandle.
Also see:
*
[ICoreWindowInterop](https://learn.microsoft.com/en-us/windows/win32/api/corewindow/nn-corewindow-icorewindowinterop)
*
[WindowsXamlManager.InitializeForCurrentThread](https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.hosting.windowsxamlmanager.initializeforcurrentthread?view=winrt-22621#windows-ui-xaml-hosting-windowsxamlmanager-initializeforcurrentthread)
* The source code in
`onecoreuap\windows\dxaml\xcp\dxaml\lib\WindowsXamlManager_Partial.*`
* os.2020!6102020 which fixed MSFT:33498969, MSFT:27807465,
MSFT:21854264
Fixes an issue when using both:
```json
"centerOnLaunch": true,
"firstWindowPreference": "persistedWindowLayout",
```
In this case, the Terminal would ignore the persisted location and still
just center on launch. This has been really annoying while testing
tear-out, as we keep re-opening all my debug windows as a stack on top
of each other.
Looking through this test, I seriously don't understand how this doesn't
work. I mean, I don't really get how it _does_ work, but at this point
in the tests, we've actually established that both `Nihilist.exe` _and_
openconsole are running. From my read, there's no reason these should be
failing at this point.
We previously added a "retry 5 times" bit to this test, in #8534. That
did work back then. So uh, just do that... again?
Moves our `GetWindowLayoutRequested` handler AFTER the xaml island is
started. The `AppHost::_GetWindowLayoutAsync` handler requires us to be
able to work on our UI thread, which requires that we have a
`Dispatcher` ready for us to move to. If we set up this callback in the
ctor, then it is possible for there to be a time slice where
* the monarch creates the peasant for us,
* we get ctor'ed (registering the callback)
* then the monarch attempts to query all _peasants_ for their layout,
coming back to ask us even before XAML has been created.
I believe this was the source of the crash that was reported in a mail
thread. It actually happened to me once while debugging another branch.
Alas, this was realy hard to hit in the first place, so I'm not
_totally_ certain this fixes it.
Related to #14957
Don't generate a profile for rancher-desktop utility WSL distro.
Adds a check for rancher-desktop as well as docker. As mentioned in the
discussion of this issue. This becomes much more difficult to maintain
once other folks inevitably start to follow this pattern. But the easy
win was up for grabs so I took it :)
Closes#12757
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>
When win32-input-mode is enabled, we generate an input sequence for both
key down and key up events. However, in the initial implementation the
key up sequence for most keypresses would be faked - they were generated
at the same time as the key down sequence, regardless of when the key
was actually released. After this PR, we'll only generate the key up
sequence once a key has actually been released.
## References and Relevant Issues
The initial implementation of win32-input-mode was in PR #6309.
The spec for win32-input-mode was in PR #5887.
## Validation Steps Performed
I've manually tested this with an app that polls `ReadConsoleInput` in a
loop and logs the results. With this PR applied, I can now see the key
up events as a key is released, rather than when it was first pressed.
When compared with conhost, though, there are some differences. When
typing a shifted key, e.g. `Shift`+`A`, WT generates key down and key up
events for both the `Shift` and the `A`, while conhost only generates
both events for the `Shift` - the `A` won't generate a key up event
unless you release the `Shift` before the `A`. That seems more like a
conhost flaw though.
Another case I tested was the Japanese Microsoft IME, which in conhost
will generate a key down event for the Japanese character being inserted
followed by a key up event for for `Return`. WT generates key up events
for the ASCII characters being typed in the IME, then both a key down
and key up event for the inserted Japanese character, and finally a key
up event for `Return`. Both of those seem weird, but they still appear
to work OK.
The current version of WT actually produces the most sensible behavior
for the IME - it just generates key up and key down events for the
inserted character. But that's only because it's dropping most of the
system generated key up events.
Closes#8440
I have observed the test comment coming back from Helix with `"`
and friends in it.
It ends badly as you might imagine.
This unescape will be a no-op if the data is already well-formed.
This PR adds support to the About Dialog for checking the store to see
if there's a new version of the Terminal package available. We'll only
do this once per day, per terminal window.
In dev mode, we'll always fake it and say there's an update to `x.y.z`
available.
This also involved pulling all of the About dialog code out into its own
class. All that is goodness.
We don't currently provide a button for _installing_ the update. We just
check. Incremental progress is better than none.
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Some of our automated tooling detects this as being a private API that
we're accessing via LoadLibrary/GetProcAddress. It's not *wrong*, but
it's also not *right*.
It's easier for us to just not do it (and save all the code for it!) in
OpenConsole.
This is a revert of the revert of #12979. We mainly reverted that PR
because of an issue where restored windows would grow/shrink slightly on
external displays. It was too close to the ship date for that release,
so we backed it out wholesale (in #13098). I think I've found the real
root of the problem, and fixed it here.
The money diff here from the original PR:
4c08b9a1bc2e90b8284e4d8117d0de400784520f...c34495dcfc19ea67a9f4f9673d422760200683ab.
Basically, I had put the part where we actually handle the creation of
the window into `_AppInitializedHandler`, when we should have left the
window to be created in `_HandleCreateWindow` We create it there,
_hidden_, and then should only _show_ it in `_AppInitializedHandler`.
I'm _NOT_ incorporating the change for #9053. I reverted that bit in
1fac40355. I am too worried about that messing with the phwnd that I
wanted to get that reviewed and committed atomically, separately.
* fixes #11561
* tested manually
* I work here
This adds a setting (`compatibility.allowHeadless`) to let the Terminal
keep running even when all windows are closed. This lets hotkeys keep
working, because the Emperor thread is still running, just, without any
windows.
I'm really tempted to invoke the magic "closes" word on #9996, but
honestly, we should also add some sort of support for `wt --headless` or
`wt --hidden` or whatever, before we close that. There's also #13630
which seems imminently doable.
Tested manually. I'd post a gif of "close all terminal windows, then
invoke the quakeMode binding and \*presto\*, but that would be an
unnecessarily big gif.
Related to #9996 but not enough to close it if you ask me
This is a minimal version of the requests for #14858. In that thread we
discussed FULL reverting the default themes to the old ones. In later
discussion, we decided _meh_, let's just ship the legacy themes too, so
it's easy to go back if you should choose. The default still remains the
sane `dark`, but the `legacy*` themes are all right there, and given the
same special treatment as the other inbox themes.
Closes#14858Closes#14844
Making Conhost pick up codepage from .lnk files.
Because of the wrong assignment order, the Conhost was not picking up
the codepage stored in .lnk shortcut files. This change fixes this issue
by changing the order of the assignment to the correct one.
This is a potential backward compatibility issue.
Since this issue has been present in the codebase for years, this change
runs a high risk of breaking backward compatibility with software that
depends on incorrect behavior.
## Validation Steps Performed
Tested fix manually (using chcp command, making sure each .lnk codepage
was picked up.) against Debug/Release x64 builds with 5 different .lnk
files:
1. Arabic codepage 1256
2. Greek 869
3. Latin2 852
4. Thai 874
5. Traditional Chinese 50229
Ran TAEF tests against Debug/Release x64/x86 with identical results as
main branch.
Tested against invalid codepage numbers by manually manipulating .lnk
file binary. In case of an invalid codepage number, Conhost defaults to
a valid default one, which I assume is expected behavior.
Closes#14942
This is a regression caused by 599b550. If I'm reading `stream.cpp`
in cf87590 right, it returns `STATUS_SUCCESS` if `ReadCharacterInput`
read at least 1 character. I think? this PR makes the code behave
exactly equivalent. The old code is a bit of an "acquired taste"
so it's a bit hard to tell.
Closes#15116
## PR Checklist
* Run `more long_text_file.txt` in cmd
* Press Spacebar
* Scrolls down ✅
* Press Q
* Exits ✅
Unpackaged installations don't have the luxury of magic package
isolation to stop them from accidentally touching each other's monarchs.
We need to enforce that ourselves by making their monarch CLSIDs unique
per install.
We'll use a v5 UUID based on the install folder to unique them.
Closes#15117
Upgrading clang-format lead to a few changes in the formatting
of code inside macros. Apart from the upgrade, I've also spent
some time removing all options from .clang-format that are
redundant with `BasedOnStyle: Microsoft`.
This will allow us to share the same fundamental text insertion
logic for both `ResizeTraditional` and `Reflow`, because both
can be implemented with `ROW::CopyRangeFrom`. It also replaces
the `BufferAllocator` struct with a `_allocateBuffer` function
which will help us allocate scratch buffer rows in the future.
Closes#14696
## PR Checklist
* Disable reflow resize in conhost
* Print "zhwik8.txt" - a enwik8.txt equivalent of Chinese Wikipedia
* Run `color 80` in cmd
* Resize windows from 120 to 119 columns
* Wide glyphs disappear and are replaced with whitespace ✅
* Resizing the window to >120 columns adds gray whitespace ✅
On a real VT terminal, most of the control characters that don't do
anything are supposed to be filtered out, and not written to the buffer.
Up to to now, though, we've only been filtering out `NUL`. This PR
extends our control processing to filter the remaining characters that
aren't supposed to be displayed.
We introduced filtering for the `NUL` control in PR #3015.
The are two special cases worth mentioning.
1. The `SUB` control's main purpose is to the cancel a control sequence
that is in progress, but it also needs to output an error character (a
reverse question mark) to the display.
2. The `DEL` control is typically filtered out, but when a 96-character
set is designated, it can sometimes be mapped to a printable glyph that
needs to be displayed.
## Validation Steps Performed
I've manually tested that all the controls that are meant to be filtered
out are no longer being displayed.
I've also extended the existing `NUL` unit test to cover the full set of
controls characters that are supposed to be filtered.
Closes#10786
`til::linear_flat_set` is a primitive hash map with linear probing.
The implementation is slightly complicated due to the use of templates.
I've strongly considered just writing multiple copies of this class,
by hand since the code is indeed fairly trivial but ended up deciding
against it, because this templated approach makes testing easier.
This class is in the order of 10x faster than `std::unordered_map`.
I noticed this bug while resizing my window on my 150% scale display.
Every 3 "snaps" of the window size, it would fail to resize the text
buffer. I found that this occurs, because we convert the swap chain
size from a float into a double, which converts my 597.333313 height
into 597.33331298828125, which then multiplied by 1.5 results in
895.999969482421875. If you just cast this to an integer, it'll
result in a height of 895px instead of the expected 896px.
This PR addresses the issue in two ways:
* Replace casts to integers with `lrint` or `floor`, etc.
* Remove many of the redundant double <> float conversions.
## PR Checklist
* Resizing my window always resizes the text buffer ✅
## Summary of the Pull Request
This pull request adds support for holding the control key and clicking
the Open Terminal Here context menu item to elevate the request.
## References and Relevant Issues
#14810
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
## PR Checklist
- [x] Closes#14810
- [ ] 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)
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
C++ is a very well balanced and reasonable language, which is why
`static` inside classes means "shared between all instances", whereas
`static` outside of classes means "not shared between all .cpp files".
32 years after this problem was written onto parchment it was fixed with
the introduction of inline variables in C++17, which tell the compiler
to deduplicate variables the same way it deduplicates functions.
It can be costly, difficult, or often impossible to compare two
instances of a struct. This little helper can simplify this.
The underlying idea is that changes in state occur much less often than
the amount of data that's being processed in between. As such, this
helper assumes that _any_ modification to the struct it wraps is a
state change. When you compare the modified instance with another
the comparison operator will then always return false. This makes
state changes potentially more costly, because more state might be
invalidated than was necessary, but on the other hand it makes both,
the code simpler and the fast-path (no state change) much faster.
For instance, let's look at the amount of data that represents a
user's chosen font: It encompasses the font family, size and weight,
font axes (a vector of tuples), dpi and cell height/width overrides.
Comparing all that data, every time the user changes anything, is
fairly complex to code and maintain and costly at runtime, even though
the user will change the only font very seldomly. Instead, we can
optimize for the common case of no font changes occuring and simply
assume that if any font related field changed, all fields changed.
This is exactly what `til::generational` does.
Updates the Terminal to Microsoft.UI.Xaml v2.8.
* MUX 2.8 adds a dependency on WebView2, so we need to include parts of it too.
* See https://github.com/microsoft/microsoft-ui-xaml/pull/7574 for why
we're adding the `.props`
* The TabView thing:
> tl;dr: In >=MUX 2.7, we were updating our tab colors by doing a
"Visual State Dance", as I called it. We'd manually change the
`TabViewItem`'s VisualState to one that it wasn't in, then change it
back to the one it should be in. This seemingly re-applied the new
values of the brushes. However in 2.8, this seemingly didn't work
anymore!
>
> So instead, we do a "Theme Dance", like so:
> ```c++
> const auto& reqTheme = TabViewItem().RequestedTheme();
> TabViewItem().RequestedTheme(ElementTheme::Light);
> TabViewItem().RequestedTheme(ElementTheme::Dark);
> TabViewItem().RequestedTheme(reqTheme);
> ```
> This causes the `ThemeResource`s to be re-evaluated to the new values.
> We never got to the root cause of why this seems different in 2.8. It
literally makes no sense.
Closes#13495
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
Rendering hyperlinks is unneccessarily complex at the moment, because
it requires you to implement `UpdateDrawingBrushes`, manually extract
the hyperlink flag from the given `TextAttribute` and save it until the
next call to `PaintBufferGridLines` which does not get that flag.
This isn't particularly clean as it assumes that `PaintBufferGridLines`
will be called after `UpdateDrawingBrushes` in the first place.
Instead, we can simply pass the hyperlink flag to `UpdateDrawingBrushes`
so that the renderers don't need to deal with this anymore.
## PR Checklist
* Hyperlinks show up with a dotted line ✅
* Hovering hyperlinks underline them ✅
This tool augments `vttest` by adding some things that are specific to
us (like non-VT console attributes), and some things `vttest` is
seemingly too old for (like emojis). I'm planning to add more "pages"
of tests to the application in the future, whenever the need arises.
Two PowerShell scripts were added so that developers new to the project
know if they have the wrong version of PowerShell installed.
When first building Terminal, it would continuously fail, and I didn't
really know why. I'm new to both this project and to open source, so
when I saw an error message about "pwsh.exe" not being found I was
confused and didn't know what went wrong. What I didn't know is that
Windows PowerShell and PowerShell Core had different names for
their .exe files, and since I had the latest version of Windows
PowerShell installed, I figured that I was completely set. So, once I
realized that Windows PowerShell (what I had installed) is
powershell.exe and PowerShell Core (what I needed to have installed) is
pwsh.exe, I downloaded PowerShell Core, and it built without issue. So,
in order to help other newbies, I made two scripts, `CheckPSVersion` and
`WindowsCheckPSVersion`, which make sure that PowerShell Core 7.0.0+ is
installed, outputting an error telling the developer to download Core
7.0.0+ if they have Windows PowerShell but not Core. These scripts are
run pre-build courtesy of `Microsoft.Terminal.Settings.ModelLib.vcxproj`
## Validation Steps Performed
Building with both Windows PowerShell and PowerShell core: builds
perfectly, no issues.
Building with Windows PowerShell but not PowerShell core: build fails,
but a nice error prints out that reminds the user to download the
correct version of PowerShell core.
Closes#14797
This pull request implements portable mode for Windows Terminal, which
will make side by side deployment of different versions generally more
feasible.
Portable mode was specified in #15032.
There are three broad categories of changes in this PR:
1. Changes to settings loading.
2. A new indicator in the settings UI plus a link to the portable mode
docs.
3. A new application display name, `Terminal (Portable)`, which users
will hopefully include in their bug reports.
It's surprisingly small for how big a deal it is!
Related to #15034Closes#1386
_This is the last one 🎉_
## Summary
_In the final chapter of our tale, we present a PR of great
significance. It grants the power to tear tabs from their windows and
create a new window where they may be dropped, one not necessarily of
the Terminal sort. The dimensions of the original window are transferred
to this new abode, and its placement on the screen is determined by the
user's placement of the tab._
_This is the last main chapter of the tear-out saga, and the dawning of
the new age._
Closes#5000
Related to #1256
## Detailed description
We're really leaning on the existing `RequestNewWindow` event that the
monarch already had - honestly, most of that was so simple that it could
have just been in the parent PRs. We just need to add new support for
passing in a content blob of json, and making sure the Terminal always
uses that over commandline args. Easy enough.
There's a bit of wackiness here in adjusting the positioning just right
so that the new window appears in the right place, but it feels...
pretty good all things considered.
Since the removal of the Win10-specific variant of the Terminal MSIX in
#15031, there has been no officially-sanctioned (or even unofficially
tested!) way to get an unzippable double-click-runnable version of
Windows Terminal.
Due to a quirk in the resource loading system, an unpackaged
distribution of Terminal needs to ship all of XAML's resources and all
of is own resources in a single `resources.pri` file. The tooling to
support this is minimal, and we were previously just coasting by on
Visual Studio's generosity plus how the prerelease distribution of XAML
embedded itself into the consuming package.
This pull request introduces a build phase plus a supporting script (or
three) that produces a ZIP file distribution of Windows Terminal when
given a Terminal MSIX and an XAML AppX.
The three scripts are:
1. A script to merge any number of PRI files and/or PRI dump files (made
with `makepri dump /dt detailed`)
2. A script that specifically merges XAML's resources with Terminal's.
This is necessary because the XAML package emits a couple PRI
resources into Terminal's resources _even when it is not
co-packaged._ We need to remove the conflicting resources.
3. Finally, a script to take a WT and XAML distribution and combine them
-- resources, files, everything -- and strip out the things that we
don't need. This script is an all-in-one that calls the other two and
produces a ZIP file at the end.
The final distribution is named after the PFN
(`Microsoft.WindowsTerminal`, or `...Preview` or `WindowsTerminalDev`),
the version number and the architecture. When expanded, it produces a
directory named `terminal-X.Y.Z.A` (version number.)
I've also added the build script to the release pipeline.
As a treat, this also produces an unpackaged distribution out of every
CI build... that way, contributors can download live deployable copies
of WT Unpackaged to test out their changes. Pretty cool.
Refs #1386
The main purpose of this PR was to merge the `ITerminalApi::LineFeed`
implementations into a shared method in `AdaptDispatch`, and avoid the
VT code path depending on the `AdjustCursorPosition` function (which
could then be massively simplified). This refactoring also fixes some
bugs that existed in the original `LineFeed` implementations.
## References and Relevant Issues
This helps to close the gap between the Conhost and Terminal (#13408).
This improves some of the scrollbar mark bugs mentioned in #11000.
## Detailed Description of the Pull Request / Additional comments
I had initially hoped the line feed functionality could be implemented
entirely within `AdaptDispatch`, but there is still some Conhost and
Terminal-specific behavior that needs to be triggered when we reach the
bottom of the buffer, and the row coordinates are cycled.
In Conhost we need to trigger an accessibility scroll event, and in
Windows Terminal we need to update selection and marker offsets, reset
pattern intervals, and preserve the user's scroll offset. This is now
handled by a new `NotifyBufferRotation` method in `ITerminalApi`.
But this made me realise that the `_EraseAll` method should have been
doing the same thing when it reached the bottom of the buffer. So I've
added a call to the new `NotifyBufferRotation` API from there as well.
And in the case of Windows Terminal, the scroll offset preservation was
something that was also needed for a regular viewport pan. So I've put
that in a separate `_PreserveUserScrollOffset` method which is called
from the `SetViewportPosition` handler as well.
## Validation Steps Performed
Because of the API changes, there were a number of unit tests that
needed to be updated:
- Some of the `ScreenBufferTests` were accessing margin state in the
`SCREEN_INFORMATION` class which doesn't exist anymore, so I had to add
a little helper function which now manually detects the active margins.
- Some of the `AdapterTest` tests were dependent on APIs that no longer
exist, so they needed to be rewritten so they now check the resulting
state rather than expecting a mock API call.
- The `ScrollWithMargins` test in `ConptyRoundtripTests` was testing
functionality that didn't previously work correctly (issue #3673). Now
that it's been fixed, that test needed to be updated accordingly.
Other than getting the unit tests working, I've manually verified that
issue #3673 is now fixed. And I've also checked that the scroll markers,
selections, and user scroll offset are all being updated correctly, both
with a regular viewport pan, as well as when overrunning the buffer.
Closes#3673
_Behold, the penultimate chapter in the saga of tear-out! This
significant update bestows upon the user the power to transport tabs
betwixt Terminal windows. Alas, the drag and drop capabilities of
TabView are not yet refined, so this PR primarily concerns itself with
the intricacies of plumbing. When a tab is extracted and deposited
elsewhere, it is necessary to have the recipient make an inquiry to the
Monarch, who in turn will beseech the sender to transmit the tab
content, akin to the act of moving a tab. Curious it may seem, but the
method has proven effective._
The penultimate tear-out PR. This PR enables the user to move tabs from
one Terminal window to another. The TabView drag/drop APIs have some
rough edges, so this PR is mostly plumbing. When a tab is drag/dropped,
we need to get the recipient to ask the Monarch to ask the sender to
send the tab content, like a MoveTab action. Wacky, but it works.
There's a LONG tail of UX gaps. Those I'm going to track in #14900. It
is more valuable for us to merge this now than to figure out workarounds
immediately.
The next PR will be the last main PR in this saga - in which we enable
dragging a tab out of the window and dropping to create a new window.
* Closes#1256
* Related to #5000
* Follow-ups get to go in #14900
## Detailed description
As I mentioned, it's mostly plumbing. The order that we get tab drag
events is... unfortunate... for our use case. So we do a lot of sending
`RequestReceiveContentArgs` up and down between windows, just to
communicate who the tab was dropped on to whomever the tab was dragged
from.
There's a diagram for this that I originally put in
https://github.com/microsoft/terminal/issues/5000#issuecomment-1435328038:
```mermaid
sequenceDiagram
participant Source
participant Target
participant Monarch
Note Left of Source: _onTabDragStarting
Source --> Source: stash dragged content
Source --> Source: pack window ID into DataPackage
Source ->> Target: Drag tab
Note right of Target: _onTabStripDragOver
Target ->> Target: AcceptedOperation(DataPackageOperation::Move)
Source --> Target: Release mouse (to drop)
Note right of Target: _onTabStripDrop
Target --> Target: get WindowID from DataPackage
Target -) Monarch: Request that WindowID sends content to us<br>RequestRecieveContent
Monarch -) Source: Tell to send content to Target.Id<br>RequestSendContent, SendContent
Source --> Source: detach our content
Source -) Monarch: RequestMoveContent(stashed, target.id)
Monarch -) Target: AttachContent(stashed)
# Target -->> Source:
# Note Left of Source: TabViewTabDragStartingEventArgs<br>.OperationCompleted
# Note Left of Source: _onTabDroppedCompleted
```
Really really though, let's try to avoid nits about the UX at this time.
This PR works with what we've got. Mail threads are percolating. I've
got 19 chapters worth of Hobbit branch names to use for those follow
ups.
_Lo! Harken to me, for I shall divulge the heart of the tab tear-out
saga. Verily, this PR shall bestow upon thee the power to move tabs and
panes between windows by means of pre-defined actions. Though be warned,
it does not yet grant thee the power to drag and drop them as thou
mayest desire. Yet, the same plumbing that underpins this work shall
remain steadfast. Behold, the majority of this undertaking concerns the
elevation of the RequestMoveContent event from the TerminalPage to the
very summit of the Monarch. From thence, a great AttachContent method
shall descend back to the lowest depths. Furthermore, there are minor
revisions to TermControl that shall enable thee to better detach the
content and attach it to a new one._
This is the most important part of the tab tear-out saga. This PR
enables the user to move tabs and panes between windows using
pre-defined actions. It does _not_ enable the user to drag/drop them
yet, but the same fundamental plumbing will still apply. Most of the PR
is plumbing the `RequestMoveContent` event up from the `TerminalPage` up
to the `Monarch`, and then plumbing an `AttachContent` method back down.
There are also small changes to `TermControl` to better support
detaching the content and attaching to a new one.
For testing, I recommend:
```json
{ "keys": "f1", "command": { "action": "moveTab", "window": "1" } },
{ "keys": "f2", "command": { "action": "moveTab", "window": "2" } },
{ "keys": "f3", "command": { "action": "movePane", "window": "1" } },
{ "keys": "f4", "command": { "action": "movePane", "window": "2" } },
{ "keys": "shift+f3", "command": { "action": "movePane", "window": "1", "index": 3 } },
{ "keys": "shift+f4", "command": { "action": "movePane", "window": "2", "index": 3 } },
```
* Related to #1256
* Related to #5000
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
When saving and restoring the cursor position with origin mode enabled,
we originally matched the behavior of the early DEC terminals, which
stored the position as an absolute offset. But if the margin boundaries
were changed prior to restoring the position, that could result in the
cursor being outside the margins, potentially with negative coordinates.
Our implementation avoided that bug by clamping the coordinates back
into range, but that's not how DEC ultimately fixed the issue. Starting
with the VT420, they began using relative coordinates (i.e. relative to
the margin origin), so a restored position could never end up negative.
This PR updates our implementation to match that newer behavior.
## Validation Steps Performed
Thank to testing performed by @al20878, we know this was the algorithm
used on the VT420, VT520, and VT525, and I've manually confirmed that
our implementation now matches their behavior.
I've also updated the `CursorSaveRestore` unit test which previously
covered our clamping behavior - it's now being used to confirm that
we're correctly using relative offsets when restoring the cursor.
Closes#15048
[Flexible Virtualization] is a little more restrictive than
`unvirtualizedResources`, but it's more descriptive and stands a chance
of working on Windows 10.
This makes `unvirtualizedResources` actually work for us - we can tell
the system exactly which registry keys we want to use. This is required
for our registry writes to work on Windows 10.
[Flexible Virtualization]:
https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization
This regression is caused by 0eff8c0. It previously said `.Y` here.
I went through the diff again and found no other width/height mistake.
Closes#14762Closes#15043
This adds PR adds a couple foundational functions and classes to make
our TextBuffer more performant and allow us to improve our Unicode
correctness in the future, by getting rid of our dependence on
`OutputCellIterator`. In the future we can then replace the simple
UTF-16 code point iterator with a proper grapheme cluster iterator.
While my focus is technically on Unicode correctness, the ~4x VT
throughput increase in OpenConsole is pretty nice too.
This PR adds:
* A new, simpler ROW iterator (unused in this PR)
* Cursor movement functions (`NavigateToPrevious`, `NavigateToNext`)
They're based on functions that align the cursor to the start/end
of the _current_ cell, so such functions can be added as well.
* `ReplaceText` to write a raw string of text with the possibility to
specify a right margin.
* `CopyRangeFrom` will allow us to make reflow much faster, as it's able
to bulk-copy already measured strings without re-measuring them.
Related to #8000
## Validation Steps Performed
* enwik8.txt, zhwik8.txt, emoji-test.txt, all work with proper
wide glyph reflow at the end of a row ✅
* This produces "a 咪" where only "a" has a white background:
```sh
printf '\e7こん\e8\x1b[107ma\x1b[m\n'
```
* This produces "abん":
```sh
stdbuf -o0 printf '\x1b7こん\x1b8a'; printf 'b\n'
```
* This produces "xy" at the end of the line:
```sh
stdbuf -o0 printf '\e[999C\bこ\bx'; printf 'y\n'
```
* This produces red whitespace followed by "こ " in the default
background color at the end of the line, and "ん" on the next line:
```sh
printf '\e[41m\e[K\e[m\e[999C\e[2Dこん\n'
```
We ship a separate package to Windows 10, which contains a copy of XAML
embedded in it, because of a bug in activating classes from framework
packages while we're elevated.
We did this to avoid wasting disk space on Windows 11 installs (which is
critical given that we're preinstalled in the Windows image.)
The fix for this issue was released in a servicing update in April 2022.
Thanks to KB5011831, we no longer need this workaround!
And finally, this means that we no longer need to depend on a copy of
"pre-release" XAML. We only did that because it would copy all of its
assets into our package.
Introduced in #12560Closes#14106
Closes (discussion) #14981
Reverts #14660
* These `Icon` bindings were to `Profile`s which aren't Observable, but
it also doesn't matter
* More c# warnings
hopefully we'll just jump straight to real errors now.
If we get initialized with a window name, this will be called before
XAML is stood up, and constructing a PropertyChangedEventArgs will
throw. So don't.
Regressed in #14843
Related to #5000, #14957
This PR introduces two new sequences, `DECRQPSR` and `DECRSPS`, which
provide a way for applications to query and restore the presentation
state reports. This includes the tab stop report (`DECTABSR`) and the
cursor information report (`DECCIR`).
One part of the cursor information report contains the character set
designations and mapped G-sets. But we weren't tracking that data in a
way that could easily be reported, so I needed to do some refactoring in
the `TerminalOutput` class to make that accessible.
Other than that, the rest was fairly straightforward. It was just a
matter of packaging up all the information into the correct format for
the returned `DCS` string, and in the case of the restore operations,
parsing the incoming data and applying the new state.
## Validation Steps Performed
Thanks to @al20878, we were able to test these operations on a real
VT525, and I've manually verified that our implementation matches that
behavior. I've also added some unit tests covering both reports.
Closes#14984
When a `DECCRA` operation is copying content that spans a double width
line, it's possible that some range of the bounding rectangle will be
off-screen, and that range is not supposed to be copied. However, the
code checking for off-screen positions was using incorrect coordinates,
so we would mistakenly copy content that shouldn't be copied, and drop
content that should have been copied. This PR fixes that.
## References and Relevant Issues
This was a regression introduced in PR #14650 when fixing an issue with
horizontal scrolling of DBCS characters.
## Validation Steps Performed
I manually verified this fixes the test case in #15019, and I've also
added a unit test that replicates that case.
Closes#15019
## Summary of the Pull Request
PR adds functionality to enable or disable readOnly mode within panes.
This functionality is different to toggling as if you call the same
functionality twice, it will not toggle between states.
## References and Relevant Issues
- Closes https://github.com/microsoft/terminal/issues/14415
- Documentation https://github.com/MicrosoftDocs/terminal/pull/645
## Validation Steps Performed
- Checked readOnly is enabled when command triggered
- Checked readOnly is enabled when command triggered while read only
already enabled
- Checked readOnly is disabled when command triggered while read only is
enabled
- Checked readOnly stays disabled when command triggered while read only
is disabled
- Checked above with multiple tabs and split panes
## PR Checklist
- [ ] Closes#14415
- [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/645
- [X] Schema updated (if necessary)
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
## Summary
_Thus we come to the introduction of a new servant, the
`ContentManager`, a singular entity that serves at the behest of the
`emperor`. It is its charge to keep track of all `TermControl` instances
created by the windows, for each window must seek its blessing before
calling forth such an instance._
_With the aid of the `ContentManager`, the `TermControl` shall now be
traced by the hand of fate through the use of unique identifying marks,
known as `GUID`s. Yet, its purpose remains yet unknown, for it is merely
a waypoint upon the journey yet to come._
_This act of bridging also brings a change to the handling of events
within the `TermControl`. This change shall see the addition of a
revoker, similar to the manner in which the `AppHost` hath employed it,
to the `TermControl`. Additionally, there is a new layer of indirection
between the `ControlCore` and the `App` layer, making ready for the day
when the `TermControl` may be repositioned and re-parented with ease._
_Consider this but a trivial act, a mere shadow of things yet to come,
for its impact shall be felt but briefly, like the passing of a gentle
breeze._
Related to #5000
Related to #1256
# Detailed description
This PR is another small bridge PR between the big work in #14843, and
the PR that will enable panes to move between windows.
This introduces a new class, called `ContentManager`. This is a global
singleton object, owned by the emperor. Whenever a window wants to
instantiate a new `TermControl`, it must ask the ContentManager to give
it one. This allows the ContentManager to track each "content" by GUID.
That's it. We don't do anything with them in this PR by itself, we just
track them.
This also includes a small change to the way TermControl events are
handled. It adds an `AppHost`-like revoker struct, and weak_ref's all
the handlers. We also add a layer of indirection between the
ControlCore's raising of events and the App layer's handling. This will
make reparenting content easier in the future.
This is a pretty trivial change which shouldn't have any major side
effects. Consider it exposition of the things to come. It's
intentionally small to try and keep the reviews more managable.
Due to a limitation in the Windows App Installer UI, Terminal had to
shell out to `reg.exe` to write the Delegation registry keys. The team
in charge of AppInstaller lifted that (once by-policy) limitation.
Therefore, we can remove our BODGY workaround.
It was brought to my attention that we should be more restrictive in
which tasks we ovver a GitHub token to. Sorry!
With thanks to sitiom for the version parsing and the magic GitHub
action syntax incantation for determining what is a prerelease.
## 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
```
[The winget-releaser action] automatically generates manifests for the
[Winget Community Repository] and submits them.
I suggest adding Dependabot to keep the action up to date. There were
many cases where the action was failing due to an outdated version.
Closes#14795
[The winget-releaser action]:
https://github.com/vedantmgoyal2009/winget-releaser
[Winget Community Repository]: https://github.com/microsoft/winget-pkgs
Credit where credit is due - @jboelter did literally all the hard work.
I just separated this out to two elements:
* Are we running elevated?
* Can we drag drop?
As we learned in #7754, the builtin administrator _can_ drag drop. But
critically, they are also running as admin! The way we had this logic
before, we're treat them as unelevated, because we had been overloading
the meaning here.
This splits these into two separate functions. Comes with the added
benefit of re-adding the elevation shield to the Terminal window for
users with UAC disabled (which was missing before) (and can _still_ be
disabled).
Closes#13928
Tested on a Win10 VM with `EnableLua=0`
#14745 contains two regressions related to console alias handling:
* When `ProcessAliases` expands the backup buffer into (an) aliased
command(s) it changes the `_bytesRead` field of `COOKED_READ_DATA`,
requiring us to re-read it and reconstruct the `input` string-view.
* Multiline aliases are read line-by-line whereas #14745 didn't treat
them any different from regular single-line inputs.
## Validation Steps Performed
In `cmd.exe` run
```
doskey test=echo foo$Techo bar$Techo baz
test
```
The output should look exactly like this:
```
C:\>doskey test=echo foo$Techo bar$Techo baz
C:\>test
foo
C:\>bar
C:\>baz
C:\>
```
This PR adds support for querying the color indices set by the `DECAC`
control, using the existing `DECRQSS` implementation.
## References and Relevant Issues
The initial `DECRQSS` support was added in PR #11152.
The `DECAC` functionality was added in PR #13058, but at the time we
didn't know how to format the associated `DECRQSS` query.
## Detailed Description of the Pull Request / Additional comments
For most `DECRQSS` queries, the setting being requested is identified by
the final characters of its escape sequence. However, for the `DECAC`
settings, you also need to include a parameter value, to indicate which
color item you're querying.
This meant we needed to extend the `DECRQSS` parser, so I also took this
opportunity to ensure we correctly parsed any parameter prefix chars. We
don't yet support any setting requiring a prefix, but this makes sure we
don't respond incorrectly if an app does query such a setting.
## Validation Steps Performed
Thanks to @al20878, we've been able to test how these queries are parsed
on a real VT525 terminal, and I've manually verified our implementation
matches that behavior.
I've also extended the existing `DECRQSS` unit test to confirm that we
are responding to the `DECAC` queries as expected.
Closes#13091
Experimental for now. `experimental.rightClickContextMenu`, a
per-profile setting. Long term we want to enable full mouse bindings, at
which point this would be replaced.
Closes#3337
This adds **two** context menus to the `TermControl` - one for
right-clicking with a selection, and one without. The implementation is
designed to follows the API experience of the context menu on something
like a [`RichEditBox`](winui2gallery://item/RichEditBox). The hosting
application adds a handler for the menu's `Opening` event, and appends
whatever items it wants at that time.
So `TermControl` only implements a few "actions" by default - copy,
past, find. `TerminalApp` is then responsible for adding anything else
it needs. Right now, those actions are:
* Duplicate tab
* Duplicate pane
* Close Tab
* Close pane
Screenshots in
https://github.com/microsoft/terminal/pull/14775#issuecomment-1415737393
Azure Devops jumps to these as the first "error" when you open a failing
build. But these are warnings, not errors. So you're left hunting for
the real error. _If only someone had scrollbar marks for indicating
lines with error messages..._
May as well clean them up.
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 two things related to URLs emitted via OSC8.
* Allows `wsl$` and `wsl.localhost` as the hostname in `file://` URIs
* Generally allows _all_ URIs that parse as a URI.
The relevant security comments: https://github.com/microsoft/terminal/pull/7526#issuecomment-764160208
> this doesn't let a would-be attacker specify command-line arguments (ala "cmd.exe /s /c do_a_bad_thing") (using somebody else's reputation to cause mayhem)
>
> `ShellExecute` de-elevates because it bounces a launch request off the shell
>
> "Works predictably for 15% of applications" (h/t to PhMajerus' AXSH, and other on-Windows requestors) is better in so many ways than "Works for 0% of applications", in my estimation. Incremental progress 😄 while we work on features that'll make it even more broadly applicable.
Closes#10188Closes#7562
_And so begins the first chapter in the epic tale of the Terminal's tab
tear-out. This commit, though humble in its nature, shall mark the
beginning of a grand journey._
_This initial offering, though small in its scope, doth serve to divide
the code that currently resides within TerminalPage and AppLogic, moving
it unto a new entity known as TerminalWindow. In the ages to come, these
classes shall take on separate responsibilities, each with their own
purpose._
_The AppLogic shall hold sway over the entire process, shared among all
Terminal windows, while the AppHost, TerminalWindow, and TerminalPage
shall rule over each individual window._
_This pull request prepares the way for the future, moving state that
pertains to the individual windows into the TerminalWindow. This is a
task of great labor, for it requires moving much code, but the end
result shall bring greater organization to the codebase._
_And so the stage is set, for in the next pull request, the Process
Model v3 shall be revealed, unifying all Terminal windows into a single
process, a grand accomplishment indeed._
_courtesy of G.P.T. Tolkien_
<details>
<summary>Or, as I wrote it originally. </summary>
This is the first of the commits in the long saga which will culminate
in tab tear-out for the Terminal.
This the most functionally trivial of the PRs. It mostly just splits up
code that's currently in TerminalPage & AppLogic, and moves it into a
new class `TerminalWindow`. In the future, these classes will separate
responsibility as such:
* There will be one `AppLogic` per process, shared across all Terminal
windows.
* There will be one `AppHost`, `TerminalWindow`, and `TerminalPage` for
each individual window in the process.
This PR prepares for that by moving some state that's applicable to
_individual windows_ into `TerminalWindow`. This is almost exclusively a
code moving PR. There should be minimal functional changes.
</details>
In the next PR, we'll introduce the actual "Process Model v3", merging
all Terminal windows into a single terminal process.
Related to #5000. See
https://github.com/Microsoft/terminal/issues/5000#issuecomment-1407110045
for my current todo list.
Related to #1256.
These commits are all artificially broken down pieces. Honestly, I don't
want to really merge them till they're all ready, so we know that the
work e2e. This my feigned attempt to break it into digestable PRs.
Lightly manually tested, things seem to still all work? Most of this
code was actually written in deeper branches, it was only today I
realized it all needed to come back to this branch.
* [x] The window persistence fishy-ness of the subsequent PR isn't
present here. So that's something.
* [x] Localtests still pass
### Detailed description
> Q: Does `AppLogic` not keep track of its windows?
Sure doesn't! I didn't think that was something it needed to know.
>Q: Why does `TerminalWindow` (per-window) have access to the
commandline args (per-process)
It's because it's _not_ per process. Commandline args _are_ per-window.
Consider - you launch the Terminal, then run a `wt -w -1 -- foo`. That
makes its own window. In this process, yes. But that new window has its
own commandline args, separate from the ones that started the original
process.
The `Sample` method has an offset parameter which we can use here.
The result is not identical to the old shader, as the older shader
used the height of the terminal for drawing horizontal edges and so
the result looked way fatter than it was seemingly originally intended.
On my 150% scale display I found an offset of +/- 2px to produce an
acceptable result, although in the future it might be worthwhile to
make the offset dependent on the UI scale.
Closes#14953
## Summary of the Pull Request
This fixes a couple of audit failures in `TerminalCore` where the
compiler was complaining about functions that should have been declared
as `noexcept`.
These failures have actually existed for a while, but you'd only see
them if you ran the audit build locally. They only recently started
showing up on the CI build server - I'm guessing because the compiler
there has now been upgraded.
## Validation Steps Performed
Compiled the audit build locally and it no longer fails.
This PR implements the `DECRQCRA` escape sequence, which lets you
request a checksum of a portion of the screen. This is most useful in
automated testing to verify that the generated screen content is what it
was expected to be.
For now this functionality is gated behind a feature flag which is only
enabled for dev builds.
## Detailed Description of the Pull Request / Additional comments
I've done my best to match the DEC checksum algorithm as closely as
possible, which we've determined by testing on a real VT525 terminal
(many thanks to @al20878 for that).
The checksum is an unsigned 16-bit value that starts off at zero, and
from which you then subtract the ordinal value of every character in the
selected range. It's also affected by the rendition attributes in the
selected cells.
* Bold/Intense - subtract 0x80
* Blinking - subtract 0x40
* Reverse video - subtract 0x20
* Underlined - subtract 0x10
* Invisible - subtract 0x08
* Protected - subtract 0x04
* Background color - subtract the color index
* Foreground color - subtract the color index * 0x10
I should note that our ordinal calculation only matches DEC for the
characters in the ASCII and Latin-1 range, because the original
algorithm predates Unicode. If we want to support the other character
sets correctly we'll need custom mapping tables, but I didn't think that
was essential for now.
It's also worth mentioning that we don't handle "empty" cells correctly,
but that's not the fault of the checksum calculation - it's just that
our default fill character is a space rather than a `NUL`.
## Validation Steps Performed
I've manually compared our implementation against the tests results that
@al20878 got from the VT525, and confirmed that we match as well as was
expected (i.e. taking into account the limitations mentioned above).
I've also added a few basic unit tests that verify we're generating the
expected checksums for the various renditions and color attributes.
Closes#14974
Adds a helper that replicates how the `RegenerateUserEnvironment()`
method in `shell32.dll` behaves.
* Raises #12516 from the dead.
* Half of #1125
Co-authored-by: Michael Niksa <miniksa@microsoft.com>
When a character is written in the last column of a row, the cursor
doesn't move, but instead sets a "delayed EOL wrap" flag. If another
character is then output while that flag is still set, the cursor moves
to the start of the next line, before writing to the buffer.
That flag is supposed to be reset when certain control sequences are
executed, but prior to now we haven't always handled that correctly.
With this PR, we should be resetting the flag appropriately in all the
places that it's expected to be reset.
For the most part, I'm following the DEC STD 070 reference, which lists
a bunch of operations that are intended to reset the delayed wrap flag:
`DECSTBM`, `DECSWL`, `DECDWL`, `DECDHL`, setting `DECCOLM` and `DECOM`,
resetting `DECCOLM`, `DECOM`, and `DECAWM`, `CUU`, `CUD`, `CUF`, `CUB`,
`CUP`, `HVP`, `BS`, `LF`, `VT`, `FF`, `CR`, `IND`, `RI`, `NEL`, `ECH`,
`DCH`, `ICH`, `EL`, `DECSEL`, `DL`, `IL`, `ED`, and `DECSED`.
We were already resetting the flag for any of the operations that
performed cursor movement, since that always triggers a reset for us.
However, I've now also added manual resets in those ops that weren't
moving the cursor.
Horizontal tabs are a special case, though. Technically the standard
says they should reset the flag, but most DEC terminals never followed
that rule, and most modern terminals agree that it's best for a tab to
leave the flag as it is. Our implementation now does that too.
But as mentioned above, we automatically reset the flag on any cursor
movement, so the tab operation had to be handled as a special case,
saving and restoring the flag when the cursor is updated.
Another flaw in our implementation was that we should have been saving
and restoring the flag as part of the cursor state in the `DECSC` and
`DECRC` operations. That's now been fixed in this PR too.
I should also mention there was a change I had to make to the conpty
renderer, because it was sometimes using an `EL` sequence while the
terminal was in the delayed EOL wrap state. This would reset the flag,
and break subsequent output, so I've now added a check to prevent that
from happening.
## Validation Steps Performed
I've added some unit tests that confirm the operations listed above are
now resetting the delayed EOL wrap as expected, and I've expanded the
existing `CursorSaveRestore` test to make sure the flag is being saved
and restored correctly.
I've also manually confirmed that the test case in issue #3177 now
matches XTerm's output, and I've confirmed that the results of the
wraptest script[^1] now match XTerm's results.
[^1]: https://github.com/mattiase/wraptest/Closes#3177
The overarching intention of this PR is to improve our Unicode support.
Most
of our APIs still don't support anything beyond UCS-2 and DBCS
sequences.
This commit doesn't fix the UTF-16 support (by supporting surrogate
pairs),
but it does improve support for UTF-8 by allowing longer `char`
sequences.
It does so by removing `TranslateUnicodeToOem` which seems to have had
an almost
viral effect on code quality wherever it was used. It made the
assumption that
_all_ narrow glyphs encode to 1 `char` and most wide glyphs to 2
`char`s.
It also didn't bother to check whether `WideCharToMultiByte` failed or
returned
a different amount of `char`s. So up until now it was easily possible to
read
uninitialized stack memory from conhost. Any code that used this
function was
forced to do the same "measurement" of narrow/wide glyphs, because _of
course_
it didn't had any way to indicate to the caller how much memory it needs
to
store the result. Instead all callers were forced to sorta replicate how
it
worked to calculate the required storage ahead of time.
Unsurprisingly, none of the callers used the same algorithm...
Without it the code is much leaner and easier to understand now. The
best
example is `COOKED_READ_DATA::_handlePostCharInputLoop` which used to
contain 3
blocks of _almost_ identical code, but with ever so subtle differences.
After
reading the old code for hours I still don't know if they were relevant
or not.
It used to be 200 lines of code lacking any documentation and it's now
50 lines
with descriptive function names. I hope this doesn't break anything, but
to
be honest I can't imagine anyone having relied on this mess in the first
place.
I needed some helpers to handle byte slices (`std::span<char>`), which
is why
a new `til/bytes.h` header was added. Initially I wrote a `buf_writer`
class
but felt like such a wrapper around a slice/span was annoying to use.
As such I've opted for freestanding functions which take slices as
mutable
references and "advance" them (offset the start) whenever they're read
from
or written to. I'm not particularly happy with the design but they do
the job.
Related to #8000Fixes#4551Fixes#7589Fixes#8663
## Validation Steps Performed
* Unit and feature tests ✅
* Far Manager ✅
* Fixes test cases in #4551, #7589 and #8663✅
This just removes some leftover code that I forgot to remove before the merge.
Additionally I forgot to add a newly added file to our `sources` build file.
Woops. Closes#14878
## Validation Steps Performed
* Font Family: Iosevka Term (v19.0.1)
* Font Size: 11pt (or 10px cell height in conhost)
* Display Scale: 100%
* "--------------" leaves no gap between the text and the cursor ✅
Our templates were declared in the wrong order in JsonUtils, so all we
needed to do was reorder them. The tests bear this out.
This allows us to disable two-phase template name lookup. I also fixed a
minor issue that resulted in the inclusion of too many copies of
expandIconPath.
Interesting things we could do after this:
- remove all `InitializeComponent` calls - they do it automatically
- have some Clang support (!)
- use `std::optional`<->`IReference` automatic binding
- use `std::format` support (!) for json/uri/hostname/http stuff/all
`IStringable`s
- potentially move to `/await:strict` for C++20 coroutines
I've also fixed up a couple ambiguities introduced by this change.
* `lld-link` is more strict about the casing of keywords in `.def` files
* `[[nodiscard]]` must come before `virtual` and `static` qualifiers
* `precomp.h` is never to be included with `<>`
* We were calling the jsoncpp constructors directly (oops) as functions
(oops)
* ClipboardTests constructed `KeyEvent`s by copy instead of directly
* While we can `await` a `Dispatcher`, it's clearer to add `resume_foreground`
#13626 contains a small "regression" compared to #13321:
It now began to store trailers in the buffer wherever possible to allow
a region
of the buffer to be backed up and restored via Read/WriteConsoleOutput.
But we're unfortunately still ill-equipped to handle anything but UCS-2
via
WriteConsoleOutput, so it's best to again ignore trailers just like in
#13321.
## Validation Steps Performed
* Added unit test ✅
This commit makes the following project-wide changes/replacements as a
first step in cleaning up our use of `NTSTATUS`.
* Rewriting any uses of `NTSTATUS_FROM_WIN32` that were vulnerable to multiple evaluation bugs
* This is required because the macro version of `NTSTATUS_FROM_WIN32` evaluates its argument twice
* Removing all our local redefinitions of `NTSTATUS` in favor of that of `winternl.h`
* Because of this, we got to (had to?) remove some old transclusions from `conddkrefs.h`
* `NT_SUCCESS` (ours) -> `SUCCEEDED_NTSTATUS` (wil)
* `VERIFY_IS_TRUE(NT_SUCCESS())` (overly elaborate) -> `VERIFY_NT_SUCCESS` (WEX)
* `VERIFY_SUCCESS_NTSTATUS` (ours) -> `VERIFY_NT_SUCCESS` (WEX)
* `!SUCCEEDED_NTSTATUS` -> `FAILED_NTSTATUS`
* One bad use of S_OK as an NTSTATUS -> `STATUS_SUCCESS`
* Removing `NTSTATUS` from any projects that do not use it
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 ✅
## Summary of the Pull Request
Let the profile pages' views have access to the window root, rather than the `ProfileViewModel`. The window root is passed along when the page is navigated to.
## Validation Steps Performed
Clicking `Browse` no longer crashes.
## PR Checklist
- [x] Closes#14808
This pull request removes, in full, our dependency on cpprestsdk. This
allows us to shed 500KiB-1.2MiB from our package off the top and enables
the following future investments:
- Removal of the App CRT forwarders to save an additional ~500KiB
- Switching over to the HybridCRT and removing our dependency on _any
CRT_.
cpprest was built on my dev box two or so years ago, and is in _utter_
violation of our compliance guidelines on SBOM et al.
In addition, this change allows us to use the proxy server configured
in Windows Settings.
I did this in four steps (represented roughly by the individual commits):
1. Switch from cpprest's http_client/json to Windows.Web.Http and
Windows.Data.Json
2. Switch from websocketpp to winhttp.dll's WebSocket implementation¹
3. Remove all remaining utility classes
4. Purge all dependencies from all projects and scripts on cpprest.
I also took this opportunity to add a feature flag that allows Dev
builds to run AzureConnection in-process.
¹ Windows.Networking.Sockets' API is so unergonomic that it was simply
infeasible (and also _horrible_) to use it.
## Validation Steps
I've run the Azure Connection quite a bit inproc.
Closes#4575.
Might be related to #5977, #11714, and with the user agent thing maybe #14403.
This is a rather trivial changeset. Now that these two are present in the
`std` namespace there's no reason for us to continue using the `gsl` ones.
Additionally this ensures future compatibility with other 3rd party libraries.
When working on #14745 I noticed that `SplitToOem` was in a bit of a poor state
as well. Instead of simply iterating over its `deque` argument and writing the
results into a new `deque` it used `pop` to advance the head of both queues.
This isn't quite exception safe and rather bloaty. Additionally there's no need
to call `WideCharToMultiByte` twice on each character if we know that the most
verbose encoding is UTF-8 which can't be any more than 4 chars anyways.
Related to #8000.
## PR Checklist
* 2 unit tests cover this ✅
When working on #14745 I found `KeyEvent`s a little hard to read in the
debugger. I noticed that this is because of sign extension when converting
`char`s to `wchar_t`s in `KeyEvent::SetCharData`.
The original console output modes were considered attributes of the
buffer, while later additions were treated as global state, and yet both
were accessed via the same buffer-based API. This could result in the
reported modes being out of sync with the way the system was actually
behaving, and a call to `SetConsoleMode` without updating anything could
still trigger unpredictable changes in behavior.
This PR attempts to address that problem by making all modes part of the
buffer state, and giving them predictable default values.
While this won't solve all the tmux layout-breaking issues in #6987, it
does at least fix one case which was the result of an unexpected change
in the `DISABLE_NEWLINE_AUTO_RETURN` mode.
All access to the output modes is now done via the `OutputMode` field in
`SCREEN_INFORMATION`. The fields that were tracking global state in the
`Settings` class (`_fAutoReturnOnNewline` and `_fRenderGridWorldwide`)
have now been removed.
We still have a global `_dwVirtTermLevel` field, though, but that now
serves as a default value for the `ENABLE_VIRTUAL_TERMINAL_PROCESSING`
mode when creating a new buffer. It's enabled for conpty mode, and when
the VT level in the registry is not 0. That default doesn't change.
For the VT alternate buffer, things works slightly differently, since
there is an expectation that VT modes are global. So when creating an
alt buffer, we copy the current modes from the main buffer, and when
it's closed, we copy them back again.
## Validation Steps Performed
I've manually confirmed that this fixes the problem described in issue
#14690. I've also added a basic feature test that confirms the modes are
initialized as expected when creating new buffers, and changes to the
modes in one buffer do not impact any other buffers.
Closes#14690
New-TerminalStackedChangelog used to generate logs that looked like this:
```
* [3] A commit that was seen 3 times
* A commit that was only seen once
* [2] Some other commit
```
Now it will generate logs that look like this:
```
/ base..branch-1
|/ base..branch-2
||/ base..branch-3
* [XXX] A commit that was seen 3 times
* [ X ] A commit that was only seen once
* [XX ] Some other commit
```
This format is more expressive, as it indicates _which branches_ contain which commits.
As a reminder, my release note writing style starts with a stacked changelog. It's how I tell (1) which commits are in the new preview release only, (2) which commits are in the new preview and the new stable release and (3) which commits were already released in a previous stable release.
Changes from 1 get included in the new changelog, changes from 2 get included in both and changes from 3 get deleted because they have already been released.
For some reason, Windows Terminal stops dispatching UIA TextChanged events sometimes. There isn't a reliable repro for this bug.
However, under NVDA's logger, it appears that when the bug does occur, we still dispatch UIA notifications (which may be ignored by NVDA in some configurations). A "quick fix" here is to dispatch a TextChanged event if we're going to dispatch a notification. Since we're just enabling a flag, we won't send two events at once.
Closes#10911
The `SignalTextChanged` crash seems to be occurring due to the `TermControlAutomationPeer` being destructed by the time the UIA event is actually dispatched. Even though we're already checking if TCAP and TermControl still exist, it could be that the TermControl is being closed as text is being output.
The proposed fix here is to record when the closing process starts and exposing that information directly to the TCAP. If TCAP sees that we're in the process of closing, don't bother sending a UIA event.
Closes#13978
Up until now, we have been relying on the catalog signature produced for our MSIX package.
There are some things (Packaged COM, Process Explorer as of 2022) that cannot handle catalog-signed
files. It's easier and safer for us to simply sign all the executables we produce before packaging them.
Unfortunately, we can't do it before we package them. We have to unpack and re-pack our package.
In the future, this will allow us to provide a codesigned distribution that is not in an MSIX package.
TEST=Ran a build and checked out the contents of the package. They were all signed!
Closes#13294Closes#12695Closes#9670
We forgot to updateTheme again when we change the titlebar color. That would result in us setting the titlebar visibility only when the settings were reloaded, but if the unfocused BG was opaque, and the focused was transparent, we'd use the current _unfocused_ color to set the titlebar visibility.
Also, this fixes a bug with `tabRow.BG: terminalBackground`
from teams for brevity
> tabRow.BG = terminalBackground might not work, and here's why
>
> the termcontrol's BG brush might be (r,g,b, 255), with an Opacity of 0
>
> so my "use mica when the brush's A is <1.0" doesn't work
>
closes#14563
This uses `shell:AppsFolder` to launch elevated instances of the app via
`ShellExecuteEx` and `runas` in elevate-shim.exe. The app to launch is
discovered via the `GetCurrentApplicationUserModelId` API.
e.g. `shell:AppsFolder\WindowsTerminalDev_8wekyb3d8bbwe!App`
This will fallback to launching `WindowsTerminal.exe` if it fails to
discover the app user model id to launch.
This also fixes a bug in elevate-shim where the first argument of
WinMain was lost (e.g. `new-tab`).
Curiously, `AppLogic::RunAsUwp()` is never called and
`AppLogic::IsUwp()` is always false when running debug builds locally
(e.g. WindowsTerminalDev). It's not clear if this is an artifact of
development packages or something else.
## Validation Steps Performed
Various manual debug/execution scenarios.
Verified the fallback path by running the unbundled app by extracting
the `CascadiaPackage_0.0.1.0_x64.msix` from the 'drop' build artifact.
Fixes#14501
This regressed when we implemented ColorSchemeViewModel in #13179.
This commit fixes that by automatically focusing the ColorSchemeListView
when we navigate to the ColorSchemes page, which makes sense from a
user experience perspective anyway.
Closes#11971
Specify the resource to use for the list view item background when selected.
References #14693
## Validation Steps Performed
Background is no longer blue, it is light gray (like in Windows 11). Screenshots below.
This should make sure we only use Mica for the BG of the SUI when we're on a Windows build that supports it. Otherwise, we're just gonna get the emergency backstop / full transparency under it.
Confirmed this fixes it on my win10 VM.
Closes#14667
This PR add support for the ANSI Insert/Replace mode (`IRM`), which
determines whether output characters are inserted at the active cursor
position, moving existing content to the right, or whether they should
overwrite the content that is already there.
The implementation is a bit of a hack. When that mode is enabled, it
first measures how many cells the string is expected to occupy, then
scrolls the target line right by that amount before writing out the new
text.
In the longer term it might be better if this was implemented entirely
in the `TextBuffer` itself, so the scrolling could take place at the
same time as the content was being written.
## Validation Steps Performed
I've added a very basic unit test that verifies the mode is working as
expected. But I've also done a lot more manual testing, confirming edge
cases like wide characters, double-width lines, and both with and
without wrapping mode enabled.
Closes#1947
## Summary of the Pull Request
When we navigate to the color schemes page, find the default color scheme (if present) and manually set the container's automation name to include the word 'default'.
Note that we don't want to change the actual `ColorSchemeViewModel`'s name since that name is used internally to identify schemes. We only want to change the `ListViewItem`'s name, i.e. the container in the SUI.
## PR Checklist
* [x] Closes#14401
* [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: #xxx
## Validation Steps Performed
Screen reader reads out the 'default' text now. It also correctly reads out the new default scheme if the default scheme is changed via SUI or json.
As of about 2022, the one's digit of the Build of our version is a placeholder value to differentiate the Windows 10 build from the Windows 11 build. Let's trim that out, it's only a source of confusion.
For additional clarity, let's omit the Revision, which _must_ be `.0`, and doesn't provide any value to report.
We will need to make sure we report releases as `1.17.ABC` now, instead of `1.17.ABC1.0`/`1.17.ABC2.0`
Let's not backport this. 1.17 will be the start of the new numbering scheme. Otherwise, `1.16.EFG` < `1.16.ABC1.0`, for an old version `ABC1` and a new version `EFG`.
* closes#14106
* As summarized here: https://github.com/microsoft/terminal/issues/14106#issuecomment-1289462310
`_Entries` was getting default constructed to `nullptr`. We should be careful about that.
Adds a test too, and fixes a regression in the local tests introduced in #13763.
Closes#14557
ColorScheme MVVM was implemented in #13179. This PR updates the
ProfileViewModel/AppearanceViewModels to use color scheme view models
instead of the raw settings model objects.
* [x] Updates ProfileViewModel/AppearanceViewModel to use
ColorSchemesPageViewModel/ColorSchemeViewModel implemented in #13179
* [x] Removes ProfilePageNavigationState
## Validation Steps Performed
Settings UI still works (we _probably_ want to bug bash this at some
point though as with all SUI changes)
The main purpose of this PR was to merge the `ITerminalApi::PrintString`
implementations into a shared method in `AdaptDispatch`, and avoid the
VT code path depending on `WriteCharsLegacy`. But this refactoring has
also fixed some bugs that existed in the original implementations.
This helps to close the gap between the Conhost and Terminal (#13408).
I started by taking the `WriteCharsLegacy` implementation, and stripping
out everything that didn't apply to the VT code path. What was left was
a fairly simple loop with the following steps:
1. Check if _delayed wrap_ is set, and if so, move to the next line.
2. Write out as much of the string as will fit on the current line.
3. If we reach the end of the line, set the _delayed wrap_ flag again.
4. Repeat the loop until the entire string has been output.
But step 2 was a little more complicated than necessary because of its
legacy history. It was copying the string into a temporary buffer,
manually estimated how much of it would fit, and then passing on that
partial buffer to the `TextBuffer::Write` method.
In the new implementation, we just pass the entire string directly to
`TextBuffer::WriteLine`, and that handles the clipping itself. The
returned `OutputCellIterator` tells us how much of the string is left.
This approach fixes some issues with wide characters, and should also
cope better with future buffer enhancements.
Another improvement from the new implementation is that the Terminal now
handles delayed EOL wrap correctly. However, the downside of this is
that it introduced a cursor-dropping bug that previously only affected
conhost. I hadn't originally intended to fix that, but it became more of
an issue now.
The root cause was the fact that we called `cursor.StartDeferDrawing()`
before outputting the text, and this was something I had adopted in the
new implementation as well. But I've now removed that, and instead just
call `cursor.SetIsOn(false)`. This seems to avoid the cursor droppings,
and hopefully still has similar performance benefits.
The other thing worth mentioning is that I've eliminated some special
casing handling for the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` mode and
the `WC_DELAY_EOL_WRAP` flag in the `WriteCharsLegacy` function. They
were only used for VT output, so aren't needed here anymore.
## Validation Steps Performed
I've just been testing manually, writing out sample text both in ASCII
and with wide Unicode chars. I've made sure it wraps correctly when
exceeding the available space, but doesn't wrap when stopped at the last
column, and with `DECAWM` disabled, it doesn't wrap at all.
I've also confirmed that the test case from issue #12739 is now working
correctly, and the cursor no longer disappears in Windows Terminal when
writing to the last column (i.e. the delayed EOL wrap is working).
Closes#780Closes#6162Closes#6555Closes#12440Closes#12739
I can't exactly repro #14559. I suspect that's due to #14567 having been merged. This, however, seemed related. Without this, we'll use the App's `RequestedTheme` (the one that can't be changed at runtime), rather than the user's `requestedTheme`. That will do weird things, like make the BG of the SUI dark, with white expanders.
I think this should close#14559.
Some investigation revealed that `_keyEvents` would get a `NULL_POINTER_READ` error. On the main thread, `RecordKeyEvent()` would be called, which mainly updates `_keyEvents`. On the renderer thread, `NotifyNewOutput()` would be called, which starts by iterating through `_keyEvents` and slowly clearing it out. On occasion, these two threads are modifying `_keyEvents` simultaneously, causing a crash.
The fix is to add a mutex on this variable.
Closes#14592
Basically what it says on the tin. For transparent tabs, we should layer on to the tab row to evaluate what the actual color of the tab will be. We did this for deselected tabs, but not for selected ones.
Gif below.
Closes#14561
## Summary of the Pull Request
Updates the tab event handling so that the "Export Text" and "Find" tab context menu items work when a tab isn't focused.
## PR Checklist
* [x] Closes#13948
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
Manually tested.
This builds upon #10749. When we added a separate pivot to track the "active" anchor, we forgot to update the pivot while circling. What does that mean? Moving the mouse would trigger us to update the selection using new endpoint and the old _pivot_, which hadn't been updated.
There's probably a more elegant way of doing this, but it's good enough.
Updated the test to cover this as well.
Closes#14462
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
#14461 is caused by a null pointer exception in `TerminalIsSelectionActive()`. Since this reveals that it is possible to enter a state where `_terminal` is null, I've gone ahead and added null-checks throughout the code to make it more stable.
Closes#14461
## Validation Steps Performed
Ran locally. Still works.
CascadiaSettings relies on getting a JsonUtils::DeserializationException
from the various JSON Utility functions, and then formatting that into
an error message. Well, DeserializationException tries to include an
object representation in its what() message . . . and generates an
exception trying to do so. CascadiaSettings never gets the
DeserializationException, and displays a weird message.
It's safe to remove the stringification in DeserializationException
because CascadiaSettings was never using it (_and_ because
CascadiaSettings was using an even better version of the same logic.)
Fixes#14373
When the buffer contains wide characters that occupy more than one cell,
and those cells are scrolled horizontally by exactly one column, that
operation can result in the wide characters being completely erased.
This PR attempts to fix that bug, although it's not an ideal long term
solution.
Although not really to blame, it was PR #13626 that exposed this issue.
The root of the problem is that scrolling operations copy cells one by
one, but wide characters are written to the buffer two cells at a time.
So when you move a wide character one position to the left or right, it
can overwrite itself before it's finished copying, and the end result is
the whole character gets erased.
I've attempt to solve this by getting the affected operations to read
two cells in advance before they start writing, so there's no risk of
losing the source data before it's fully output. This may not work in
the long term, with characters wider than two cells, but it should at
least be good enough for now.
I've also changed the `TextBuffer::Write` call to a `WriteLine` call to
improve the handling of a wide character on the end of the line, where
moving it right by one column would place it half off screen. It should
just be dropped, but with the `Write` method, it would end up pushed
onto the following line.
## Validation Steps Performed
I've manually confirmed this fixes all the test cases described in
#14626, and also added some unit tests that replicate those scenarios.
Closes#14626
This is basically just like #14064, but with the `theme` instead.
If you define a pair of `theme` names:
```json
"theme": { "dark": "light", "light": "dark" },
```
then the Terminal will use the one relevant for the current OS theme. This cooperates with #14064, who sets the `scheme` based on the app's theme.
This was spec'd as a part of #3327 / #12530, but never promoted to its own issue.
Gif below.
In order to modify the accessibility information for the PseudoConsoleWindow, it needs to have a UIA provider registered. This PR introduces `PseudoConsoleWindowAccessibilityProvider` and registers it as a UIA provider appropriately. The registration process is based on that of the `WindowUiaProvider` for ConHost.
Closes#14385
## Validation Steps Performed
Run Accessibility Insights FastPass on the window. The PseudoConsoleWindow no longer is tagged as missing a name.
Depending on the line rendition, and whether the cursor is over a wide
character or not, it's possible for the width to take up anywhere from 1
to 4 cells. And when it's more than 1 cell wide, part of the cursor may
end up off screen. However, our bounds check requires the entire cursor
to be on screen, otherwise it doesn't render anything, and that can
result in cursor droppings being left behind. This PR fixes that.
The bounds check that is causing this issue was introduced in #13001 to
fix a debug assertion.
To fix this, I've removed the bounds checking, and instead clip the
cursor rect to the boundaries of the viewport. This is what the original
code was trying to do prior to the #13001 fix, but was mistakenly using
the `Viewport:Clamp` method, instead of `TrimToViewport`. Since this
implementation doesn't require a clamp, there should be no risk of the
debug assertion returning.
## Validation Steps Performed
I've confirmed that the test case in #14657 is now working correctly,
and not leaving cursor droppings behind. I've also tested under conhost
with buffer sizes wider than the viewport, and confirmed it can handle a
wide cursor partially scrolled off screen.
Closes#14657
Grab all paths from `DROPFILES` struct provided in drag event data
`GetStorageItemsAsync()` only giving up to 16 items when items are dropped from any archives
- When this occurs, we should look into `FileDrop` key for a stream of the [`DROPFILES struct`](https://learn.microsoft.com/en-us/windows/win32/shell/clipboard#cf_hdrop)
- This struct contains a null-character delimited string of paths which we can just read out
## Validation Steps Performed
* [X] Unit tests pass locally
* [X] Drag and drop paths work for both archives and non-archives files, folders, shortcuts, etc.
Closes#14628
Fix access violation on lParam when constructing wstring.
Per the [WM_SETTINGSCHANGE docs], NULL is a valid value for lParam. A
null lParam was observed when using the 'Switch User' feature of Windows
while developing the Terminal app.
## Validation Steps Performed
Reproduced the scenario w/ the check in place and verified no crash.
Closes#14652
[WM_SETTINGSCHANGE docs]: https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-settingchange
`s/it's/its/`
Note that I didn't touch the several errors in the doc and doc/spec directories, since those seem to be dated and signed email excerpts, and I don't want to violate authorial integrity. Let me know if you would like me to fix those as well.
## References
p 57. Murray, L. (1824). English grammar. Philadelphia : E. T. Scott.
I skimmed several hundred usages of the word "it's" in the code. This actually wasn't as tiresome as it sounds, since many of the code comments in this repo are entertaining and educational — the adjectives do not _necessarily_ apply in that order, but do _possibly_ apply in that order.
<!-- 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 an additional optional parameter that indicates the position of the new tab being created.
https://user-images.githubusercontent.com/17508246/206831900-d8349fb6-4241-4c37-8dd8-e1645ba94c90.mp4https://user-images.githubusercontent.com/17508246/206831949-02e4156e-f471-4d2f-b54b-3b0d294c62fe.mp4
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#14313
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
<!-- 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
An optional parameter is added to TerminalPage::_CreateNewTabPane() and TerminalPage::_InitializeTab() which indicates the insert position of the duplicated tab.
During a new tab creation (not duplicate), this optional parameter has a default value(-1) and the new tab is inserted at the end.
The duplicated tab is inserted next to the original one even if it is not focused.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Created different tabs and duplicated them.
Duplicated tabs that are focused and not focused.
This PR replaces the uses of `Viewport::CompareInBounds()` in the UIA code with `til::point` comparators. Additionally, it simplifies the logic further by using `std::max` and `std::min`.
In doing so, we are no longer hitting the `assert` in `CompareInBounds()`.
Closes#14542
2 new ConPTY APIs were added as part of this commit:
* `ClosePseudoConsoleTimeout`
Complements `ClosePseudoConsole`, allowing users to override the `INFINITE`
wait for OpenConsole to exit with any arbitrary timeout, including 0.
* `ConptyReleasePseudoConsole`
This releases the `\Reference` handle held by the `HPCON`. While it makes
launching further PTY clients via `PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE`
impossible, it does allow conhost/OpenConsole to exit naturally once all
console clients have disconnected. This makes it unnecessary to having to
monitor the exit of the spawned shell/application, just to then call
`ClosePseudoConsole`, while carefully continuing to read from the output
pipe. Instead users can now just read from the output pipe until it is
closed, knowing for sure that no more data will come or clients connect.
This is especially useful in combination with `ClosePseudoConsoleTimeout`
and a timeout of 0, to allow conhost/OpenConsole to exit asynchronously.
These new APIs are used to fix an array of bugs around Windows Terminal exiting
either too early or too late. They also make usage of the ConPTY API simpler in
most situations (when spawning a single application and waiting for it to exit).
Depends on #13882, #14041, #14160, #14282Closes#4564Closes#14416
Closes MSFT-42244182
## Validation Steps Performed
* Calling `FreeConsole` in a handoff'd application closes the tab ✅
* Create a .bat file containing only `start /B cmd.exe`.
If WT stable is the default terminal the tab closes instantly ✅
With these changes included the tab stays open with a cmd.exe prompt ✅
* New ConPTY tests ✅
## Summary of the Pull Request
Performs some cleanup in the Settings UI for the Launch Parameters settings:
1. Updates all `NumberBox` controls in the Settings UI to have a `Compact` `SpinButtonPlacementMode` instead of an inline one. This alleviates the XAML bug where the spin button would appear over the number box's input value.
2. Fixes an issue where a long X/Y value would resize the settings controls weirdly. This was fixed by introducing a `Grid` inside the main grid and applying a width to the number boxes.
3. Rename "Use system default" checkbox to be more clear. Propagate the new localized string into expander preview.
Closes#14558
Similar to #14519.
Voice Access allows for functionality like "click <name>" to automatically move the cursor and click on a control. The Search Box had an AutoProp.Name that didn't match the button text, leading to confusion because Voice Access wouldn't be able to find a control named "Create".
To fix this, we simply aligned the button text and the AutoProp.Name.
Closes#13808
## Summary of the Pull Request
- [x] Clicking a color scheme in the list view immediately takes you to the page to edit the scheme
- [x] Adding a new scheme immediately takes you to the page to edit the new scheme
- [x] 'delete' and 'set as default' buttons have been moved to the edit scheme page
## PR Checklist
* [x] Closes#14289
* [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
## Validation Steps Performed
The schemes page still works, keyboard navigation also works
Voice Access allows for functionality like "click \<name\>" to automatically move the cursor and click on a control. The Search Box had an AutoProp.Name that didn't match the placeholder text, leading to confusion because Voice Access wouldn't be able to find a control named "Find...".
To fix this, we simply aligned the placeholder text and the AutoProp.Name to be "Find". The elipses were removed because no dialog is opened.
The fix was accomplished in two ways to ensure that this is backportable:
1. via code, directly set the AutoProp.Name to match the placeholder text.
2. in the resources file, explicitly match the AutoProp.Name to the placeholder text. This allows this change to be backportable in the event that the code above wasn't backported.
Closes#14398
### ⇒ [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}`
We originally needed this library (or a separate DLL in our own project)
to handle hooking up the XAML resource loader to the providers that our
application needed. It was introduced in its nascent form in 2019, in a
PR titled "Make XAML files work."
It appears we no longer need it, and the provider hookup is being
handled by our `AppT2` base class override. I've tested this in Windows
10 Vb running unpackaged, and it seems to work totally fine. Crazy.
Removing this dependency saves us a couple hundred kilobytes on disk and
removes one consumer of the App CRT from our package.
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
This PR adds a new dynamic profile generator which creates profiles to
quickly connect to detected SSH hosts.
This PR adds a new `SshHostGenerator` inbox dynamic profile generator.
When run, it looks for an install of our
[Win32-OpenSSH](https://github.com/PowerShell/Win32-OpenSSH) client app
`ssh.exe` in all of the (official) places it gets installed. If the exe
is found, the generator then looks for and parses both the user and
system OpenSSH config files for valid SSH hosts. Each host is then
converted into a profiles to call `ssh.exe` and connect to those hosts.
VALIDATION
Installed OpenSSH, configured host for alt.org NetHack server, connected
and played some NetHack from the created profile.
* [x] When OpenSSH is not installed, don't add profiles
* [x] Detected when installed via Optional Features (installs in
`System32\OpenSSH`, added to PATH)
* [x] Detected when installed via the 32-Bit OpenSSH MSI from GitHub
(installs in `Program Files (x86)\OpenSSH`, not added to PATH)
* [x] Detected when installed via the 64-Bit OpenSSH MSI from GitHub
(installs in `Program Files\OpenSSH`, not added to PATH)
* [x] Detected when installed via `winget install
Microsoft.OpenSSH.Beta` (uses MSI from GitHub)
* [x] With `"disabledProfileSources": ["Windows.Terminal.SSH"]` the
profiles are not generated
Closes#9031
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
Closes https://github.com/microsoft/terminal/issues/9031
We couldn't do this before, because `App::Current().Resources().Lookup()` would always return the OS theme version of a resource. That thread has lengthy details on why.
FORTUNATELY FOR US, this isn't the first time we've dealt with this. We've come up with a workaround in the past, and we can just use it again here.
Closes#3917
This will also make #3061 easy 😉
## Summary of the Pull Request
This PR adds support for the DEC macro operations `DECDMAC` (Define Macro), and `DECINVM` (Invoke Macro), which allow an application to define a sequence of characters as a macro, and then later invoke that macro to execute the content as if it had just been received from the host.
This PR also adds two new `DSR` queries: one for reporting the available space remaining in the macro buffer (`DECMSR`), and another reporting a checksum of the macros that are currently defined (`DECCKSR`).
## PR Checklist
* [x] Closes#14205
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
I've created a separate `MacroBuffer` class to handle the parsing and storage of macros, so the `AdaptDispatch` class doesn't have to do much more than delegate the macro operations to that.
The one complication is the macro invocation, which requires injecting characters back into the state machine's input stream. Ideally we'd just pass the content to the `ProcessString` method, but we can't do that when it's already in the middle of a `CSI` dispatch.
My solution for this was to add an `OnCsiComplete` method via which we could register a callback function that injects the macro sequence only once the state machine has returned to the ground state. This feels a bit hacky, but that was the best approach I could come up with.
## Validation Steps Performed
Thanks to @KalleOlaviNiemitalo, we've been able to do some testing on a real VT420 to determine how the macro operations are intended to work, and I've tried to get our implementation to match that behavior as much as possible (we differ in some aspects of the checksum reporting, where the VT420 behavior seemed undesirable, or potentially buggy).
I've also added unit tests covering some of the same scenarios that we tested on the VT420.
This reverts commit 19b6d35.
This re-enables support for Mica, and transparent titlebars in general. It also syncs the titlebar opacity with the control opacity for `terminalBackground`. It also somehow fixes the bug where the bottom few pixels of the max btn doesn't work to trigger the snap flyout.
Closes#10509
Does nothing for #13631
### To-done's
* [x] Check the mica API on 22000, windows 11 RTM
- this works on 10.0.22621.674, but that's not 22000
* [x] Check how this behaves on windows 10.
- For both, this API just no-ops. That's fine! we can just say "Mica is only supported on >=22621"
This changeset includes various guards against resizing the terminal down to 0
columns/rows: The 2 `TextBuffer` locations that accept new sizes, as well as
the `HwndTerminal::Refresh` which was the entrypoint causing the issue.
Closes#14404
## Summary of the Pull Request
This change should have been a part of #14190 but was missed.
## PR Checklist
* [x] Closes#14469
* [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
## Validation Steps Performed
Setting launch position in the settings UI works now
## Summary of the Pull Request
Watson reports show that Visual Studio terminal attempts to render a string that is null causing the renderer to crash.
More specifically, we see "NULL_POINTER_WRITE_c0000005_PublicTerminalCore.dll!TextBuffer::WriteLine" with the following stack:
PublicTerminalCore!TextBuffer::WriteLine+0x1da
PublicTerminalCore!TextBuffer::Write+0x191
PublicTerminalCore!Microsoft::Terminal::Core::Terminal::_WriteBuffer+0x1d3
PublicTerminalCore!Microsoft::Terminal::Core::Terminal::PrintString+0x9
PublicTerminalCore!TerminalDispatch::PrintString+0x22
PublicTerminalCore!Microsoft::Console::VirtualTerminal::OutputStateMachineEngine::ActionPrintString+0x42
PublicTerminalCore!Microsoft::Console::VirtualTerminal::StateMachine::ProcessString+0x123
PublicTerminalCore!TerminalSendOutput+0x68
Microsoft_DotNet_MSBuildSdkResolver!DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, System.String)+0x8f
Microsoft_Terminal_Wpf!Microsoft.Terminal.Wpf.TerminalContainer.Connection_TerminalOutput(System.Object, Microsoft.Terminal.Wpf.TerminalOutputEventArgs)+0x20
Microsoft_VisualStudio_Terminal_Implementation!Microsoft.VisualStudio.Terminal.TerminalWindowBase+<>c__DisplayClass59_0+<<BeginProcessingPtyData>b__0>d.MoveNext()+0x55f
## References
Internal bug: [Bug 1614709](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1614709): [Watson] crash64: NULL_POINTER_WRITE_c0000005_PublicTerminalCore.dll!TextBuffer::WriteLine
## Detailed Description of the Pull Request / Additional comments
Added a null check before PInvoking TerminalSendOutput.
## Validation Steps Performed
Validated locally that the check prevents null strings from rendering.
When a terminal process exits (successful or not) and the profile isn't
set to automatically close the pane, a new message is displayed:
You can now close this terminal with ^D or Enter to restart.
Ctrl+D then is able to close the pane and Enter restarts it.
I originally tried to do this at the ConptyConnection layer by changing
the connection state from Failed to Closed, but then that didn't work
for the case where the process exited successfully but the profile isn't
set to exit automatically. So, I added an event to
ControlCore/TermControl that Pane watches. ControlCore watches to see if
the input is Ctrl+D (0x4) and if the connection is closed or failed, and
then raises the event so that Pane can close itself. As it turned out, I
think this is the better place to have the logic to watch for the Ctrl+D
key. Doing it at the ConptyConnection layer meant I had to parse out the
key from the escaped text passed to ConptyConnection::WriteInput.
## Validation Steps Performed
Tried adding lots of panes and then killing the processes outside of
Terminal. Each showed the new message and I could close them with Ctrl+D
or restart them with Enter. Also set a profile to never close
automatically to make sure Ctrl+D would work when a process exits
successfully.
Closes#12849Closes#11570Closes#4379
<!-- 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.
My goal is to make `IRenderData` "snapshottable", so that we
can render a frame of text without holding the console lock.
To facilitate this, this commit merges our 3 data interfaces
into one. It includes no actual changes apart from renames.
This commit is just a slight refactor of `ConsoleProcessList` which I've noticed
was in a poor shape. It replaces iterators with for-range loops, etc.
Additionally this fixes a bug in `SetConsoleWindowOwner`, where it used to
default to the newest client process instead of the oldest.
Finally, it changes the process container type from a doubly linked list
over to a simple array/vector, because using linked lists for heap allocated
elements felt quite a bit silly. To preserve the previous behavior of
`GetProcessList`, it simply iterates through the vector backwards.
## Validation Steps Performed
* All unit/feature tests pass ✅
* Launching a TUI application inside pwsh inside cmd
and exiting kills all 3 applications ✅
This changeset consists of two parts:
* Refactor `PtySignalInputThread` to move more code from `_InputThread`
into the various `_Do*` handlers. This allows us to precisely control
console locking behavior which is the cause of this bug.
* Add the 1-line fix to `_DoSetWindowParent` to unlock the console before
calling foreign functions (`SetWindowLongPtrW` in this case).
This fix is theoretical in nature, based on a memory dump from an affected user
and most likely fixes: https://developercommunity.visualstudio.com/t/10199439
## Validation Steps Performed
* ConPTY tests complete. ✅
My long-term plan is to replace the `CodepointWidth` enum with a simple integer
return value that indicates the amount of columns a codepoint is wide.
This is necessary so that we can return 0 for ZWJs (zero width joiners).
This initial commit represents a cleanup effort around `CodepointWidthDetector`.
Since less code runs faster, this change has the nice side-effect of running
roughly 5-10% faster across the board. It also drops the binary size by ~1.2kB.
## Validation Steps Performed
* `CodepointWidthDetectorTests` passes ✅
* U+26bf (``"`u{26bf}"`` inside pwsh) is a wide glyph
in OpenConsole and narrow one in Windows Terminal ✅
This is a partial fix for the Get-Credential issue. While investigating it, I found that the pseudoconsole window is not marked as being "owned" (in NTUSER) by the PID/TID of the console application that is "hosted" "in" it. Doing this does not (and cannot) fix `Get-Credential` failing in DefTerm scenarios.
ConsoleSetWindowOwner is one of the operations that can be done by a conhost to any window, and so the RemoteConsoleControl can call through to the Win32 ConsoleControl to pull it off.
I chose to add SetWindowOwner to the IConsoleControl interface instead of moving ConsoleControl::Control into the interface to reduce the amount of churn and better separate interface responsibilities.
References #14119
As noted in #11000.
This adds support for `FTCS_COMMAND_START`, `FTCS_COMMAND_EXECUTED` and `FTCS_COMMAND_FINISHED`, which allow a shell to more clearly markup parts of the buffer.
As a trick, I'm also making the `experimental.autoMarkPrompts` setting act like a `FTCS_COMMAND_EXECUTED` if it comes after a `FTCS_COMMAND_START`. This lets the whole sequence work for cmd.exe (which wouldn't otherwise be possible).
* My cmd prompt
```bat
PROMPT $e]133;D$e\$e]133;A$e\$e]9;9;$P$e\[$T]$e[97;46m%_seperator%$P$e[36;49m%_seperator%$e[0m$_$e[0m%_GITPROMPT%$e[94m%username%$e[0m@$e[32m%computername%$e[0m$G$e]133;B$e\
```
* pwsh profile, heavily cribbed from vscode
```pwsh
$Global:__LastHistoryId = -1
function Global:__Terminal-Get-LastExitCode {
if ($? -eq $True) {
return 0
}
# TODO: Should we just return a string instead?
# return -1
if ("$LastExitCode" -ne "") { return $LastExitCode }
return -1
}
function prompt {
# $gle = $LastExitCode
$gle = $(__Terminal-Get-LastExitCode);
$LastHistoryEntry = $(Get-History -Count 1)
# Skip finishing the command if the first command has not yet started
if ($Global:__LastHistoryId -ne -1) {
if ($LastHistoryEntry.Id -eq $Global:__LastHistoryId) {
# Don't provide a command line or exit code if there was no history entry (eg. ctrl+c, enter on no command)
$out += "`e]133;D`a"
} else {
# Command finished exit code
# OSC 633 ; D [; <ExitCode>] ST
$out += "`e]133;D;$gle`a"
}
}
$loc = $($executionContext.SessionState.Path.CurrentLocation);
# IMPORTANT: Make sure there's a printable charater _last_ in the prompt.
# Otherwise, PSReadline is gonna use the terminating `\` here and colorize
# that if it detects a syntax error
$out += "`e]133;A$([char]07)";
$out += "`e]9;9;`"$loc`"$([char]07)";
$out += "PWSH $loc$('>' * ($nestedPromptLevel + 1)) ";
$out += "`e]133;B$([char]07)";
$Global:__LastHistoryId = $LastHistoryEntry.Id
return $out
}
```
* Doesn't close any issues, because this was always just an element in #11000
* I work here
* From FHL code
This is a follow-up of #13025 to make the members of `til::point/size/rect`
uniform and consistent without the use of `unions`. The only file that has
any changes is `src/host/getset.cpp` where an if condition was simplified.
## Validation Steps Performed
* Host unit tests ✅
* Host feature tests ✅
* ControlCore feature tests ✅
This PR adds support for the `DECRQM` (Request Mode) escape sequence,
which allows applications to query the state of the various modes
supported by the terminal. It also adds support for the `DECNKM` mode,
which aliases the existing `DECKPAM` and `DECKPNM` operations, so they
can be queried with `DECRQM` too.
This is one solution for #10153 (saving and restoring the state of
bracketed paste mode), and should also help with #1040 (providing a way
for clients to determine the capabilities of the terminal).
Prior to adding `DECRQM`, I also did some refactoring of the mode
handling to get rid of the mode setting methods in the `ITermDispatch`
interface that had no need to be there. Most of them were essentially a
single line of code that could easily be executed directly from the
`_ModeParamsHelper` handler anyway.
As part of this refactoring I combined all the internal `AdaptDispatch`
modes into an `enumset` to allow for easier management, and made sure
all modes were correctly reset in the `HardReset` method (prior to this,
there were a number of modes that we weren't restoring when we should
have been).
And note that there are some differences in behavior between conhost and
Windows Terminal. In conhost, `DECRQM` will report bracketed paste mode
as unsupported, and in Terminal, both `DECCOLM` and `AllowDECCOLM` are
reported as unsupported. And `DECCOLM` is now explicitly ignored in
conpty mode, to avoid the conpty client and conhost getting out of sync.
## Validation Steps Performed
I've manually confirmed that all the supported modes are reported in the
`DECRQM` tests in Vttest, and I have my own test scripts which I've used
to confirm that `RIS` is now resetting the modes correctly.
I've also added a unit test in `AdapterTest` that iterates through the
modes, checking the responses from `DECRQM` for both the set and reset
states.
I should also mention that I had to do some refactoring of the existing
tests to compensate for methods that were removed from `ITermDispatch`,
particularly in `OutputEngineTest`. In many cases, though, these tests
weren't doing much more than testing the test framework.
I originally added these platforms to prevent the .NET components from
building when you built the entire solution, and to prevent them from
building in CI.
It turns out that managing an extra thousand project-platform-config
triples is an absolute pain, **and** that we should have been building
these things in CI the entire time. So.
This should make life _a lot_ easier.
As a bonus, this PR enables the WPF test harness to build for ARM64.
This fixes two issues with `experimental.useBackgroundImageForWindow` I discovered while looking at #14260
* It looks like the opacity of the whole-window BG image wouldn't hot reload if the path didn't.
* > set useBGForWindow:true, focus a pane with an image, then set it to useBGForWindow:false, and observe a pane with <100 opacity. You'll be able to see the BG image left behind!
These are pretty easy to miss, so I can see how it happened.
I don't think this _technically_ closes that thread, though. Ultimately, I think OP's settings were just wrong (and possible didn't hot-reload). There's another, trickier bit I'm discussing in that thread, that might deserve its own separate follow-up for discussion.
#14160 didn't fix#14132 entirely. There seems to be a race condition left
where (on my system) 9 out of 10 times everything works correctly,
but sometimes OpenConsole exits, while pwsh and bash keep running.
My leading theory is that the new code is exiting OpenConsole faster than the
old code. This prevents clients from calling console APIs, etc. causing them
to get stuck. The old code (and new code) calls `ExitProcess` when the ConPTY
pipes break and I think this is wrong: In conhost when you close the window we
only call `CloseConsoleProcessState` via the `WM_CLOSE` event and that's it.
Solution: Remove the call to `RundownAndExit` for ConPTY.
During testing I found that continuously printing text inside msys2 will cause
child processes to only exit slowly one by one every 5 seconds.
This happens because `CloseConsoleProcessState` calls `HandleCtrlEvent` without
holding the console lock. This creates a race condition where most of the time
the console IO thread is the one picking up the `CTRL_CLOSE_EVENT`. But that's
problematic because the `CTRL_CLOSE_EVENT` leads to a `ConsoleControl` call of
type `ConsoleEndTask` which calls back into conhost's IO thread and
so you got the IO thread waiting on itself to respond.
Solution: Don't race conditions.
## Validation Steps Performed
* `Enter-VsDevShell` and close the tab
Everything exits after 5s ✅
* Run msys2 bash from within pwsh and close the tab
Everything exits instantly ✅
* Run `cat bigfile.txt` and close the tab
Everything exits instantly ✅
* Patch `conhost.exe` with `sfpcopy`, as well as `KernelBase.dll`
with the recent changes to `winconpty`, then launch and exit
shells and applications via VS Code's terminal ✅
* On the main branch without this modification remove the call to
`TriggerTeardown` in `RundownAndExit` (this speeds up the shutdown).
Run (msys2's) `bash.exe --login` and hold enter and then press Ctrl+Shift+W
simultaneously. The tab should close and randomly OpenConsole should exit
early while pwsh/bash keep running. Then retry this with this branch and
observe how the child processes don't stick around forever anymore. ✅
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
This commit replaces `Utf16Parser` with `<til/unicode.h>` which includes:
* `til::utf16_iterator` as a replacement for `Utf16Parser::Parse`
* `til::utf16_next` as a replacement for `Utf16Parser::ParseNext`
This fixes 2 bugs with `Utf16Parser`:
* Swallowing invalid surrogate pairs instead of turning them into U+FFFD.
* `std::vector<std::vector<wchar_t>>`. It's now >12000% faster.
## Validation Steps Performed
* New unit tests pass ✅
* Searching for narrow/wide characters in conhost works ✅
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
Commits mentioned in this file will be acknowledged by GitHub, but
skipped in the blame view. Other tools use this as well.
You can make git use it by passing
`--ignore-revs-file .git-blame-ignore-revs` to `git blame`.
The only commits we're ignoring right now are codebase-wide reformatting
or line endings changes.
## Summary of the Pull Request
Ensures that reading the buffer content actually returns the content.
## References
Regressed in #13626.
## PR Checklist
* [x] Closes#14378
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
## Validation Steps Performed
Added a test.
This commit is a from-scratch rewrite of `ROW` with the primary goal to get
rid of the rather bodgy `UnicodeStorage` class and improve Unicode support.
Previously a 120x9001 terminal buffer would store a vector of 9001 `ROW`s
where each `ROW` stored exactly 120 `wchar_t`. Glyphs exceeding their
allocated space would be stored in the `UnicodeStorage` which was basically
a `hashmap<Coordinate, String>`. Iterating over the text in a `ROW` would
require us to check each glyph and fetch it from the map conditionally.
On newlines we'd have to invalidate all map entries that are now gone,
so for every invalidated `ROW` we'd iterate through all glyphs again and if
a single one was stored in `UnicodeStorage`, we'd then iterate through the
entire hashmap to remove all coordinates that were residing on that `ROW`.
All in all, this wasn't the most robust nor performant code.
The new implementation is simple (from a design perspective):
Store all text in a `ROW` in a regular string. Grow the string if needed.
The association between columns and text works by storing character offsets
in a column-wide array. This algorithm is <100 LOC and removes ~1000.
As an aside this PR does a few more things that go hand in hand:
* Remove most of `ROW` helper classes, which aren't needed anymore.
* Allocate backing memory in a single `VirtualAlloc` call.
* Rewrite `IsCursorDoubleWidth` to use `DbcsAttrAt` directly.
Improves overall performance by 10-20% and makes this implementation
faster than the previous NxM storage, despite the added complexity.
Part of #8000
## Validation Steps Performed
* Existing and new unit and feature tests complete ✅
* Printing Unicode completes without crashing ✅
* Resizing works without crashing ✅
## Summary of the Pull Request
This PR adds support for the rectangular area escape sequences:
`DECCRA`, `DECFRA`, `DECERA`, `DECSERA`, `DECCARA`, `DECRARA`, and
`DECSACE`. They provide VT applications with an efficient way to copy,
fill, erase, or change the attributes in a rectangular area of the
screen.
## PR Checklist
* [x] Closes#14112
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #14112
## Detailed Description of the Pull Request / Additional comments
All of these operations take a rectangle, defined by four coordinates.
These need to have defaults applied, potentially need to be clipped
and/or clamped within the active margins, and finally converted to
absolute buffer coordinates. To avoid having to repeat that boilerplate
code everywhere, I've pulled that functionality out into a shared method
which they all use.
With that out of the way, operations like `DECFRA` (fill), `DECERA`
(erase), and `DECSERA` (selective erase) are fairly simple. They're just
filling the given rectangle using the existing methods `_FillRect` and
`_SelectiveEraseRect`. `DECCRA` (copy) is a little more work, because we
didn't have existing code for that in `AdaptDispatch`, but it's mostly
just cloned from the conhost `_CopyRectangle` function.
The `DECCARA` (change attributes) and `DECRARA` (reverse attributes)
operations are different though. Their coordinates can be interpreted as
either a rectangle, or a stream of character positions (determined by
the `DECSACE` escape sequence), and they both deal with attribute
manipulation of the target area. So again I've pulled out that common
functionality into some shared methods.
They both also take a list of `SGR` options which define the attribute
changes that they need to apply to the target area. To parse that data,
I've had to refactor the `SGR` decoder from the `SetGraphicsRendition`
method so it could be used with a given `TextAttribute` instance instead
of just modifying the active attributes.
The way that works in `DECCARA`, we apply the `SGR` options to two
`TextAttribute` instances - one with all rendition bits on, and one with
all off - producing a pair of bit masks. Then by `AND`ing the target
attributes with the first bit mask, and `OR`ing them with the second, we
can efficiently achieve the same effect as if we'd applied each `SGR`
option to our target cells one by one.
In the case of `DECRARA`, we only need to create a single bit mask to
achieve the "reverse attribute" effect. That bit mask is applied to the
target cells with an `XOR` operation.
## Validation Steps Performed
Thanks to @KalleOlaviNiemitalo, we've been able to run a series of tests
on a real VT420, so we have a good idea of how these ops are intended to
work. Our implementation does a reasonably good job of matching that
behavior, but we don't yet support paging, so we don't have the `DECCRA`
ability to copy between pages, and we also don't have the concept of
"unoccupied" cells, so we can't support that aspect of the streaming
operations.
It's also worth mentioning that the VT420 doesn't have colors, so we
can't be sure exactly how they are meant to interpreted. However, based
on the way the other attribute are handled, and what we know from the
DEC STD 070 documentation, I think it's fair to assume that our handling
of colors is also reasonable.
Prior to this PR, the conhost vertical scrollbar would be forced to be
visible whenever the "Disable Scroll-Forward" option was set. It was
assumed that it would be needed as soon as the current viewport was
filled, so it was better to start off visible and disabled.
When the viewport height and buffer height are the same, though, the
scrollbar is never needed, and conhost compensates for that by making
the window narrower. But since we were still forcing the scrollbar to be
visible, that would result in it overlapping content in the rightmost
columns.
This PR attempts to fix that issue by simply leaving the scrollbar to
decide the visibility itself. This is perhaps not as aesthetically
pleasing when it starts off hidden and then later becomes visible, but
that seems better than having it overlap the content.
I've manually confirmed this fixes the problem reported in issue #2449.
Closes#2449
## Summary of the Pull Request
Compiler was raising the error: `expression did not evaluate to a constant.`, causing the solution to fail when building. Removing this `constexpr` fixes it.
## 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
## Validation Steps Performed
Solution builds now
AuditMode was accidentally disabled in 1c6aa4d, around 2 years ago.
This should fix this issue and address all the warnings it now generates.
Related to #14129.
The following members were not initialized during construction:
* `CursorType _defaultCursorShape`
* `bool _suppressApplicationTitle`
* `bool _bracketedPasteMode`
* `size_t _hyperlinkPatternId`
* `SelectionExpansion _multiClickSelectionMode`
* `til::CoordType _scrollbackLines`
Unlike gcc and clang, MSVC is fairly tame when it comes to removing code
tainted by undefined behavior, so the most likely affect this had is that
we were reading uninitialized memory.
Related to #14129.
We already were setting the automation properties on the expander, however, we were not setting it on the content when an expander was present. This change applies the automation properties to both the expander and the child content (i.e. TextBox).
Closes#13827
There is a condition which causes the console host process (conhost.exe)
to crash with a `FAIL_FAST` in `WriteCharsLegacy`.
**_Repro Scenario:_** Two conditions need to be met for crash to happen:
1. The `ENABLE_PROCESSED_OUTPUT` console mode needs to be disabled. This
condition is met through the race condition, explained in the section
below.
2. We are printing a string where there is a full width character
(character that requires two spaces on the screen) being printed at
the edge of the console window. That is, we have one character space
available, and the character requires 2 spaces.
Running following script (attached to bug) causes a crash:
`for /l %%A in (0, 1, 10000) do start /B C:\test.bat`
The script `test.bat` repeatedly prints a console-width line
with a DBCS character that doesn't fit.
_**Race:**_ Normally, we get into `WriteCharsLegacy` with
`PROCESSED_OUTPUT` enabled. However, during the initialization of a new
CMD session, `cmd!ResetConsoleMode()` is called, which first sets the
output console mode to the value of `curOutputMode` (which is a static
variable initialized to 0) by calling `SetConsoleMode()`, before then
setting it to the desired output mode with processed output enabled:
```c++
void ResetConsoleMode( void )
{
static DWORD desOutMode = ENABLE_PROCESSED_OUTPUT | /* ... */;
SetConsoleMode(conOut, curOutputMode); // <------ sets console mode to 0, disabling processed output
if (GetConsoleMode(conOut, &curOutputMode)) {
if ((curOutputMode & desOutMode) != desOutMode) {
curOutputMode |= desOutMode;
if (!SetConsoleMode(conOut, curOutputMode) && /* ... */) // <----- enables processed output
```
If there is another instance of CMD that is producing output in between
these two `SetConsoleMode()` calls, then we may end up in
`WriteCharsLegacy` with processed output mode disabled.
This fix removes a `FAIL_FAST_IF` that checks for `PROCESSED_OUTPUT`
mode after the initial character processing loop.
Before RS5, this was an `ASSERT()`. This FAIL_FAST was added in RS5 in
PR !1794053 (which changed all `ASSERT`-likes to `FAIL_FAST_IF`.)
We believe this assertion guarded only the "processing" of Backspace,
Tab, CR and LF, and did not expect that we would get out of the
character processing loop with unprocessed glyph characters. The
`FAIL_FAST` is redundant in this case, as the handlers for the
Backspace, Tab, CR and LF characters we are already checking for
`PROCESSED_OUTPUT`. Therefore, it is safe to remove this `FAIL_FAST`.
It turns out that we *can* exit the loop with unprocessed glyph
characters. In these cases, we don't want to `FAIL_FAST`.
# Validation
* Basic sanity testing to confirm strings are correctly being printed.
* Repro scenario script no longer crashes conhost.exe
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 eb5d8064dc0f09d8be92efb5e6efa69983f30a3f
Related work items: MSFT-42055103
`TextBuffer` is buggy and allows a `Trailing` `DbcsAttribute` to be written
into the first column. Since other code then blindly assumes that there's a
preceding `Leading` character, we'll get called with a X coordinate of -1.
This issue will be fixed by #13626 and this commit fixes it in the meantime.
Additionally fixes an unimportant crash when the window height is 0px,
because it was annoying during testing and doesn't hurt to be fixed.
## Validation Steps Performed
* Run a stress test that prints random Unicode at random positions
* Resize the window furiously at the same time
* Doesn't crash / fail-fast ✅
XAML has an issue in windows 10 where `Width="*"` does not work properly
inside the `DataTemplate` for a `ListView`. Because of this, the color
scheme list view items looked very strange in windows 10 (see #14187).
Thanks to that, we thought up a few new designs for the color schemes
page and selected a new one that blends the color chips with a region
that shows the foreground and background color with the text preview.
Closes#14187
My hope with this commit is to make our code more robust against accidental
recursive locking, as well as making it easier to write code with confidence,
with only a slight performance trade-off.
## Validation Steps Performed
* Playing Pac Man music through MIDI ✅
* Windows Terminal runs happily ever after ✅
Silent MIDI notes can be used to seemingly deny a user's input for long
durations (multiple minutes). This commit improves the situation by ignoring
all DECPS sequences for a second when Ctrl+C/Ctrl+Break is pressed.
Additionally it fixes a regression introduced in 666c446:
When we close a tab we need to unblock/shutdown `MidiAudio` early,
so that `ConptyConnection::Close()` can run down as fast as possible.
## Validation Steps Performed
* In pwsh in Windows Terminal 1.16 run ``while ($True) { echo "`e[3;8;3,~" }``
* Ctrl+C doesn't do anything ❎
* Closing the tab doesn't do anything ❎
* With these modifications in Windows Terminal:
* Ctrl+C stops the output ✅
* Closing the tab completes instantly ✅
* With these modifications in OpenConsole:
* Ctrl+C stops the output ✅
* Closing the window completes instantly ✅
If the opacity is set to 100%, the background becomes solid instead of 'fully opaque acrylic'. If the opacity is below 100% the acrylic material is re-enabled (depending on the user's settings).
## Validation Steps Performed
I updated two unit tests to reflect the change in behavior and manually tested the transition from <100% opacity to 100% opacity (and vice versa) on win11.
Steps:
1. Start with 100% opacity and acrylic material enabled.
2. Decrease opacity and observe acrylic effect.
3. Increase opacity back to 100% and disable the acrylic effect.
4. Decrease opacity and notice that acrylic effect is no longer there.
Closes#12880
Lately I've been a bit concerned about issues resulting from b036cab enabling
`/fp:fast` throughout the entire project. This commit reverts that change and:
* Enables `/fp:contract` which defaults to off since VS 17.0
This re-enables FMA for floats on ARM64. Since this doesn't affect NANs, etc.
I don't expect any issues apart from a slight change in float accuracy.
* Introduces `TIL_FAST_MATH_BEGIN` with which `/fp:fast` can be selectively
enabled for code that benefits from it like `ColorFix.cpp`.
Without `TIL_FAST_MATH_BEGIN` `ColorFix` is about twice as slow
(which is actually very noticeable in real life).
This PR doesn't produce any noticeable performance regressions.
## Validation Steps Performed
* Patch `RenderSettings.hpp` to include `Mode::AlwaysDistinguishableColors`
* Run a color intense application in AtlasEngine and observe CPU usage
## Summary of the Pull Request
Allow exe/dll paths for the `Icon` setting
The exe/dll icon needs to work in all the following areas:
* [x] The tab
* [x] The navigation view item in the SUI
* [x] The new tab flyout
* [x] The command palette
## PR Checklist
* [x] Closes#1504
* [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 the command palette, we had to switch to using `ContentPresenter` because `IconSourceElement` cannot take in every type of icon we need to provide
## Validation Steps Performed
Setting "%SystemRoot%\System32\shell32.dll,214" as the icon for a profile works in all the cases listed above.
## Summary of the Pull Request
- Pipe the `ShowWindow` value through to `ConptyConnection`
- When `TerminalPage` receives the new connection, it checks the `ShowWindow` value and maximizes *IF* there were no other pre-existing tabs (in glomming mode, we don't want to maximize sessions that did not ask for it)
## References
#12154
## 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
This is just a temporary solution until we change our defterm handoff process. Because of the way the process currently works, we have no way of knowing that the connection has requested the window to be maximized until after we have already started a terminal session. This means that we have to manually maximize the window upon receiving the connection, instead of having the session _start_ maximized, as it probably should.
## Validation Steps Performed
`start /max python` with defterm enabled opens up python in a maximized WT window
The original implementation of the _Device Status Report_ sequence was
only capable of handling ANSI status queries. This PR adds the ability
to respond to private DEC queries as well.
To prove it's working as intended, I've also included support for the
DEC extended cursor position report (`DECXCPR`), which is essentially
the same as the ANSI cursor position report, but with an additional
parameter indicating the page number. Until we support paging, though,
that value is just hardcoded to 1.
## References
The method for distinguishing between ANSI options and the private DEC
options is based on the updates made to the `SM`/`RM` mode sequences in
PR #8469.
## Validation Steps Performed
I've added a couple of unit tests covering the `DECXCPR` report, and
also manually confirmed we now pass the _Extended Cursor-Position_ test
in vttest.
Closes#14206
[Git2Git] Merged PR 8017580: Emit traces to determine user opt-in status for Default-by-default
We already have tracing in the console host that tells us when a
console session was successfully handed off to a Terminal. However, that
doesn't provide us enough information about Windows' intent in doing
so--namely, (1) whether the user _wanted_ that handoff to happen, OR (2)
whether the user has opted out because they didn't want it to happen.
(1) looks like any other hand-off, which will pollute our statistics
(2) doesn't generate any messages, because we fail out of handoff before
logging a single thing.
This pull request adds new, better events.
The events look like this (in TVPP):
```
Microsoft.Windows.Console.Host ConsoleHandoffSessionStarted
handoffCLSID: {2eaca947-7f5f-4cfa-ba87-8f7fbeefbe69}
handoffTargetChosenByWindows: true
```
```
Microsoft.Windows.Console.Host ConsoleHandoffSessionStarted
handoffCLSID: {2eaca947-7f5f-4cfa-ba87-8f7fbeefbe69}
handoffTargetChosenByWindows: false
```
```
Microsoft.Windows.Console.Host ConsoleHandoffSessionStarted
handoffCLSID: {b23d10c0-e52e-411e-9d5b-c09fdf709c7d}
handoffTargetChosenByWindows: false
```
Cherry picked from !7583836
Cherry-picked from commit `26f311e2`.
Fixes MSFT-41943733
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 2c876875f24263409175e986102862eda4f09f32
## Summary of the Pull Request
This removes all of the redundant tooltips from the settings UI. Since all of the settings are added through the SettingsContainer, it's a pretty simple change.
Closes#14184
## Validation Steps Performed
- [X] hover over all settings in the settings UI
- [X] hover over all entries in the SUI nav view
This is just a quick drive-by improvement. Switching from double to float
roughly doubles performance on a contemporary x86 CPU with `/fp:fast`.
## Validation Steps Performed
* Patch `RenderSettings.hpp` to include `Mode::AlwaysDistinguishableColors`
* Run a color intense application in AtlasEngine and observe CPU usage
This pull request introduces a number of source files to ut_til/sources.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 35865f47ced9103b02b06a1eb8d43d26b420af99
Remove vestigial submodule entry
## References
#12778 removed the actual WIL submodule, but there was still an entry left in the `.gitmodules` file that was causing me confusion about an orphaned submodule directory I had in an old copy of the repo.
## Validation Steps Performed
- Official validation checks passed
- Build still works locally after a `git clean -fdx`
This regression was introduced in b3c9f01. Since `TermControl` is the XAML
object that owns its scrollbar and the scrollbar's `VisualStateManager`
a strong reference back to the `TermControl` results in a circular reference.
## Validation Steps Performed
* Set a breakpoint on `TermControl::~TermControl()`
* Breakpoint hits on tab close ✅
Updates the version of XamlStyler to one with support for .NET 6.0. The version used before this depended on .NET 3.1, [which goes out of support on 2022-12-13.](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core)
This shouldn't be controversial as .NET 6.0 is included with VS 2022, unlike .NET 3.1.
Override the center on launch setting when a position is specified on the commandline.
## Validation Steps Performed
1. Set center on launch in the SUI.
2. Run `wtd` - the new window is centered.
3. Run `wtd --pos 100,200` - the new window is positioned at (100,200).
Closes#14176
This commit makes the following improvements:
* Only adjust block characters that come from fallback fonts. This ensures
that the glyphs of the chosen font all look exactly as they were designed.
* When adjusting the size, use the fallback font's full block glyph U+2588
to determine the size that the given glyph should have.
Closes#14098
## Validation Steps Performed
* Print `UTF-8-demo.txt` in Consolas.
* All block glyphs look uniform. ✅
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
This pull request operates on the same theory as #14217, but at a lower
level. Carlos and I discovered that TerminalPage *already* has an
action-dispatching key preview handler, and that my implementation of
`IDirectKeyListener` handles focus-tree bubbling mostly correctly.
Because of that discovery, we learned we could move the
`IDirectKeyListener` into TerminalPage itself and not have to complicate
the SUI or the Command Palette with the DirectKey interface.
Validation:
When bound to Alt+Space, the system menu works in the command palette,
the settings UI, and in read-only panes.
Fixes#11970Closes#14217
Fixes MSFT-41390832
The way `DECARM` was initially implemented, we checked for repeated key
presses by matching the last recorded virtual key code, and used a 0 key
code to indicate that no key was pressed. This caused the VT query
responses to fail, because they generated key events with a 0 key code,
and that would end up being detected as a repeated key that should be
suppressed.
This PR fixes that issue by using a `std::optional` to track the last
key code, so if no key has been pressed we can represent that with
`std::nullopt`, and there's no way that can be confused with a genuine
key press.
The `DECARM` mode was introduced in PR #13981.
## Validation Steps Performed
I've manually tested in Vttest to confirm that the query reports are now
working again, even when `DECARM` is disabled. I've also checked that
`DECARM` itself it still working as expected.
Closes#14208
Problem:
* Calling `RundownAndExit` tries to flush out the last frame from `VtEngine`
* `VtEngine` indirectly calls `RundownAndExit` if the pipe is gone via `VtIo`
* `RundownAndExit` is called by other parts of OpenConsole
* `RundownAndExit` must be `[[noreturn]]` for most parts of OpenConsole
* `VtIo` itself has a mutex ensuring orderly shutdown
* In short, doing a thread safe orderly shutdown requires us to hold both,
a lock in `RundownAndExit` and `VtIo` at the same time, but while other parts
need a blocking `RundownAndExit`, `VtIo` needs a non-blocking one
* Refactoring the code to use optionally non-blocking `RundownAndExit`
requires refactoring and might prove to be just as buggy
Solution:
* Simply don't call `RundownAndExit` in `VtEngine` at all
* In case the write pipe breaks:
* `VtEngine` will close the handle
* The client should notice that their read pipe is broken and
close their write pipe sooner or later
* Once we notice that our read pipe is broken, we call `RundownAndExit`
* `RundownAndExit` might call back into `VtEngine` but
without a pipe it won't do anything
* In case the read pipe breaks or any other part calls `RundownAndExit`:
* We call `RundownAndExit`
* `RundownAndExit` might call back into `VtEngine` and depending on whether
the write pipe is broken or not it will simply write into it or ignore it
Closes#14132
Pretty sure this also applies to #1810
## Validation Steps Performed
* Open 5 tabs and run MSYS2's `bash --login` in each of them
* `Enter-VsDevShell` in another tab
* Close window
* 5 tab processes are killed instantly, 1 after ~3s ✅
* Replace conhost with OpenConsole via sfpcopy
* Launch Dozens of Git Bash tabs in VS Code
* Close them randomly
* Remaining ones still work, processes are gone ✅
c0b2f488c1
Unlike iTerm2, we're not planning on making it configurable.
This commit also adds a max length of 1024 characters on the "display URI" that we pass up to XAML, so as to not inundate the UI.
Fixes#14200
Since #13730 merged, when we parse LaunchPosition we treat the
coordinates as `int32_t`. This PR updates the actual `LaunchPosition`
struct to also use `int32_t` for consistency.
## Validation Steps Performed
Terminal still builds and runs
This pull request adds a couple `const` keywords, simplifies a bit of boolean logic,
adds the `static` keyword to `Commandline::IsEditLineEmpty`, and a couple more things.
Addressing post-hoc comments on the launch parameters expander in the SUI (added in #13605)
- Use more contextually appropriate strings (`Centered` instead of `On` / `Off`)
- Don't emit an extra `NotifyChanges`
References #13605
Instead of using the currently focused tab when an unfocused tab is duplicated, the `_MakePane(...)` function now uses an optional source tab argument that points to the correct tab being duplicated.
## Validation Steps Performed
Manually tested on multiple tabs with different profiles. Performed steps:
* Construct at least two tabs with different profiles.
* Select `Duplicate Tab` option from the dropdown menu of the unfocused tab.
* Verify that the new tab has the same profile as the tab it was duplicated from.
Closes#13942
The breadcrumbs in the SUI were not readable by screen readers because they are represented as a button with a text block inside of it. Turns out, if you make the DataTemplate's item `IStringable` (meaning it has a `ToString()`), it all magically works! Allowing the screen reader to read the button as text.
Closes#13826
This PR adds support for the `DECARM` (Auto Repeat Mode) sequence, which
controls whether a keypress automatically repeats if you keep it held
down for long enough.
Note that this won't fully work in Windows Terminal until issue #8440 is
resolved.
Every time we receive a `KeyDown` event, we record the virtual key code
to track that as the last key pressed. If we receive a `KeyUp` event the
matches that last key code, we reset that field. Then if the Auto Repeat
Mode is reset, and we receive a `KeyDown` event that matches the last
key code, we simply ignore it.
## Validation Steps Performed
I've manually tested the `DECARM` functionality in Vttest and confirmed
that it's working as expected. Although note that in Windows Terminal
this only applies to non-alphanumeric keys for now (e.g. Tab, BackSpace,
arrow keys, etc.)
I've also added a basic unit test that verifies that repeated key
presses are suppressed when the `DECARM` mode is disabled.
Closes#13919
It turns out that the negative margin for the progress ring is causing
the clipping in case the tab title gets too long:
43dbbd590f/src/cascadia/TerminalApp/TabHeaderControl.xaml (L18-L27)
The negative margin was introduced in #8113 because the progress ring is
supposed to replace the tab icon but the `TabView` still reserves space
even if no icon is set (see
https://github.com/microsoft/terminal/pull/8133#issuecomment-739098014).
However, it is not actually the `TabView` reserving space even when
there is no icon, but a workaround for a crash in the
`IconPathConverter` that returns a `BitmapIconSource` with a `nullptr`
source instead of a `nullptr` `IconSource`:
43dbbd590f/src/cascadia/TerminalSettingsModel/IconPathConverter.cpp (L143-L154)
The workaround in `IconPathConverter` could probably be removed as I did
not find any instance where it is still used in a way that could trigger
the mentioned crash, but I did not dare to just remove it as I do not
know enough about the code by far. Hence, I opted to just locally
instantiate the `IconSource` with a `nullptr` directly in `TerminalTab`.
Fixes#8910
This PR adds support for the selective erase escape sequences: `DECSED`,
`DECSEL`, and `DECSCA`. They provide a way of marking certain areas of
the screen as "protected", so you can erase the content everywhere else
without affecting those protected areas.
This adds another bit in the `CharacterAttributes` enum to track the
protected status of each cell, and an operation triggered by the
`DECSCA` sequence which can toggle that bit in the active attributes.
There there are two new erase operations triggered by the `DECSED` and
`DECSEL` sequences, which work similar to the existing `ED` (erase in
display) and `EL` (erase in line) operations, but which only apply to
unprotected cells.
I've also updated the `DECRQSS` settings request, so you can query the
active protected attribute status.
## Validation Steps Performed
I've manually confirmed that we pass the selective erase tests in Vttest
now, and I've also manually tested some more complicated edge cases and
confirmed that we match the behavior of the hardware VT240 emulator in
MAME.
For unit testing I've extended the existing erase tests to cover
selective erase as an additional option, I've added a test covering the
`DECSCA` sequence, and I've extended the `DECRQSS` adapter test to
confirm the attribute reporting is working.
Closes#14029
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 ✅
Adds UIA events to the WPF control for the following items:
- selection changed
- text changed (and output)
- cursor changed
### Automation Peer
Similar to the architecture of the UWP TermControl, we added a
`HwndTerminalAutomationPeer` which acts as the
`TermControlAutomationPeer` in UWP. However, we don't need a XAML
wrapper here, so really we just need it to inherit from
`TermControlUiaProvider` (the `ITextProvider` implementation shared
across conhost and WT) and `IUiaEventDispatcher` (the event dispatching
interface that is responsible for signaling the screen reader that
something has changed).
### Removing the local echo
As with WT, we need to record key events to remove the local echo. These
recorded events are matched up with the output text. Each sequential
match is removed in the output text so that it's not read by the screen
reader.
### Detecting what to send events for
As with WT, a `UiaEngine` was added to the renderer and it is set up
when a UIA client is detected. WT would normally stop sending events
when focus was lost from the control. We do the same here.
### Automation properties
`TermControlUiaProvider` was upgraded to support property values. Such
properties include class name and control type. These align with those
set in `TermControlAutomationPeer`. Realistically, those should point to
these, but that requires a lot more work and a localization burden
(because we need to move the localized word "terminal").
`HwndTerminalAutomationPeer` takes this a step further and overrides the
class name to be `WPFTermControl`. This allows screen readers to provide
special handling for the `WPFTermControl` vs the UWP term control since
they will be updating at different speeds.
### Build fixes
To build the WPF test app, I had to mess with the dependencies a little
bit. Really just add the atlas engine and uia renderer to the build
steps.
### HwndTerminal initialization
The initialization order with `WM_NCCREATE` was changed to match that of
Windows Terminal (BaseWindow/IslandWindow). This is safer now. I also
removed the `static` window because it was unnecessary.
### Handling `WM_GETOBJECT`
WPF's HwndHost likes to mark the `WM_GETOBJECT` message as handled to
force the usage of the WPF automation peer. We now explicitly mark it as
not handled and don't return an automation peer. This forces the message
to go down to the HwndTerminal where we return terminal's UiaProvider.
### Remove TermControl layer from UIA tree
TermContol (the top-most layer in the UIA tree) would pop up and not do
anything. This PR also overrides the automation peer at that layer and
marks IsContentElement/IsControlElement=false (the equivalent to
AccessibilityView=Raw). This makes the layer only appear in the UIA tree
if you are using the raw view (i.e. you know what you're doing and you
want to see each individual layer even if you can't directly interact
with it).
## Validation Steps Performed
Tested with Narrator/NVDA using WpfTerminalTestNetCore project in our
repo.
- [X] New output is read out (not just key events, but also other output
text)
- [X] Local echo does not occur (i.e. pressing 'A' should only read 'A'
once, not twice [key event and rendered letter]).
- [X] selection events are read out properly
- [X] cursor change events are read out properly (tested with text
cursor indicator preview in Settings App > Accessibility > Text
Cursor)
NOTE: test this with Release builds. Debug builds may be too slow and
not read out properly
Closes#12642
## Summary of the Pull Request
`InitialPosition` and `CenterOnLaunch` can now be edited in the SUI
## PR Checklist
* [x] Closes#9075
* [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
`InitialPosition` follows the same style as `LaunchSize`, with a number box for the x coordinate and a number box for the y coordinate. When there is no value for either of these coordinates, the respective number box is empty (and displays the text `Undefined`).
## Validation Steps Performed
They work
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Update Nuget used
This change fixes issues with certain fonts that draw _way_ outside the advance
width/height black box and expect to remain centered on the baseline.
## Validation Steps Performed
* Use MesloLGM Nerd Font
* Print U+E0B0
* Ensure it's centered, even if it's cut off ✅
if the bot adds it, then the issue will get added to the project before the bot gets a chance to add the triage label. Just start with the triage label.
This commit changes the glyph scale algorithm to prefer aligning glyphs to
their baseline. This improves the visual appearance of simulated italic glyphs.
However wide Emojis in narrow cells now look slightly worse without centering.
Closes#13987
## Validation Steps Performed
* Use FiraCode which has no italic variant and instead uses simulated italics
* Write italic text
* Baseline is consistent ✅
`ConptyClosePseudoConsole` blocks until OpenConsole exits.
This is problematic for the changes in 666c446, which stopped calling that
function on a background thread to solve a race condition. This commit fixes
the potential lags/deadlocks from waiting on OpenConsole's exit, by adding
`ConptyClosePseudoConsoleNoWait` which only closes the IO handles and allows
OpenConsole to exit naturally. This uncovered another potential deadlock
in `ServiceLocator::RundownAndExit` which might call itself recursively.
Closes#14032
## Validation Steps Performed
* Print tons of text and concurrently close the tab.
Tab closes, OpenConsole/pwsh exits instantly ✅
* Use `Enter-VsDevShell` and close the tab.
Tab closes instantly, OpenConsole/pwsh exits after ~5 seconds ✅
When we first introduced the shell extension, it didn't work properly
for some folders (such as the Desktop, or perhaps any "background"
click) due to a bug in Windows. We worked around that bug with the help
of an awesome community member, who contributed code that would pull up
the topmost Explorer window and query its location.
That Windows bug was eventually fixed, but we still had trouble with
items appearing correctly. On Windows 11, the Open in Terminal menu item
appears and disappears at random when you right-click the desktop, but
it always appears when you right-click a folder. It sometimes appears
for Quick Access, even though it shouldn't.
We tried to fix that in #13206, but the fix caused more issues than it
solved. We reverted it for 1.15 and 1.16.
At the end of the day, it turns out that getting the path from the
toplevel explorer window is fragile. Fortunately, the shell does offer
us a way to get that information: the site chain.
This pull request replaces GetPathFromExplorer() with an implementation
of `IObjectWithSite`, which allows us to use the site chain to look up
from whence a context menu request was initiated. It also makes item
lookup generally more robust.
* ✅ Tested on Windows 11
* ✅ Desktop
* ✅ Folder Background
* ✅ Folder Selected
* ✅ Quick Access (does not appear)
* ✅ This PC (does not appear)
* ✅ Tested on Windows 10
* ✅ Desktop
* ✅ Folder Background
* ✅ Folder Selected
* ✅ Quick Access (does not appear)
* ✅ This PC (does not appear)
References #13206
References #13523Closes#12578
Co-authored-by: John Lueders <johnlue@microsoft.com>
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
We're using this in UnicodeStorage!
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 828282c76d559ae2dbbee4288796a939e7f869f8
Related work items: MSFT-41396187
There's a different behavior regarding cursors between conhost and Windows
Terminal. In case of the latter we don't necessarily call `PaintCursor`
during cursor movement, because the cursor blinker never stops "blinking".
Closes#14028
## Validation Steps Performed
* Enter text until after the line wraps
* Hold backspace until the line unwraps
* No leftover cursor on the second line ✅
This fixes an issue with c51bb3a, where some fractional font
sizes are displayed as something like 13.600000000001.
Closes#14024
## Validation Steps Performed
* Enter a font size of 13.6 and save
* NumberBox displays "13.6" ✅
This PR attempts to simplify the `TextAttribute` class by merging the
two fields that were previously storing the "legacy" attributes and the
"extended" attributes separately.
When the `TextAttribute` class is initialized with a legacy value, we
were masking off the `META_ATTRS` bits to store in the `_wAttrLegacy`
field, and then additionally clearing the `COMMON_LVB_SBCSDBCS` bits,
so there were only 5 bits that were actually used in the end. We also
had an additional `_extendedAttrs` field holding other VT attributes,
which only used 8 of its available 16 bits.
In this PR I've now merged the the two sets of attributes into one enum,
so they all fit in a single 16-bit value. The legacy attributes retain
the same bit positions they originally had, so we can mask them off from
an incoming legacy value as we did before. I've just simplified the
process somewhat by creating a `USED_META_ATTRS` mask that covers the
exact subset of meta attributes that we care about.
The new enum that holds the combined attributes has now been named
`CharacterAttributes` rather than `ExtendedAttributes`, since that seems
to be the term typically used in VT documentation. This covers both
rendition/visual attributes and logical attributes (not yet used, but we
will need them at some point to support selective erase operations).
While making these changes I also noticed the `IsLeadingByte` and
`IsTrailingByte` methods weren't actually used anywhere, and weren't
correctly implemented anyway, so I've removed those now.
## Validation Steps Performed
I've manually run a number of attribute test scripts which cover both
legacy and VT operations, and everything still appears to be working
correctly.
Closes#14031
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 ✅
This commit fixes several issues:
* Some fonts set a line-gap even though they behave as if they
don't want any line-gaps. Since Terminals don't really have
any gaps anyways, it'll now not be taken into account anymore.
* Center alignment breaks bitmap glyphs which expect left-alignment.
* Automatic "opsz" axis makes Terminus TTF's italic glyphs look quite
weird. I disabled this feature as we might not need it anyways.
A complete fix depends on #14013Closes#14006
## Validation Steps Performed
* Use Terminus TTF at 13.5pt
* Print UTF-8-demo.txt
* No gaps between block characters ✅
If a rendering engine constantly throws error we'll effectively
denial-of-service our users by drowning them in warning popups.
This commit fixes the issue by limiting the retries in all cases.
Issue found in: #13985
## Validation Steps Performed
* Add a `THROW_HR(E_INVALIDARG);` in `AtlasEngine::StartPaint()`
* Launch Windows Terminal
* Only one warning popup shows up ✅
* Rendering is disabled until one clicks "resume" ✅
The `TileHashMap` refresh via `makeNewest()` in `StartPaint()` depends
on us filling the entire `cellGlyphMapping` row with valid data.
This commit makes sure to initialize the `cellGlyphMapping` buffer.
Additionally it clears the rest of the row with whitespace
until proper `LineRendition` support is added.
Closes#13962
## Validation Steps Performed
* vttest's "Test of double-sized characters" stops crashing ✅
* No weird leftover characters ✅
Direct3D 10.0 and 10.1 only have optional support for shader model 4.
This commit fixes our assumption that it's always present by checking
`ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x` first.
Closes#13985
## Validation Steps Performed
* Set feature level to 10.1 via `dxcpl`
* `CheckFeatureSupport` is called and doesn't throw ✅
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 4024b6933d446a359a35136053da8b4a8f598d9d
Related work items: MSFT-41327033
Disables strictness and warnings as errors for custom pixel shaders in
RELEASE. Windows terminal is not telling the user why the shader won't
compile which makes it very frustrating for the shader hacker.
After trying the recent preview none of my shaders loaded anymore in
Windows Terminal Preview which made me very sad. I had no idea what was
wrong with them. After cloning the git repo, building it, fighting an
issue that prevent DEBUG SDK from being used I finally was able to
identify some issues that were blocking my shaders.
> error X3556: integer modulus may be much slower, try using uints if possible.
> error X4000: use of potentially uninitialized variable (rayCylinder)
While the first one is a good warning I don't think it is an error and
the tools I use didn't flag it so was hard to know.
The second one I was staring at the code and was unable to identify what
exactly was causing the issues, I fumbled with the code a few times and
just felt the fun drain away.
IMHO: I want it to be fun to develop shaders for windows terminal.
Fighting invisible errors are not fun. I am not after building
production shaders for Windows Terminal, I want some cool effects. So
while I am as a .NET developer always runs with Warning as errors I
don't think it's the right option here. Especially since Windows
Terminal doesn't tell what is the problem.
However, I understand if the shaders you ship with Windows Terminal
should be free of errors and silly mistakes, so I kept the stricter
setting in DEBUG mode.
## Validation Steps Performed
Loaded Windows Terminal in RELEASE and DEBUG mode and validated that
RELEASE mode had reduced strictness but DEBUG retained the previous more
restrictive mode.
docs: https://github.com/marketplace/actions/add-to-github-projects?version=v0.3.0
Hey maybe we should use more actions. This was thrown out during the last GH sync. Hopefully this doesn't explode.
This _should_ add all issues that don't have one of `Issue-Feature`, `Needs-Triage`, `Needs-Author-Feedback`, `Issue-Scenario` to the project board. That should just leave all the bugs and tasks that have been triaged.
I didn't go for
```yml
labeled: Issue-Task, Issue-Bug
label-operator: OR
```
since those would include untriaged ones.
There's also no way to filter on milestone currently, so this will likely add icebox issues. We'll need to remove those manually as needed.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 7ea9457533db712ee8e8a5a11e1fbbdfc9430027
Related work items: MSFT:40841395
This replaces ~70k LOC (parts of boost, 1/4th of the code in this project)
with ~700 LOC (`small_vector.h`). By replacing boost, we simplify future
maintenance and improve compile times.
## Validation Steps Performed
* New and existing unit tests are ok ✅
* Various common VT applications run fine in debug mode OpenConsole ✅
This PR introduces a mechanism for passing through downloadable soft
fonts to the conpty client, so that we can support DRCS (Dynamically
Redefinable Character Sets) in Windows Terminal.
Soft fonts were first implemented in conhost (with the GDI renderer) in
PR #10011, and were implemented in the DX renderer in PR #13362.
The way this works is by passing through the `DECDLD` sequence
containing the font definition, but with the character set ID patched to
use a hardcoded value (this is to make sure it's not going to override
the default character set). At the same time we send through an `SCS`
sequence to map this character set into the G1 table so we can easily
activate it.
We still need to process the `DECDLD` sequence locally, though, since
the initial character set mapping take place on the host side. This gets
the DRCS characters into our buffer as PUA Unicode characters. Then when
the VT engine needs to output these characters, it masks them with `7F`
to map them back to ASCII, and outputs an `SO` control to activate the
soft font in the conpty client.
## Validation Steps Performed
I've manually tested with a number of soft fonts and applications that
make use of soft fonts. But if you're testing with the VT320 fonts from
the vt100.net collection, note that you'll need to enable the ISO-2022
coding system first, since they use 8-bit C1 controls.
When we added support for the `DECAC1` control sequence, which
determines whether `C1` controls are accepted or not, the intention was
that conhost would be making that determination, and Windows Terminal
would always be expected to accept any passed-through `C1` controls.
However, this didn't take into account that a passed-through `RIS`
sequence could end up disabling `DECAC1`, and that would leave Windows
Terminal incapable of processing any `C1` controls. This PR attempts to
fix that oversight.
The `DECAC1` sequence was added in PR #11690, when we disabled `C1`
acceptance by default.
This is a bit of a hack, but I've added a new `AlwaysAcceptC1` mode to
the state machine, which is enabled at startup in the Terminal, and is
never disabled. The parser then just needs to check whether either
`AcceptC1` or `AlwaysAcceptC1` are set.
## Validation Steps Performed
I've manually confirmed the test case in #13968 now works as expected.
Closes#13968
This PR introduces a mechanism for passing through line rendition
attributes to the conpty client, so we can support double-width and
double-height text in Windows Terminal.
Line renditions were first implemented in conhost (with the GDI
renderer) in PR #8664, and were implemented in the DX renderer in PR
#13102.
By default this won't add any additional overhead to the conpty output,
but as soon as there is any usage of double-size text, we switch to a
mode in which every line output will be prefixed with a line rendition
sequence. This is to ensure that the line attributes in the client
terminal are always in sync with the host.
Since this does add some overhead to the conpty output, we'd prefer not
to remain in this mode longer than necessary. So whenever there is a
full repaint of the entire viewport, we check to see if all of the lines
are single-width. If that is the case, we can then safely skip the line
rendition sequences in future updates.
One other small optimization is when the conpty update is only writing
out a single character (this is something we already check for). When
that is the case, we can safely skip the line rendition prefix, because
a single character update should never include a change of the line
rendition.
## Validation Steps Performed
I've manually tested that Windows Terminal now passes the double-size
tests in _Vttest_, and also confirmed various edge cases are working
correctly in my own double-size tests.
Closes#11595
Our Windows branch name changed, and I took this opportunity to resolve
an issue where vpack builds would occasionally fail due to GitHub rate
limiting the Azure DevOps IP addresses.
`ATLAS_POD_OPS` doesn't check for `has_unique_object_representations` and so a
bug exists where `CachedCursorOptions` comparisons invoke undefined behavior.
The color of inactive tab text is incorrect since #13689 due to the introduction
of `til::color::layer_over` which incorrectly calculated the RGB values.
## Validation Steps Performed
* Added unit tests ✅
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
This commit reduces the amount of telemetry during general usage by about half.
8 events that weren't really used anymore were removed.
1 new event was added ("AppInitialized") which will help us investigate #5907.
During review 9 events were found that were incorrectly tagged as perf. data.
## Validation Steps Performed
* Launch Windows Terminal
* The "latency" field "AppInitialized" matches the approx. launch time ✅
When Leonard updated CLI11 in #12658, he imported a version that no
longer requires RTTI. Since CLI11 was the only reason we had enabled
RTTI in any of our projects, we're finally able to turn it off.
| | TerminalApp.dll | MSIX Package |
| ------ | ---------------:| ------------:|
| Before | 3180KiB | 6545KiB |
| After | 1970KiB | 6426KiB |
| Delta | **-1210KiB** | **-119KiB** |
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 ✅
- fix: if a selection exists, mark mode should promote the existing selection instead of creating one at the cursor
- fix: mark mode --> move to middle of a word --> ExpandSelectionToWord --> Shift+Right/Left had some weird behavior. Fix that
- fix: Ctrl+enter on random selection clears selection. It should try to treat selection as a URL.
## References
#13854
NOTE: 3b53f3c can be serviced
As noted by the `winrt::event` documentation:
> [...] But for asynchronous events, even after revoking [...], an in-flight
> event might reach your object after it has started destructing.
This is because while adding/removing/calling event handlers might be
thread-safe, there's no guarantee that they run mutually exclusive.
This commit fixes the issue by reverting 6f0f245. Since we never checked
the result of closing a terminal connection anyways, this commit simply drops
the wait on the connection being teared down to ensure #1996 doesn't regress.
Closes#13880
## Validation Steps Performed
* Open tab, close tab, open tab, close tab, open tab, close tab
* ConPTY ✅
* Azure ✅
* Closing a tab with a huge amount of panes ✅
* Opening a bunch of tabs and then closing the window ✅
* Closing a tab while it's busy with VT ✅
* `wtd -w 0 nt cmd /c exit` ✅
* `wtd -w -1 cmd /c exit`
* No WerFault spawns ✅
This PR adds support for the `DECBKM` sequence, which provides a way for
applications to specify whether the `Backspace` key should generate a
`BS` character or a `DEL` character.
On the original VT100 terminals, the `Backarrow` key generated a `BS`,
and there was a separate `Delete` key that generated `DEL`. However, on
the VT220 and later, there was only the `Backarrow` key. By default it
generated `DEL`, but from the VT320 onwards there was an option to make
it generate `BS`, and the `DECBKM` sequence provided a way to control
that behavior programmatically.
On modern terminals, the `Backspace` key serves as the equivalent of the
VT `Backarrow`, and typically generates `DEL`, while `Ctrl`+`Backspace`
generates `BS`. When `DECBKM` is enabled (for those that support it),
that behavior is reversed, i.e. `Backspace` generates `BS` and
`Ctrl`+`Backspace` generates `DEL`.
This PR also gets the other `Backspace` modifiers more closely aligned
with the expected behavior for modern terminals. The `Shift` modifier
typically has no effect, and the `Alt` modifier typically prefixes the
generated sequence with an `ESC` character.
While not strictly related to `DECBKM`, I noticed while testing that the
`_SetInputMode` method was doing unnecessary work that was specific to
the `FocusEvent` mode. I've now moved that additional processing into
the `EnableFocusEventMode` method, which I think makes things somewhat
simpler.
## Validation Steps Performed
I've tested the basic `DECBKM` functionality in Vttest, and I've
manually tested all the modifier key combinations to make sure they
match what most modern terminals generate.
I've also added a unit test that confirms that the expected sequences
are generated correctly when the `DECBKM` mode is toggled.
Closes#13884
In testing the following issues were found in AtlasEngine and fixed:
1. "Toggle terminal visual effects" action not working
2. `d2dMode` failed to work with transparent backgrounds
3. `GetSwapChainHandle()` is thread-unsafe due to it being called outside
of the console lock and with single-threaded Direct2D enabled
4. 2 swap chain buffers are less performant than 3
5. Flip-Discard and `Present()` is less energy efficient than
Flip-Sequential and `Present1()`
6. `d2dMode` used to copy the front to back buffer for partial rendering,
but always redraw the entire dirty region anyways
7. Added support for DirectX 9 hardware
8. If custom shaders are used not all pixels would be presented
Closes#13906
## Validation Steps Performed
1. Toggling visual effects runs retro shader ✅
With a custom shader set, it toggles the shader ✅
Toggling `experimental.rendering.software` toggles the shader ✅
2. `"backgroundImage": "desktopWallpaper"` works with D2D ✅ and D3D ✅
3. Adding a `Sleep(3000)` in `_AttachDxgiSwapChainToXaml` doesn't break
Windows 10 ✅ nor Windows 11 ✅
4. Screen animations run at 144 FPS ✅ even while moving the window ✅
5. No weird artefacts during cursor movement or scrolling ✅
6. No weird artefacts during cursor movement or scrolling ✅
7. Forcing DirectX 9.3 in `dxcpl` runs fine ✅
This reverts commit f785168aac (PR #13244)
The error logged to NVDA was caused by the following line of code in `_getTextValue()`:
`THROW_HR_IF(E_FAIL, !bufferSize.IsInBounds(_start) || !bufferSize.IsInBounds(_end));`
NVDA would expand a text range to encompass the document in the alt buffer. This means that the "end" would be set to the dangling "endExclusive" point (x = left, y = one past the end of the buffer). This is a valid range!
However, upon extracting the text, we would hit the code above. The exclusive end doesn't actually point to anything in the buffer, so we would falsly throw `E_FAIL`.
Though this could be fixed by adding a special check for the `endExclusive` in the line above, I suspect there are other places throughout the UIA code that hit this problem too. The safest course of action is to revert this commit entirely since it was a code health commit (it doesn't actually close an issue).
Closes#13866
This is conjecture - I was totally unable to repro the original crash here.
Based on the stacks in MSFT:39994969, it looks like we try to fire off a
`RaiseAutomationEvent`, which calls through UIA core, eventually to the point of
calling `ComPtr<WUX::Automation::Peers::IAutomationPeer>::{dtor}`. I'm guessing
based on the stacks that the TermControl has already been released and cleaned
up. However, the lambda in the `RunAsync` calls here only takes a ref to the
TCAP. The TCAP has an outstanding reference (maybe on the other side of the UIA
fence), and gets successfully resolved as strong, but when calling to
`RaiseAutomationEvent`, the `owner` we passed in is gonezo.
This explicitly passes a `weak_ref` to `TermControlAutomationPeer`, rather than
a raw ptr, so we can actually check if the control is still alive before _we_
dereference it. If it is, great, we've got a strong ref to it now and it won't
get torn down.
Again, this is hearsay. Without a repro, the only way we can confirm this is
gone is by just hoping the crashes go away. 🤞
* Might close#13357 (we'll reopen if it doesn't?)
* narrator still works
## Summary of the Pull Request
Fix a bug where if you pressed the "Save" button, WT would crash. This was caused by adding the possibility that no color scheme is selected in the main page. With no "current scheme", attempting to get its "name" would cause a null ptr exception.
The fix is simple: just check if we actually have a current scheme.
Bonus points: if we don't have a current scheme, don't bother looking throught the color schemes for a match because we'll never find one.
## References
#13269 - Color Schemes Rejuv
## 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.
This commit stores a hash of the `settings.json` file in `ApplicationState`
with which we can detect whether the settings contents actually changed.
Since I only use a small 64-bit hash as opposed to SHA2 for instance,
I'm taking the last write time of the file into account as well.
This allows us to skip calling `UpdateJumplist` at least the majority of app
launches which hopefully improves launch performance on devices with slower IO.
Part of #5907.
## Validation Steps Performed
* Delete some profiles (see above), save settings, tasks are gone ✅
FYI For some (...) inexplicable reason, shell task lists are preserved forever
even if msix applications are uninstalled, etc. So to test whether tasks are
properly written on first app launch we have to delete some profiles/tasks
first, otherwise we can't see whether they're actually written later.
* Now exit Windows Terminal, delete `settings.json` and relaunch
* All tasks are back ✅
* With a debugger, ensure that `CascadiaSettings::WriteSettingsToDisk`
generates the same hash that `LoadAll` reads. ✅
Update the color schemes page with the new Win 11 style.
With the rejuvenated experience, we now have two pages:
- `ColorSchemes.xaml`: "color scheme selection" page
- This is the starting page for the "color schemes" nav view
item. It is intended to have the user select a color scheme
they want to modify. The user can also click the "Add new"
button to add a new color scheme or the "delete" button to
delete the selected scheme.
- If a scheme cannot be deleted, the delete button is disabled
and a disclaimer is shown.
- A "set as default" button sets the selected scheme as the
color scheme for profiles.default (aka "base layer").
- The list view item for each scheme includes the name of the
scheme, the default tag (if the scheme is the one set in base
layer), a text preview of the foreground/background, and a
grid of 16 color chips showing the colors for the scheme.
- Implementation details:
- View - `ColorSchemes`:
- "Enter" --> edit the selected scheme
- "Delete" --> delete the selected scheme
- if the selected scheme cannot be deleted, we
show the disclaimer
- View model - `ColorSchemesPageViewModel`
- when possible, the XAML binds directly to the
view model functions. Thus, we include logic
to delete, edit, and set the selected scheme
as default.
- store the current page, so that we know which
page to navigate to upon saving/discarding
changes.
- `EditColorScheme.xaml`: "color scheme modification" page
- a terminal preview of the color scheme is shown at the top of
the page.
- all colors for the scheme are displayed as color chips in an
expander that starts as expanded.
- renaming a color scheme is also inside an expander, but
there's no need for "renaming mode" anymore
- Implementation details:
- View - `EditColorScheme`:
- include logic to display the disclaimer and
add the automation properties
- include logic for "Enter" and "Escape" in the
rename editor
- View Model - `ColorSchemeViewModel`:
- as before, when possible, the XAML binds
directly to the view model functions.
- To enable the "default" tag functionality, we
had to expose knowledge of being the default
via "IsDefaultScheme()" which compares the
current name to the one in the settings model.
- Miscellaneous implementation details:
- to get the expander to start as expanded, we had to modify the
setting container style.
- Since "set as default" is a button on the selector page, we
needed a way to refresh the view model's knowledge of being
the default. So we added a `RefreshIsDefault` API to the
`ColorSchemeViewModel` to notify changes.
- With the new layout, we no longer need an 'enter rename mode'
button, so all that logic has been removed
- Add logic to `MainPage` to handle navigating to the correct
page upon saving/discarding changes.
Closes#9775
Co-authored-by: Carlos Zamora <cazamor@microsoft.com>
See also:
33732458ed/dev/SplitButton/SplitButton.xaml (L290-L293)
We need to
* Also set `SplitButtonForegroundSecondary` cause SplitButton's use that resource separately from the `Foreground()` property
* Manually trigger the visual state change, to refresh the brushes. We do something similar in TabBase
This is one of the bullet points in #13725
This commit implements support for `experimental.rendering.software`.
There's not much to it. It's just another 2 if conditions.
## Validation Steps Performed
* `"experimental.rendering.software": false` renders with D3D ✅
* `"experimental.rendering.software": true` triggers the new code path ✅
This commit implements support for custom shaders in AtlasEngine
(`experimental.retroTerminalEffect` and `experimental.pixelShaderPath`).
Setting these properties invalidates the device because that made it
the easiest to implement this less often used feature.
The retro shader was slightly rewritten so that it compiles without warnings.
Additionally we noticed that AtlasEngine works well with D3D 10.0 hardware,
so support for that was added bringing feature parity with DxRenderer.
Closes#13853
## Validation Steps Performed
* Default settings (Independent Flip) ✅
* ClearType (Independent Flip) ✅
* Retro Terminal Effect (Composed Flip) ✅
* Use wallpaper as background image (Composed Flip) ✅
* Running `color 40` draws everything red ✅
* With Retro Terminal Effect ✅
When selecting candidate history, priority is given to histories with empty commands list.
I think lazily calling `s_Allocate` will require a ton of rewriting. Also I think it is not an unexpended behavior that buffer is allocated when an application connects.
Closes#13571
## 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
Direct2D is able to detect remote connections and will switch to sending
draw commands across RDP instead of rendering the data on the server.
This reduces the amount of data that needs to be transmitted as well
as the CPU load of the server, if it has no GPU installed.
This commit changes `AtlasEngine` to render with just Direct2D if a software or
remote device was chosen by `D3D11CreateDevice`. Selecting the DXGI adapter the
window is on explicitly in the future would allow us to be more precise here.
This new rendering mode doesn't implement some of the more fancy features just
yet, like inverted cursors or coloring a single wide glyph in multiple colors.
It reuses most existing facilities and uses the existing tile hash map to cache
DirectWrite text layouts to improve performance. Unfortunately this does incur
a fairly high memory overhead of approximately 25MB for a 120x30 viewport.
Additional drive-by changes include:
* Treat the given font size exactly as its given without rounding
Apparently we don't really need to round the font size to whole pixels
* Stop updating the const buffer on every frame
* Support window resizing if `debugGeneralPerformance` is enabled
Closes#13079
## Validation Steps Performed
* Tested fairly exhaustively over RDP ✅
More or less, as in #13554
* Dark theme by default (was `system`)
* Justification:
> I think the interesting thing that we have today is that the color
> scheme is dark by default, but our window theme is set to system.
> System theme in Windows 11 is defaulted to light unless changed by
> the user. Now, we have a conflict between the theme and color scheme
> in Terminal.
>
> I think our options become, make the color scheme match "default"
> and set it to a light color scheme if the system theme is light, or
> manually match the theme to the color scheme by setting it to dark.
>
> Given that Terminal has historically had a black background with
> its Campbell color scheme, for a consistent UI experience, I'm
> voting to change the window theme to be dark by default as well.
* `tab.background: terminalBackground`
* Change the tab row colors back to "what they were pre-Controlsv2" more
or less
- The ramp is based off of "Light tab row background from Edge's
unfocused titlebar color, inactive tab row color BG from the
controlsv1 colors"
* `tabRow.unfocusedBackground` set `Transparent`
Closes#13554
Does what it sounds like on the label.
This is important, because when unset, the tab will use the active `Background` color to create an inactive BG, which maybe isn't what we want. Consider:
- a bright cyan active BG,
- and `terminalBG` for the `tabRow` bg.
Without an unfocusedBackground setting, all the tabs will still appear cyan when unfocused, which is extra gross.
As a judgement call, I made `terminalBackground` and `accent` use 30% opacity when set, to match the existing coloration.
See also #13554. If we want to make the default theme `tab.background: terminalBackground`, we should make `tab.unfocusedBackground` transparent (`#00000000`) by default. Otherwise, a Campell (`#0c0c0c`) tab on _any_ tab row will still have a faint tab visible.
* closes#13684
* closes#13246
* tested manually
This also does a lot of code shuffling, to get SettingsUI tabs to behave sensibly. We want those tabs to have (`#0c0c0c`, `#ffffff`) colored BGs for `terminalBackground` (see mail thread).
We also don't want dark focused tabs colors, combined with light tab row colors, combined with transparent unfocused tabs, to result in unfocused tabs having white-on-white text. That's gross. So that's been added to this PR in b38b704.
This pull request adds the JSON schema for `cgmanifest.json`.
## FAQ
### Why?
A JSON schema helps you to ensure that your `cgmanifest.json` file is valid.
JSON schema validation is a build-in feature in most modern IDEs like Visual Studio and Visual Studio Code.
Most modern IDEs also provide code-completion for JSON schemas.
### How can I validate my `cgmanifest.json` file?
Most modern IDEs like Visual Studio and Visual Studio Code have a built-in feature to validate JSON files.
You can also use [this small script](https://github.com/JamieMagee/verify-cgmanifest) to validate your `cgmanifest.json` file.
### Why does it suggest camel case for the properties?
Component Detection is able to read camel case and pascal case properties.
However, the JSON schema doesn't have a case-insensitive mode.
We therefore suggest camel case as it's the most common format for JSON.
### Why is the diff so large?
To deserialize the `cgmanifest.json` file, we use [`JSON.parse()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse).
However, to serialize the JSON again we use [`prettier`](https://prettier.io/).
We found that, in general, it gave smaller diffs than the default [`JSON.stringify()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) function.
Since locking the console can take a non-trivial amount of time,
the main thread might have already released the ControlCore instance, while the
`UpdatePatternLocations` background thread is holding the last active reference.
If the function call goes out of scope, we destroy the instance, which might
not be safe, considering its members are usually only used by the main thread.
This commit fixes the issue by only holding a reference of the `Terminal`.
## Validation Steps Performed
* Patterns are recognized ✅
See https://github.com/microsoft/terminal/issues/12176#issuecomment-1199488906, and MSFT:39723014.
I have literally no idea how to repro this one, or debug it. The dump I looked at looked like there was a `SwapChainScaleChanged` that was being dispatched as the app was tearing down. The `ControlCore` had started closing, but the `TermControl` hadn't yet. Apparently, just none of the `_refreshSizeUnderLock` callers checked if we were already closing.
All the callers appear to be on the main thread.
Closes#12176
Since there's no real way for me to repro this manually, I'm thinking we fire this fix off to the OS terminal build, where we'll pretty quickly be able to see if this fixed it or not.
While having a debugger attached, opening the settings tab generates an
uncomfortable amount of exceptions. This change reduces this by a lot.
## Validation Steps Performed
* Icons still appear ✅
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
This PR by itself doesn't _really_ change much. Technically, now the Terminal will respect the Title of a `.lnk` when started for defterm, but we don't do anything else yet. Primarily, the goal of this PR is to just wire up startup info in OpenConsole to the connected Terminal.
* This required a bit of changes in `srvinit.cpp:ConsoleEstablishHandoff` to replicate other bits of startup, where we crack open the connect message to get the relevant bits of info.
* We pack that all into a `TERMINAL_STARTUP_INFO`, which we pass along to the registered terminal application.
* `ConptyConnection` accepts the handoff, and gathers that information out of the `TERMINAL_STARTUP_INFO`
* Some other updates to the scratch sln were made to make it build again (related, but unimportant).
* This is a precursor to:
* #13111
* #12154
* Closes#9458
* Tested manually
* I work here
## Summary of the Pull Request
The command palette (and tab search by extension) doesn't ever tell screen readers what is selected. Here, we simply hook up the selection changed event to a function that tells the screen reader what is selected. With this, the user no longer has to tab into the list view to know what is selected!
Will resolve the following bug upon validation from a11y team: #12065
## Validation Steps Performed
Performed repro steps from #12065.
NOTE: we do NOT read the selected item when the command palette is first opened. I think that's ok.
I got tired of renaming the packages that came out of our build
pipeline. I also got tired of the fact that every appxbundle artifact we
upload comes with another whole copy of Terminal for every architecture,
plus all their symbols. Those are reflected in other artifacts, so
there's no reason to duplicate them.
## Summary of the Pull Request
Polishes #13405 with some additional feedback found in testing and post-mortem reviews. Such feedback includes:
- [x] ControlInteractivity vs ControlCore split ([link](https://github.com/microsoft/terminal/pull/13405#discussion_r919365435))
- [x] clearing the selection should be under lock when copying text via "Enter"
- [x] move mark mode keybindings into a helper function
- [x] decide if "Enter" should be configurable or non-configurable ([link](https://github.com/microsoft/terminal/pull/13405#discussion_r919379305))
- [x] rename `_isTargetingUrl`
- [x] bugfix: ctrl+enter when the link is outside of the viewport
## References
Original PR: #13405
Relevant issue: #6649
Epic: #4993
Apparently, calling `GetText(INT_MAX)` causes a HUGE memory spike for a few seconds each time this is called. The [UIA docs](https://docs.microsoft.com/en-us/windows/win32/api/uiautomationcore/nf-uiautomationcore-itextrangeprovider-gettext#parameters) say to put `-1` if no limit is required, but I assume a few people have been hit by this before.
This addresses this issue (and similar ones) in two ways:
1. as we iterate over the lines of text, if we're already past the max length, just break out of the loop
2. _only_ resize if the max length is actually less than the current length. This prevents us padding the string with `L'\0'` erroneously (which is probably what causes the memory spike).
While debugging #13694, we discovered a very subtle bug we had accidentally introduced in a few places. `ViewModelHelper` defines a `PropertyChanged` event, backed by a `_propertyChangedHandlers` `event`. All opbservable properties in the viewmodels are supposed to run through that event. However, if you do `WINRT_CALLBACK(PropertyChanged, Windows::UI::Xaml::Data::PropertyChangedEventHandler)` in a derived class, it'll override that original method with the new one. XAML will subscribe to the second one, which is backed by `_PropertyChangedHandlers`, but the properties will still raise notifications on the callbacks registered to `_propertyChangedHandlers`.
This change makes it more explicit in these derived classes, that the `PropertyChanged` method exposed by these classes is indeed the one that's implemented in the base class.
This is a bit of a footgun, for sure. AuditMode would have apparently caught this, as we'd be overriding a method without using the `override` keyword.
Unblocks #13694.
In Global Appearance SUI, the toggle switch for "Always show tabs" is now grayed out when "Hide the title bar" is enabled (the default).
Also, the order of the settingcontainers was changed to help show the cause and effect more. See [this comment](https://github.com/microsoft/terminal/issues/12873#issuecomment-1094928881).
Closes#12873
After some deliberation I noticed that rounding the glyph advance up to yield
the cell width is at least just as wrong as rounding it. This is because
we draw glyphs centered, meaning that (at least in theory) anti-aliased
pixels might clip outside of the layout box on _both_ sides of the glyph
adding not 1 but 2 extra pixels to the glyph size. Instead of just `ceilf`
we would have had to use `ceilf(advanceWidth / 2) * 2` to account for that.
This commit simplifies our issue by just going with what other applications do:
Round all sizes (cell width and height) to the nearest pixel size.
Closes#13812
## Validation Steps Performed
* Set a breakpoint on `scaling Required == true` in `AtlasEngine::_drawGlyph`
* Test an assortment of Cascadia Mono, Consolas, MS Gothic, Lucida Console
at various font sizes (6, 7, 8, 10, 12, 24, ...)
* Ensure breakpoint isn't hit ✅
This tells us that no glyph resizing was necessary
This commit fixes two race conditions:
* `SetPseudoWindowCallback` set the `_pseudoWindowMessageCallback`
callback after the Win32 message thread was already spawned.
This issue was fixed by instead using the `ServiceLocator` to get
a hold of the global `VtIo` instance which is created statically.
* `XtermEngine::SetWindowVisibility` was called without holding the
console lock. This issue was fixed by simply acquiring it first.
Closes MSFT:40913882
## Validation Steps Performed
* Add `IsConsoleLocked()` assertion in `VtEngine::_Write`
* Run Windows Terminal
* No assertion failures ✅
## Summary of the Pull Request
This PR moves the key handling for mark mode into a helper method that is then called before an action/key binding is attempted.
## References
Epic: #4993Closes#13533
## Validation Steps Performed
- Add custom keybinding to "down" arrow key
- in mark mode --> selection updates appropriately
- out of mark mode --> keybinding executed
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.
Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.
`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.
We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.
Except that part about the relative coordinates. That was not fine.
The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.
This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.
Closes#13769.
The absolute disgrace of a fix called 65b71ff failed to account for `std::move`
being unsafe to use for overlapping ranges. While `std::move` works for trivial
types (it happens to delegate to `memmove`), we need to dynamically switch
between that and `std::move_backward` to be correct.
Without this fix the LRU refresh is incorrect and might lead to crashes.
## Validation Steps Performed
I'm working on a new, pure D2D renderer inside AtlasEngine, which uses
the iterators contained in `_r.cellGlyphMapping` to draw text.
I noticed the bug, because scrolling up caused the text to be garbled
and with this fix applied it works as expected.
Fixes MSFT:38775539
Might also fix MSFT:38614563
Looking at this code should be pretty clear what's going on. On exit, the XAML root is already nulled out. But here, we're just yolo'ing and assuming it exists (why wouldn't it). So yea. This is like weirdly high percent of crashes internally, but that's not from real users. Real users, I suspect hit this as like .3% of our crashes. Not zero, but _low_.
* [x] tested manually
<hr>
May also be related to...
* MSFT:40602905
* MSFT:40602904
* MSFT:40412800
* MSFT:35213459 <---has links
Fixes MSFT:40853556
There's a small race here. The renderer thread in ConPTY might notice the terminal is gone, call CloseOutput, and release the vt renderer, and then the window proc fires and decides to minimize/restore the window, triggering an A/V.
I'm 100% confident that this has NEVER happened to a real user. But the test labs hit it so much that it makes up ~26% of our crashes.
I haven't tested this cause again, _it doesn't hit in the wild_
Rename `til::form_wchars` to `til::to_ulong` and
allow it to work with narrow `char`s.
This change will be used in #13429.
## Validation Steps Performed
* Loads `sc(...)` key bindings as expected ✅
* The change is thankfully fairly trivial if viewn with whitespace suppressed
We shouldn't add URLs into our binaries that we can't directly control.
This commit fixes the issue for URLs recently introduced in #13510.
Closes#13541
## Validation Steps Performed
This change is trivial enough that I simply opened the new redirects
in my browser, ensuring that they open the expected websites.
`debugGlyphGenerationPerformance` used to only test the performance of
text segmentation/parsing, so I renamed it to `debugTextParsingPerformance`.
The new `debugGlyphGenerationPerformance` actually clears the glyph atlas now.
Additionally this fixes a bug with `debugGeneralPerformance`:
If a `DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT` is requested,
it needs to be used. Since `debugGeneralPerformance` is for testing without
V-Sync, we need to ensure that the waitable object is properly disabled.
## Summary of the Pull Request
Skips whitespace removal if pasted string is multiline
## PR Checklist
* [x] Closes#12387
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
Tests passed
The last command in multiline paste now executes
Does two things:
* the first two commits: shakes up the way we reference MUX in our projects so we can actually just
```xml
<PropertyGroup Label="NuGet Dependencies">
<TerminalMUX>true</TerminalMUX>
</PropertyGroup>
```
Like every other dependency we have
* the last commit: update to MUX.2.7.3
This is the 1.14 PR, which should be appropriately cherry-picked through to `release-1.15` and `main`
(cherry picked from commit a277b56f6a)
Repurpose `Feature_AtlasEngine` to enable the atlas engine by default in Dev and Preview builds.
Introduce `Feature_ConhostAtlasEngine` to solely control atlas engine inclusion in conhost.
Closes#13745
We have a number of theories why #12607 is happening, one of which is that
some GPU drivers somehow rely on Win32 messages or similar which we process
on the main thread. If we then try to acquire the console lock on the main
thread, while the GPU-driver thread itself is holding that lock, we've got
ourselves a deadlock. This PR makes this less likely by running the repeat
offender `UpdatePatternLocations` on a background thread instead.
We have a number of other locations which acquire the console lock on the
main thread and a thorough bug fix must be done in a different way.
## Validation Steps Performed
* After pasting an URL it gets underlined on hover ✅
Currently "Inverse Cursor" is actually simply bitwise inversed.
It works fine, except when it does not, namely in the middle of the spectrum:
Anything close enough to dark grey (index 8, RGB(128, 128, 128) in the
classic palette) will for obvious reasons become almost the same dark grey
again after the inversion.
The issue is addressed by additionally `XOR`ing the inverted color with
RGB(63, 63, 63). This distorts the result enough to avoid collisions
in the middle. Ultimately this restores the behavior that was in
Windows Console since the Middle Ages (and still exists in ConhostV1.dll).
## PR Checklist
* [x] Closes#3647
* [x] CLA signed
* [x] Tests added/passed
* [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: #3647
## Validation Steps Performed
1. Open OpenConsole.
2. Properties, Terminal, Cursor Colors, choose Inverse Color.
3. Optionally set the RGB value of the 8th color in the standard palette to RGB(128, 128, 128) on the Colors tab, but the default one will do too.
4. Type `color 80` to see black text on dark grey background.
5. Make sure the inverted cursor is visible.
6. Repeat in WT with both default and experimental renderers.
## Summary of the Pull Request
Changes the way `_addCommandsForArg` determines if the delimiter was at the beginning of the argument so that it accounts for the fact that match includes the last character of the string before it.
## PR Checklist
* [x] Closes#13277
## Validation Steps Performed
`wt -p "u"; nt -p "u"` does not cause an error
This commit builds directly on the changes made in #13677 and fixes:
* TSF resetting to AlphaNumeric ("ASCII") input mode when pressing enter
* Vietnamese IME not composing a new word after pressing whitespace, etc.
Closes#11479Closes#13398
## Validation Steps Performed
* Japanese IME (Full-Width Katakana)
Typing "saitama" produces "サイタマ" ✅
* Korean IME
Typing "gksrmf" produces "한글" ✅
* Vietnamese IME
Typing "xin chaof" produces "xin chào" ✅
* Emoji Picker (Win+.)
✅
Adds a variable `_isBackgroundLight` that is updated when the background
color is changed. When it is `true`, the BEL indicator flash will darken
the screen instead of brightening.
`_isColorLight(bg)` returns `true` if the average of `r`, `g`, and `b`
is >127
I was unsure of an appropriate way to change the color of the
`CompositionLight` based on the background, so I changed it to always be
gray and adjusted the intensity values of the original animation to have
roughly the same visual effect as the white.
## Validation Steps Performed
* Tested the two flashes on the default color schemes and some custom
background colors to see if they look consistent
* Used tracepoints and visual to check that the right animation is used
(including multiple tabs, split windows with different themes, and
changing settings while window is open)
References #9270Closes#13450
This pull request reintroduces aliases for `VkKeyScanW`,
`MapVirtualKeyW` and `GetKeyState` that redirect through ConIoSrv on
OneCore devices.
We made an assertion in PR !7096375 that those APIs were hosted in an
extension APIset that was present on all OneCore devices. It turned out
that this was _incorrect_: that APIset extension is only hosted on
OneCoreUAP and above.
This would not be a problem save for NanoServer. NanoServer is built on
top of OneCore.
As Nano is a container host OS, it is primarily interfaced vith via
ConPTY... which exercises the VkKeyScanW/MapVirtualKeyW codepaths quite
a bit. Those APIs started returning invalid data, which caused us to
convert all incoming keyboard events into numpad events. This didn't
prove to be an issue for CMD or PowerShell (weirdly,) but it did prove
to be an issue for Redis. Unfortunately, Redis is exactly the sort of
thing you might want to run in a container.
Reintroducing these aliases was complicated because we took the
opportunity to remove all of IInputServices (!7105348), which was a
wrapper around some code that would choose Win32 or OneCore depending on
the runtime environment.
I made the choice (with the help of Leonard Hecker) to reimplement these
functions in a different way: always call the delay-loaded version, and
then on OneCore editions check the return value and error code to ssee
if we hit a delay load failure. It incurs a minor cost, but all of the
delay loads are in-proc and do not require us to make a syscall, so that
cost is negligible.
Part of this new implementation requires us to change _all conhost
internal callers_ to use "OneCoreSafe" versions of those APIs. We can't
redirect the user32 versions out of the way and usurp their import
symbols, so this commit also introduces some warning defines. If you use
VkKeyScanW (and friends), you _should_ get a linker error. Assuming
HostAndPropsheetIncludes has been included. It very well may not have
been included.
Fixes MSFT-40435912
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 949e8dfc07f122520c6a74412329a6f7e77d19c5
wyhash was chosen based on the results found in `smhasher`, were it proved
itself as an algorithm with little flaws and fairly high output quality.
While I have a personal preference for xxhash (XXH3 specifically), wyhash is a
better fit for this project as its source code is multiple magnitudes smaller,
simplifying the review and integration into the header-only `hash.h` file.
For use with hashmaps the hash quality doesn't actually matter much for
optimal performance and instead the binary size usually matters more.
But even in that scenario wyhash is fairly close to FNV1a (aka "FNV64").
The result is that this new hash algorithm will only have little impact on
hashmap performance if used over the standard FNV1a as used in the STL,
while simultaneously offering a vastly better hash quality.
This partially solves #13124.
## Validation Steps Performed
* Added test cases ✅
Other settings model classes call `JsonUtils::SetValueForKey` with the
private `_##value` member as the value. Since `_##value` is an optional,
this prevented writing out unset, optional fields. The new `Themes` class
deviated from this and this commit brings it back in line with the others.
Closes#13544
## Validation Steps Performed
* Create a `{ "name": "test" }` theme
* Save settings via the UI
* Optional/Defaulted fields aren't written ✅
## Summary of the Pull Request
VC++ v14 Descktop Framework package is required and not installed automatically when installing package manually.
## PR Checklist
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
While working on #13398 I felt that `TSFInputControl` wasn't up to sniff.
This commit is a minor cleanup of the class:
* default member initializers
* Simplified use of STL classes which already perform boundary checks
* Correctly check text buffer emptiness in `_SendAndClearText`
* Track selection range as mandated by the API
## Validation Steps Performed
* Japanese IME (Full-Width Katakana)
Typing "saitama" produces "サイタマ" ✅
* Korean IME
Typing "gksrmf" produces "한글" ✅
* Vietnamese IME
Typing "xin chaof" continues to produce broken "xin xinchaof"
(It's supposed to produce "xin chào")
* Emoji Picker (Win+.)
✅
## Summary of the Pull Request
- We only ever have 1 color picker now, instead of each tab having its own
- `TerminalPage` constructs this color picker (upon first request for it)
- `TerminalPage` attaches the color picker to the tab that requested for it
- `TerminalTab` detaches the color picker when it is done with it, so that `TerminalPage` can attach it to another tab later on
## References
#5907
## Validation Steps Performed
User-end behaviour is the same
We must use 65535 as `MAX_PARAMETER_VALUE` in order for us to properly parse
win32-input-mode sequences, which transmit UTF-16 characters as parameters.
Closes#12977
## Validation Steps Performed
* Call `SendInput` with 🙁 (`L'\xD83D'`, `L'\xDE41'`)
* 🙁 appears on the input line ✅
## Summary of the Pull Request
In #13560 we added a member to `Pane` that lets it know if it was spawned as a default terminal session, but did not propagate that value when the pane gets split or when the pane closes. This commit fixes that.
## Validation Steps Performed
A session spawned by a def term invocation remembers it even as it goes through splits
## Summary of the Pull Request
In general, when a selection marker is shown, we should scroll to it. The `selectAll` action adds a selection marker, but we don't scroll to it. This PR makes it such that we do do that.
Epic: #4993Closes#13485
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
This fixes an issue were overwriting parts of a row would only trigger
that specific portion of the row to be redrawn. This isn't just
problematic for combining characters, but also for things like
the new `TestDbcsBisectWriteCells` test introduced in #13626.
Benchmarks showed no impact on performance whatsoever.
## Validation Steps Performed
* Pick this commit into #13626
* Run the `TestDbcsBisectWriteCells` test and break before OpenConsole exits
* A correct "QいかなZYXWVUTに" output is visible ✅
This commit makes AtlasEngine recognize Powerline glyphs as box drawing ones.
The extra pixel offsets when determining the `scale` caused weird artifacts
and thus were removed. It seems like this causes no noticeable regressions.
Closes#13029
## Validation Steps Performed
* Run all values of `wchar_t` through `isInInversionList`
and ensure it produces the expected value ✅
* Powerline glyphs are correctly scaled with Cascadia Code PL ✅
07d58a8 contains a regression where the settings' `Themes()` property is
accessed without checking whether it's a `nullptr`. This can happen because
the invalid settings modal is shown with a empty settings model object.
This commit fixes the issue by deferring the update of `_settings` until
after we ensured that the `_settings` object is valid (besides warnings).
Closes#13543
## Validation Steps Performed
* Replace any string value with `123`
* Application doesn't crash ✅
## Summary of the Pull Request
- When 'discard changes' is hit, we re-initialize our list of color scheme view models but forgot to tell xaml about it, this commit fixes that.
- Make sure to exit rename mode when 'update settings' gets called
## References
color schemes mvvm added in #13179
## PR Checklist
* [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: #xxx
## Validation Steps Performed
Hitting discard changes doesn't cause an inconsistency with the currently selected scheme anymore
## 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
Curiously, at least on Windows 10 (and rarely on Windows 11), if you minimize the Terminal by clicking on the taskbar, then alt-tab to try and restore the window, the Taskbar will decide to call `SwitchToWindow` on the invisible, owned ConPTY window instead of the main window. When that happens, ConPTY'll get a `WM_SIZE(SIZE_RESTORED, lParam=0)`. The main window will NOT get a `SwitchToWindow` called. If ConPTY doesn't actually inform the hosting process about this, then the main HWND might stay hidden.
* Refer to #13158 where we disabled this.
* Closes#13589
* Closes#13248
* Tested manually on a Windows 10 VM.
* Confirmed that opening tabs while maximized/snapped doesn't restore down.
* `[Native]::ShowWindow([Native]::GetConsoleWindow(), 6)` still works
## Summary of the Pull Request
Adds support for the `tab.showCloseButton` property to themes. This accepts three values:
* `"always"` (default): The close button acts like it does today.
* `"hover"`: The close button is always visible on the active tab. On inactive tabs, the close button only appears on mouse over.
* `"never"`: The close button is never visible. You can't close the tab with middle-click, but you can still use keyboard shortcuts to close the tab.
## References
* See #3327
* ⚠️ targets #13178⚠️
## PR Checklist
* [x] Closes#3335
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated - YUP
## Detailed Description of the Pull Request / Additional comments
See the following two properties in WInUI that we're leveraging here.
* [`TabViewCloseButtonOverlayMode.OnPointerOver`](https://docs.microsoft.com/en-us/windows/winui/api/microsoft.ui.xaml.controls.tabviewclosebuttonoverlaymode?view=winui-2.7&viewFallbackFrom=winui-2.2)
* [`TabViewItem.IsClosable`](https://docs.microsoft.com/en-us/windows/winui/api/microsoft.ui.xaml.controls.tabviewitem.isclosable?view=winui-2.2#microsoft-ui-xaml-controls-tabviewitem-isclosable)
One is a tabview-level property, the other is a per-tab-item property, hence why this code is a little wacky.
## Validation Steps Performed
gifs below
This commit contains 3 improvements for glyph rendering:
* Scale block element and box drawing characters to fit the cell size
"perfectly" without leaving pixel gaps between cells.
* Use `IDWriteTextLayout::GetOverhangMetrics` to determine whether glyphs
are outside the given layout box and if they are, offset their position
to fit them back in. If that still fails to fit, we downscale them.
* Always scale up glyphs that are more than 2 cells wide
This ensures that long ligatures that mimic box drawing characters like
"===" under Cascadia Code are upscaled just like regular box drawings.
Unfortunately this results in ligature-heavy text (like Myanmar) to get an
"uneven" appearance because some ligatures can suddenly appear too large.
It's difficult to come up with a good heuristic here.
Closes#12512
## Validation Steps Performed
* Print UTF-8-demo.txt
* Block characters don't leave gaps ✅
* Print a lorem-ipsum in Myanmar
* Glyphs aren't cut off anymore ✅
* Print a long "===" ligature under Cascadia Code
* The ligature is as wide as the number of cells used ✅
## Summary of the Pull Request
Implements the MVVM style for the Color Schemes editor
## PR Checklist
* [x] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
Introduces:
- `ColorSchemesPageViewModel`: The view model responsible for the entire color schemes page. Handles what the current scheme is, adding/deleting/renaming schemes
- `ColorSchemeViewModel`: A view model class for individual color schemes
## Validation Steps Performed
Manually tested:
- Edit a color scheme
- Add new color scheme
- Rename a color scheme
- Delete a color scheme
This is an experiment, as discussed in https://github.com/microsoft/terminal/issues/11790#issuecomment-1179143049. We don't know what for sure causes these crashes, but it seems that blindly throwing, so that it gets picked up by Watson, is probably not the move. Instead, we're just gonna do our fallback, REGARDLESS of what the exception was.
See #11790, MSFT:38542548, MSFT:38572983, MSFT:38542574 et. al.
Refer to https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
The OS will send us a WM_QUERYENDSESSION when it's preparing an
update for our app. It will then send us a WM_ENDSESSION, which gives
us a small timeout (~30s) to actually shut down gracefully. After
that timeout, it will send us a WM_CLOSE. If we still don't close
after the WM_CLOSE, it'll force-kill us (causing a crash which will be
bucketed to moapphang).
We will manually start a quit, so that we can persist the state. If we refuse to
gracefully shut down, the OS will crash us to focefully terminate us. We
choose to quit here, rather than just close, to skip over any warning dialogs
(e.g. "Are you sure you want to close all tabs?") which might prevent a WM_CLOSE
from cleanly closing the window.
This will cause a appHost._RequestQuitAll, which will notify the
monarch to collect up all the window state and save it.
This "crash" caused by the OS force killing us constitutes 80% of all our crashes. 80%. See MSFT:38947155, MSFT:38877540, MSFT:21058878, MSFT:31710054, MSFT:39764652, MSFT:26883776.
Closes#13569
It also fixes the issue where if you've got Terminal Dev running (outside VS), and you try to Deploy, you have to make sure to close the "Are you sure you want to close all tabs" dialog before the deployment can proceed. A deploy in VS sends the same sequence of messages as a real update.
This commit implements the remaining 5 of 8 grid lines:
left/top/right/bottom (COMMON_LVB) borders and double underline
`AtlasEngine::_resolveFontMetrics` was partially refactored to use `float`s
instead of `double`s, because that's what the remaining code uses as well.
It also helps the new, slightly more complex double underline calculation.
## Validation Steps Performed
* Print characters with the `COMMON_LVB_GRID_HORIZONTAL`, `GRID_LVERTICAL`,
`GRID_RVERTICAL` and `UNDERSCORE` attributes via `WriteConsoleOutputW`
* All 4 grid lines are visible ✅
* Grid lines correctly scale according to the `lineWidth` ✅
* Print a double underline with `printf "\033[21mtest\033[0m"`
* A double underline is fully visible ✅
Cleans up a couple local test failures.
* [x] Closes#13474: So, I clearly hadn't ran the local tests at the end of the themes PR. We needed a sensible fallback to SOME theme, even if there wasn't one provided in the user json. This is only really hit in the tests (that don't also include `defaults.json`.
* [x] Closes#13323: Meh, the ordering of the keys in this test doesn't matter. Ordering is a map implementation detail. This is fine.
* [x] Ran tests locally
We recently figured that we can drop support for Windows 7. Coincidentally
AtlasEngine never actually supported Windows 7 properly, because it called
`ResizeBuffers` with `DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT`
no matter whether the swap chain was created with it enabled.
The new minimally supported version is Windows 8.1.
66f4f9d had another bug: Just like how we scroll our viewport by `memmove`ing
the `_r.cells` array, we also have to `memmove` the new `_r.cellGlyphMapping`.
Without this fix drawing lots of glyphs while only scrolling slightly
(= not invalidating the entire viewport), would erroneously call
`makeNewest` on glyphs now outside of the viewport. This would cause
actually visible glyphs to be recycled and overwritten by new ones.
## Validation Steps Performed
* Switch to Cascadia Code
* Print some text that fills the glyph atlas
* Scroll down by a few rows
* Write a long "==========" ligature (this quickly fills up
any remaining space in the atlas and exacerbates the issue)
* Unrelated rows don't get corrupted ✅
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.
## Summary of the Pull Request
The xaml file no longer directly accesses the settings model object, and the settings model object is no longer exposed on the view model
## References
#13377
## 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
## Validation Steps Performed
Still works
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
This change adds support for the `IntenseIsBold` rendering setting.
Windows Terminal for instance defaults to `false` here, causing
intense colors to only be bright but not bold.
## Validation Steps Performed
* Set "Intense text style" to "Bright colors"
* Enable AtlasEngine
* Print ``echo "`e[1mtest`e[0m"``
* "test" appears as bright without being bold ✅
## 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
#8000 will change the way we store text from a strict grid/matrix where
one UTF16 character or surrogate pair always equals 1 column with the
possibility of joining exactly 2 to a wide character pair, to a dynamic
buffer where 1 or more characters can form 1 or more columns in any
arbitrary combination. Our long term goal is to properly support both
complex grapheme clusters like Emojis and complex ligatures that a wider
than 2 columns. This change requires us to break our API as
`ReadConsoleOutputA/W` assumes the existence of exactly this grid/matrix
storage. Since we store wide characters like "い" as a single codepoint
that is simply marked as being 2 columns wide in the future, we cannot
reconstruct trailing DBCS characters that were written to the buffer
like we used to. On the other hand this new behavior allows us to
implement better Unicode support and most likely significantly improve
our performance.
### Minor breaking changes
* `ReadConsoleOutputA` will now always **zero** the high byte in
`(CHAR_INFO).Char.UnicodeChar`. Only the `.AsciiChar` can be used
then. This prevents users from storing "additional" data in the
terminal buffer.
* `ReadConsoleOutputA` will now **zero** the `.AsciiChar` if it fails to
convert the Unicode character into an appropriate DBCS.
* Example: It's possible to write "い" into a narrow column despite
being a wide character. In these cases `WriteConsoleOutputA` will
now return `0x00` instead of `0x44` (the lower half of い's code
point `0x3044`).
### Major breaking changes
* `ReadConsoleOutputW` will now repeat the leading Unicode character
twice and ignore the trailing one.
* Example 1: Writing the pair `0x3044 0xabcd` with
`WriteConsoleOutputW` used to yield the same `0x3044 0xabcd` if read
back with `ReadConsoleOutputW`. This worked because conhost
effectively ignored the trailing codepoint, allowing one to
"smuggle" data. In the future this trailing character will be
discarded and produce `0x3044 0x3044` instead.
* Example 2: Writing い with `WriteConsoleOutputA` can be done with
code page 932 (Shift-JIS) and the DBCS `0x82 0xa2`. If read back
with `ReadConsoleOutputW` this would previously yield the two
Unicode characters `0x3044 0xffff`. After this commit it'll yield
`0x3044 0x3044`.
### Alternative approaches
It's possible to "tag"/"mark" written data as originating from
`WriteConsoleOutputA/W` so that it can be reconstructed accurately later
on. However this lead to implementation complexities that we're actively
trying to avoid in the new buffer implementation. Effectively
_everything_ that touches the buffer's text would have to handle these
marks and either write or clear them. Given the most likely small amount
of users who depend on the current quirky behavior, it'd be an
unwarranted maintenance and performance burden and prevent Windows
Terminal to ever truly migrate to full Unicode support.
## Validation Steps Performed
* Adjusted feature tests complete successfully ✅
On occasion, when we submit to the store we get a package rejection
because the app name has changed for the `qps-*` locales. Instead of
constantly reserving new pseudolocalized app names every time the
pseudolocalization seed changes, we should just lock our app name so
that it does not get pseudolocalized.
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
You can find the version in the about dialog, or by running `wt -v` at the commandline.
You can copy the version number from the About dialog. Open the About dialog by opening the menu with the "V" button (to the right of the "+" button that opens a new tab) and choosing About from the end of the list.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
## References and Relevant Issues
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] 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
## PR Checklist
- [ ] Closes #xxx
- [ ] 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
[allow/*.txt](allow/) | Add words to the dictionary | one word per line (only letters and `'`s allowed) | [allow](https://github.com/check-spelling/check-spelling/wiki/Configuration#allow)
[reject.txt](reject.txt) | Remove words from the dictionary (after allow) | grep pattern matching whole dictionary words | [reject](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-reject)
[patterns/*.txt](patterns/) | Patterns to ignore from checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[candidate.patterns](candidate.patterns) | Patterns that might be worth adding to [patterns.txt](patterns.txt) | perl regular expression with optional comment block introductions (all matches will be suggested) | [candidates](https://github.com/check-spelling/check-spelling/wiki/Feature:-Suggest-patterns)
[line_forbidden.patterns](line_forbidden.patterns) | Patterns to flag in checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[expect/*.txt](expect.txt) | Expected words that aren't in the dictionary | one word per line (sorted, alphabetically) | [expect](https://github.com/check-spelling/check-spelling/wiki/Configuration#expect)
[advice.md](advice.md) | Supplement for GitHub comment when unrecognized words are found | GitHub Markdown | [advice](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice)
Note: you can replace any of these files with a directory by the same name (minus the suffix)
and then include multiple files inside that directory (with that suffix) to merge multiple files together.
<!-- See https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice --> <!-- markdownlint-disable MD033 MD041 -->
<details>
<summary>
:pencil2: Contributor please read this
@@ -6,7 +6,7 @@
By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
:warning: The command is written for posix shells. You can copy the contents of each `perl` command excluding the outer `'` marks and dropping any `'"`/`"'` quotation mark pairs into a file and then run `perl file.pl` from the root of the repository to run the code. Alternatively, you can manually insert the items...
:warning: The command is written for posix shells. If it doesn't work for you, you can manually _add_ (one word per line) / _remove_ items to `expect.txt` and the `excludes.txt` files.
If the listed items are:
@@ -20,31 +20,29 @@ See the `README.md` in each directory for more information.
:microscope: You can test your commits **without***appending* to a PR by creating a new branch with that extra change and pushing it to your fork. The [check-spelling](https://github.com/marketplace/actions/check-spelling) action will run in response to your **push** -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. :wink:
<details><summary>:clamp: If you see a bunch of garbage</summary>
If it relates to a ...
<details><summary>well-formed pattern</summary>
<details><summary>If the flagged items are :exploding_head: false positives</summary>
See if there's a [pattern](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns) that would match it.
If items relate to a ...
* binary file (or some other file you wouldn't want to check at all).
If not, try writing one and adding it to a `patterns/{file}.txt`.
Please add a file path to the `excludes.txt` file matching the containing file.
Patterns are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines.
Note that patterns can't match multiline strings.
</details>
<details><summary>binary-ish string</summary>
Please add a file path to the `excludes.txt` file instead of just accepting the garbage.
File paths are Perl 5 Regular Expressions - you can [test](
File paths are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your files.
`^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md](
`^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md](
../tree/HEAD/README.md) (on whichever branch you're using).
</details>
* well-formed pattern.
If you can write a [pattern](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns) that would match it,
try adding it to the `patterns.txt` file.
Patterns are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines.
# Update Lorem based on your content (requires `ge` and `w` from https://github.com/jsoref/spelling; and `review` from https://github.com/check-spelling/check-spelling/wiki/Looking-for-items-locally )
@@ -81,7 +81,7 @@ When you hit "New Issue", select the type of issue closest to what you want to r
Microsoft Windows [Version 10.0.18900.1001]
```
* What tools and apps you're using (e.g. VS 2019, VSCode, etc.)
* What tools and apps you're using (e.g. VS 2022, VSCode, etc.)
* Don't assume we're experts in setting up YOUR environment and don't assume we are experts in `<your distro/tool of choice>`. Teach us to help you!
* **We LOVE detailed repro steps!** What steps do we need to take to reproduce the issue? Assume we love to read repro steps. As much detail as you can stand is probably _barely_ enough detail for us!
* If you're reporting a particular character/glyph not rendering correctly, the specific Unicode codepoint would be MOST welcome (e.g. U+1F4AF, U+4382)
@@ -101,7 +101,7 @@ If you don't have any additional info/context to add but would like to indicate
If you're able & willing to help fix issues and/or implement features, we'd love your contribution!
The best place to start is the list of ["Easy Starter"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+label%3A%22Easy+Starter%22+) issues. These are bugs or tasks that we on the team believe would be easier to implement for someone without any prior experience in the codebase. Once you're feeling more comfortable in the codebase, feel free to just use the ["Help Wanted"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+) label, or just find an issue your interested in and hop in!
The best place to start is the list of ["good first issue"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22++label%3A%22good+first+issue%22+)s. These are bugs or tasks that we on the team believe would be easier to implement for someone without any prior experience in the codebase. Once you're feeling more comfortable in the codebase, feel free to just use the ["Help Wanted"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+) label, or just find an issue you're interested in and hop in!
Generally, we categorize issues in the following way, which is largely derived from our old internal work tracking system:
* ["Bugs"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Bug%22+) are parts of the Terminal & Console that are not quite working the right way. There's code to already support some scenario, but it's not quite working right. Fixing these is generally a matter of debugging the broken functionality and fixing the wrong code.
> * You may need to install the [VC++ v14 Desktop Framework Package](https://docs.microsoft.com/troubleshoot/cpp/c-runtime-packages-desktop-bridge#how-to-install-and-update-desktop-framework-packages).
> This should only be necessary on older builds of Windows 10 and only if you get an error about missing framework packages.
> * Terminal will not auto-update when new builds are released so you will need
> to regularly install the latest Terminal release to receive all the latest
> fixes and improvements!
@@ -65,7 +67,7 @@ the latest Terminal release by installing the `Microsoft.WindowsTerminal`
package:
```powershell
wingetinstall--id=Microsoft.WindowsTerminal-e
wingetinstall--idMicrosoft.WindowsTerminal-e
```
#### Via Chocolatey (unofficial)
@@ -175,7 +177,7 @@ While overhauling Windows Console, we modernized its codebase considerably,
cleanly separating logical entities into modules and classes, introduced some
key extensibility points, replaced several old, home-grown collections and
* You must install the [.NET Framework Targeting Pack](https://docs.microsoft.com/dotnet/framework/install/guide-for-developers#to-install-the-net-framework-developer-pack-or-targeting-pack) to build test projects
<!-- Mandatory. Major version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Mandatory. Major version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
<!-- Mandatory. Minor version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Mandatory. Minor version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
<!-- Mandatory, defaults to 0. Patch version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Mandatory, defaults to 0. Patch version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
<!-- Optional, defaults to empty. Prerelease version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Optional, defaults to empty. Prerelease version number of the PGO database which should match the version of the product. This can be hard-coded or obtained from other sources in build system. -->
<!-- This file is read by XES, which we use in our Release builds. -->
<PropertyGroup Label="Version">
<!--
The Windows 11 build is going to have the same package name, so it *must* have a different version.
The easiest way for us to do this is to add 1 to the revision field.
In short, for a given Terminal build 1.11, we will emit two different versions (assume this is build
4 on day 23 of the year):
- 1.11.234.0 for Windows 10
- 1.11.235.0 for Windows 11
This presents a potential for conflicts if we want to ship two builds produced back to back on the
same day... which is terribly unlikely.
-->
<VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>
@@ -145,7 +145,7 @@ Our only backport successes really come from corporations with massive addressab
It's also costly in terms of time, effort, and testing for us to validate a modification to a released OS. We have a mindbogglingly massive amount of automated machinery dedicated to processing and validating the things that we check in while developing the current OS builds. But it's a special costly ask to spin up some to all of those activities to validate backported fixes. We do it all the time for Patch Tuesday, but in those patches, they only pass through the minimum number of fixes required to maximize the restoration of productivity/security/revenue/etc. because every additional fix adds additional complexity and additional risk.
So from our little team working hard to make developers happy, we virtually never make the cut for servicing. We're sorry, but we hope you can understand. It's just the reality of the situation to say "nope" when people ask for a backport. In our team's ideal world, you would all be running the latest console bits everywhere everytime we make a change. But that's just not how it is today.
So from our little team working hard to make developers happy, we virtually never make the cut for servicing. We're sorry, but we hope you can understand. It's just the reality of the situation to say "nope" when people ask for a backport. In our team's ideal world, you would all be running the latest console bits everywhere everytime we make a change. But that's just not how it is today.
Original Source: https://github.com/microsoft/terminal/issues/279#issuecomment-439179675
(yes, the cmd version is just calling powershell to do the powershell version. Too lazy to convert the rest by hand, I'm already copying from `.vscode\tasks.json`)
Building the package from VS generates the loose layout to begin with, and then registers the loose manifest, skipping the msix stop. It's a lot faster than the commandline inner loop here, unfortunately.
### 2022 Update
The following command can be used to build the terminal package, and then deploy it.
The `bx` will build just the Terminal package, critically, populating the `CascadiaPackage.build.appxrecipe` file. Once that's been built, then the `DeployAppRecipe.exe` command can be used to deploy a loose layout in the same way that Visual Studio does.
Notably, this method of building the Terminal package can't leverage the FastUpToDate check in Visual Studio, so the builds end up being considerably slower for the whole package, as cppwinrt does a lot of work before confirming that it's up to date and doing nothing.
"description":"Sets the file location of the sound played when the application emits a BEL character. If the path is invalid no sound will be played. This property also accepts an array of sounds and the terminal will pick one at random.",
"oneOf":[
{
"type":[
"string",
"null"
]
},
{
"type":"array",
"items":{
"type":"string"
{
"type":[
"string",
"null"
]
},
{
"type":"array",
"items":{
"type":"string"
}
}
}
]
},
},
"AppearanceConfig":{
"properties":{
"colorScheme":{
"description":"The name of a color scheme to use when unfocused.",
"type":"string"
"oneOf":[
{
"$ref":"#/$defs/SchemePair"
},
{
"type":"string"
}
]
},
"foreground":{
"$ref":"#/$defs/Color",
@@ -197,7 +217,7 @@
},
"intenseTextStyle":{
"default":"bright",
"description":"Controls how 'intense' text is rendered. Values are \"bold\", \"bright\", \"all\" and \"none\"",
"description":"Controls how 'intense' text is rendered when unfocused. Values are \"bold\", \"bright\", \"all\" and \"none\"",
"enum":[
"none",
"bold",
@@ -207,8 +227,14 @@
"type":"string"
},
"adjustIndistinguishableColors":{
"description":"When set to true, we will (when necessary) adjust the foreground color to make it more visible, based on the background color.",
"type":"boolean"
"default":"never",
"description":"Setting to adjust the foreground color to make it more visible, based on the background color. When set to \"indexed\", we will only adjust the colors if they came from the color scheme. Other possible values are \"never\" and \"always\".",
"enum":[
"never",
"indexed",
"always"
],
"type":"string"
},
"experimental.retroTerminalEffect":{
"description":"When set to true, enable retro terminal effects when unfocused. This is an experimental feature, and its continued existence is not guaranteed.",
@@ -221,6 +247,21 @@
},
"type":"object"
},
"SchemePair":{
"description":"Contains both a light and dark color scheme for the Terminal to use, depending on the theme of the application.",
"properties":{
"light":{
"default":"Campbell",
"description":"Name of the scheme to use when the app is using light theme",
"type":"string"
},
"dark":{
"default":"Campbell",
"description":"Name of the scheme to use when the app is using dark theme",
"type":"string"
}
}
},
"FontConfig":{
"properties":{
"face":{
@@ -232,7 +273,7 @@
"default":12,
"description":"Size of the font in points.",
"minimum":1,
"type":"integer"
"type":"number"
},
"weight":{
"default":"normal",
@@ -280,6 +321,14 @@
}
},
"additionalProperties":false
},
"cellWidth":{
"$ref":"#/$defs/CSSLengthPercentage",
"description":"Override the width of the terminal's cells. The override works similar to CSS' letter-spacing. It defaults to the natural glyph advance width of the primary font rounded to the nearest pixel."
},
"cellHeight":{
"$ref":"#/$defs/CSSLengthPercentage",
"description":"Override the height of the terminal's cells. The override works similar to CSS' line-height. Defaults to the sum of the natural glyph ascend, descend and line-gap of the primary font rounded to the nearest pixel. The default is usually quite close to setting this to 1.2."
}
},
"type":"object"
@@ -300,6 +349,7 @@
"enum":[
"adjustFontSize",
"clearBuffer",
"closeOtherPanes",
"closeOtherTabs",
"closePane",
"closeTab",
@@ -308,6 +358,7 @@
"commandPalette",
"copy",
"duplicateTab",
"expandSelectionToWord",
"exportBuffer",
"find",
"findMatch",
@@ -370,6 +421,7 @@
"scrollToMark",
"clearMark",
"clearAllMarks",
"experimental.colorSelection",
"unbound"
],
"type":"string"
@@ -524,6 +576,160 @@
},
"type":"object"
},
"NewTabMenuEntryType":{
"enum":[
"source",
"profile",
"folder",
"separator",
"remainingProfiles",
"matchProfiles"
]
},
"NewTabMenuEntry":{
"properties":{
"type":{
"description":"The type of menu entry",
"$ref":"#/$defs/NewTabMenuEntryType"
}
},
"required":[
"type"
],
"type":"object"
},
"FolderEntryInlining":{
"enum":[
"never",
"auto"
]
},
"FolderEntry":{
"description":"A folder entry in the new tab dropdown",
"allOf":[
{
"$ref":"#/$defs/NewTabMenuEntry"
},
{
"properties":{
"type":{
"type":"string",
"const":"folder"
},
"name":{
"type":"string",
"default":"",
"description":"The name of the folder to show in the menu"
},
"icon":{
"$ref":"#/$defs/Icon"
},
"entries":{
"type":"array",
"description":"The entries to put inside this folder",
"minItems":1,
"items":{
"$ref":"#/$defs/NewTabMenuEntry"
}
},
"inline":{
"description":"When set to auto and the folder only has a single entry, the entry will show directly and no folder will be rendered",
"default":"never",
"$ref":"#/$defs/FolderEntryInlining"
},
"allowEmpty":{
"description":"Whether to render a folder without entries, or to hide it",
"default":"false",
"type":"boolean"
}
}
}
]
},
"SeparatorEntry":{
"description":"A separator in the new tab dropdown",
"allOf":[
{
"$ref":"#/$defs/NewTabMenuEntry"
},
{
"properties":{
"type":{
"type":"string",
"const":"separator"
}
}
}
]
},
"ProfileEntry":{
"description":"A profile in the new tab dropdown",
"allOf":[
{
"$ref":"#/$defs/NewTabMenuEntry"
},
{
"properties":{
"type":{
"type":"string",
"const":"profile"
},
"profile":{
"type":"string",
"default":"",
"description":"The name or GUID of the profile to show in this entry"
}
}
}
]
},
"RemainingProfilesEntry":{
"description":"The set of profiles that are not yet explicitly included in another entry, such as the profile or source entries. This entry can be used at most one time!",
"allOf":[
{
"$ref":"#/$defs/NewTabMenuEntry"
},
{
"properties":{
"type":{
"type":"string",
"const":"remainingProfiles"
}
}
}
]
},
"MatchProfilesEntry":{
"description":"A set of profiles all matching the given name, source, or command line, to show in the new tab dropdown",
"allOf":[
{
"$ref":"#/$defs/NewTabMenuEntry"
},
{
"properties":{
"type":{
"type":"string",
"const":"matchProfiles"
},
"name":{
"type":"string",
"default":"",
"description":"The name of the profiles to match"
},
"source":{
"type":"string",
"default":"",
"description":"The source of the profiles to match"
},
"commandline":{
"type":"string",
"default":"",
"description":"The command line of the profiles to match"
}
}
}
]
},
"SwitchToAdjacentTabArgs":{
"oneOf":[
{
@@ -830,6 +1036,43 @@
}
]
},
"ColorSelectionAction":{
"description":"Arguments corresponding to a Color Selection Action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"experimental.colorSelection"
},
"matchMode":{
"type":"string",
"default":"none",
"description":"Specifies if only the selected text should be colored (0), or all instances of selected text (case-insensitive) (1).",
"enum":[
"none",
"all"
]
},
"foreground":{
"$ref":"#/$defs/ColorOrIndex",
"type":"string",
"default":"",
"description":"The foreground color to use, as an RGB value (\"#rrggbb\"), or color index (\"iNN\"). If left unspecified it falls back to the default text foreground color."
},
"background":{
"$ref":"#/$defs/ColorOrIndex",
"type":"string",
"default":"",
"description":"The background color to use, as an RGB value (\"#rrggbb\"), or color index (\"iNN\"). If left unspecified it falls back to the default text background color."
}
}
}
]
},
"OpenSettingsAction":{
"description":"Arguments corresponding to a Open Settings Action",
"allOf":[
@@ -1494,6 +1737,146 @@
}
]
},
"ShowCloseButton":{
"enum":[
"always",
"hover",
"never",
"activeOnly"
],
"type":"string"
},
"ThemeColor":{
"description":"A special kind of color for use in themes. Can be an #rrggbb color, #rrggbbaa color, or a special value. 'accent' is evaluated as the user's selected Accent color in the OS, and 'terminalBackground' will be evaluated as the background color of the active terminal pane.",
"description":"A set of properties for customizing the appearance of the tabs",
"properties":{
"background":{
"description":"The color of a tab when it is the active tab",
"$ref":"#/$defs/ThemeColor"
},
"unfocusedBackground":{
"description":"The color of a tab when it is not the active tab",
"$ref":"#/$defs/ThemeColor"
},
"showCloseButton":{
"description":"Controls the visibility of the close button on the tab",
"$ref":"#/$defs/ShowCloseButton"
}
}
},
"TabRowTheme":{
"additionalProperties":false,
"description":"A set of properties for customizing the appearance of the tab row",
"properties":{
"background":{
"description":"The color of the tab row when the window is the foreground window.",
"$ref":"#/$defs/ThemeColor"
},
"unfocusedBackground":{
"description":"The color of the tab row when the window is inactive",
"$ref":"#/$defs/ThemeColor"
}
}
},
"WindowTheme":{
"additionalProperties":false,
"description":"A set of properties for customizing the appearance of the window itself",
"properties":{
"applicationTheme":{
"description":"Which UI theme the Terminal should use for controls",
"enum":["light","dark","system"],
"type":"string"
},
"useMica":{
"description":"True if the Terminal should use a Mica backdrop for the window. This will apply underneath all controls (including the terminal panes and the titlebar)",
"type":"boolean",
"default":false
}
}
},
"Theme":{
"additionalProperties":false,
"description":"A set of properties for customizing the appearance of the window. This controls things like the titlebar, the tabs, the application theme.",
"properties":{
"name":{
"type":"string",
"description":"The name of the theme. This will be displayed in the settings UI.",
"not":{
"enum":["light","dark","system"]
}
},
"tab":{
"$ref":"#/$defs/TabTheme"
},
"tabRow":{
"$ref":"#/$defs/TabRowTheme"
},
"window":{
"$ref":"#/$defs/WindowTheme"
}
}
},
"ThemePair":{
"additionalProperties":false,
"description":"A pair of Theme names, to allow the Terminal to switch theme based on the OS theme",
"properties":{
"light":{
"type":"string",
"description":"The name of the theme to use when the OS is in Light theme",
"default":"light"
},
"dark":{
"type":"string",
"description":"The name of the theme to use when the OS is in Dark theme",
"default":"dark"
}
}
},
"NewTabMenu":{
"description":"Defines the order and structure of the 'new tab' menu. It can consist of e.g. profiles, folders, and separators.",
"type":"array",
"items":{
"oneOf":[
{
"$ref":"#/$defs/FolderEntry"
},
{
"$ref":"#/$defs/SeparatorEntry"
},
{
"$ref":"#/$defs/ProfileEntry"
},
{
"$ref":"#/$defs/MatchProfilesEntry"
},
{
"$ref":"#/$defs/RemainingProfilesEntry"
}
]
}
},
"Keybinding":{
"additionalProperties":false,
"properties":{
@@ -1605,6 +1988,9 @@
{
"$ref":"#/$defs/AdjustOpacityAction"
},
{
"$ref":"#/$defs/ColorSelectionAction"
},
{
"type":"null"
}
@@ -1707,6 +2093,11 @@
"description":"When set to true, the terminal will focus the pane on mouse hover.",
"type":"boolean"
},
"compatibility.isolatedMode":{
"default":false,
"description":"When set to true, Terminal windows will not be able to interact with each other (including global hotkeys, tab drag/drop, running commandlines in existing windows, etc.). This is a compatibility escape hatch for users who are running into certain windowing issues.",
"type":"boolean"
},
"copyFormatting":{
"default":true,
"description":"When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard. An array of specific formats can also be used. Supported array values include `html` and `rtf`. Plain text is always copied.",
@@ -1727,14 +2118,9 @@
"description":"When set to true, URLs will be detected by the Terminal. This will cause URLs to underline on hover and be clickable by pressing Ctrl.",
"type":"boolean"
},
"experimental.autoMarkPrompts":{
"experimental.enableColorSelection":{
"default":false,
"description":"When set to true, prompts will automatically be marked.",
"type":"boolean"
},
"experimental.showMarksOnScrollbar":{
"default":false,
"description":"When set to true, marks added to the buffer via the addMark action will appear on the scrollbar.",
"description":"When set to true, adds preset \"Color Selection\" actions (keybindings) to allow colorizing selected text via keystroke, similar to the legacy conhost EnableColorSelection feature (such as alt+6 to color the selection red).",
"type":"boolean"
},
"disableAnimations":{
@@ -1784,6 +2170,11 @@
"description":"When set to true, the background image for the currently focused profile is expanded to encompass the entire window, beneath other panes.",
"type":"boolean"
},
"compatibility.reloadEnvironmentVariables":{
"default":true,
"description":"When set to true, when opening a new tab or pane it will get reloaded environment variables.",
"type":"boolean"
},
"initialCols":{
"default":120,
"description":"The number of columns displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
@@ -1874,20 +2265,32 @@
},
"type":"array"
},
"newTabMenu":{
"$ref":"#/$defs/NewTabMenu"
},
"language":{
"default":"",
"description":"Sets an override for the app's preferred language, expressed as a BCP-47 language tag like en-US.",
"type":"string"
},
"theme":{
"default":"system",
"description":"Sets the theme of the application. The special value \"system\" refers to the active Windows system theme.",
"enum":[
"light",
"dark",
"system"
],
"type":"string"
"default":"dark",
"description":"Sets the theme of the application. This value should be the name of one of the themes defined in `themes`. The Terminal also includes the themes `dark`, `light`, and `system`.",
"oneOf":[
{
"type":"string"
},
{
"$ref":"#/$defs/ThemePair"
}
]
},
"themes":{
"description":"The list of available themes",
"items":{
"$ref":"#/$defs/Theme"
},
"type":"array"
},
"showTabsInTitlebar":{
"default":true,
@@ -1970,15 +2373,14 @@
"type":"string"
},
"newTabPosition":{
"default":"atTheEnd",
"description":"Specifies position of the new tab. Possible values are \"atTheEnd\" and \"afterCurrentTab\".",
"default":"afterLastTab",
"description":"Position of newly created tabs. Possible values are \"afterLastTab\" and \"afterCurrentTab\".",
"enum":[
"atTheEnd",
"afterLastTab",
"afterCurrentTab"
],
"type":"string"
}
},
},
"autoHideWindow":{
"default":false,
"description":"If enabled, Terminal window will be hidden as soon as it loses focus.",
@@ -2101,14 +2503,15 @@
"$ref":"#/$defs/BellSound"
},
"closeOnExit":{
"default":"graceful",
"description":"Sets how the profile reacts to termination or failure to launch. Possible values:\n -\"graceful\" (close when exit is typed or the process exits normally)\n -\"always\" (always close)\n -\"never\" (never close).\ntrue and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
"default":"automatic",
"description":"Sets how the profile reacts to termination or failure to launch. Possible values:\n -\"graceful\" (close when exit is typed or the process exits normally)\n -\"always\" (always close)\n -\"automatic\" (behave as \"graceful\" only for processes launched by terminal, behave as \"always\" otherwise)\n -\"never\" (never close).\ntrue and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
"oneOf":[
{
"enum":[
"never",
"graceful",
"always"
"always",
"automatic"
],
"type":"string"
},
@@ -2120,7 +2523,14 @@
"colorScheme":{
"default":"Campbell",
"description":"Name of the terminal color scheme to use. Color schemes are defined under \"schemes\".",
"type":"string"
"oneOf":[
{
"$ref":"#/$defs/SchemePair"
},
{
"type":"string"
}
]
},
"commandline":{
"description":"Executable used in the profile.",
@@ -2165,6 +2575,18 @@
"default":false,
"description":"When true, this profile should always open in an elevated context. If the window isn't running as an Administrator, then a new elevated window will be created."
},
"environment":{
"description":"Key-value pairs representing environment variables to set. Environment variable names are not case sensitive. You can reference existing environment variable names by enclosing them in literal percent characters (e.g. %PATH%).",
"type":"object",
"additionalProperties":{
"type":"string"
}
},
"experimental.autoMarkPrompts":{
"default":false,
"description":"When set to true, prompts will automatically be marked.",
"type":"boolean"
},
"experimental.connection.passthroughMode":{
"description":"When set to true, directs the PTY for this connection to use pass-through mode instead of the original Conhost PTY simulation engine. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean"
@@ -2173,14 +2595,19 @@
"description":"When set to true, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean"
},
"experimental.showMarksOnScrollbar":{
"default":false,
"description":"When set to true, marks added to the buffer via the addMark action will appear on the scrollbar.",
"type":"boolean"
},
"experimental.pixelShaderPath":{
"description":"Use to set a path to a pixel shader to use with the Terminal. Overrides `experimental.retroTerminalEffect`. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"string"
},
"experimental.useAtlasEngine":{
"description":"Enable using the experimental new rendering engine for this profile. This is an experimental feature, and its continued existence is not guaranteed.",
"useAtlasEngine":{
"description":"Windows Terminal 1.16 and later ship with a new, performant text renderer. Set this to false to revert back to the old text renderer.",
"type":"boolean",
"default":false
"default":true
},
"fontFace":{
"default":"Cascadia Mono",
@@ -2192,7 +2619,7 @@
"default":12,
"description":"[deprecated] Define 'size' within the 'font' object instead.",
"minimum":1,
"type":"integer",
"type":"number",
"deprecated":true
},
"fontWeight":{
@@ -2223,6 +2650,17 @@
],
"deprecated":true
},
"intenseTextStyle":{
"default":"bright",
"description":"Controls how 'intense' text is rendered. Values are \"bold\", \"bright\", \"all\" and \"none\"",
"enum":[
"none",
"bold",
"bright",
"all"
],
"type":"string"
},
"foreground":{
"$ref":"#/$defs/Color",
"default":"#cccccc",
@@ -2276,15 +2714,22 @@
]
},
"adjustIndistinguishableColors":{
"description":"When set to true, we will (when necessary) adjust the foreground color to make it more visible, based on the background color.",
"type":"boolean"
"default":"never",
"description":"Setting to adjust the foreground color to make it more visible, based on the background color. When set to \"indexed\", we will only adjust the colors if they came from the color scheme. Other possible values are \"never\" and \"always\".",
"enum":[
"never",
"indexed",
"always"
],
"type":"string"
},
"scrollbarState":{
"default":"visible",
"description":"Defines the visibility of the scrollbar.",
"enum":[
"visible",
"hidden"
"hidden",
"always"
],
"type":"string"
},
@@ -2318,7 +2763,10 @@
},
"startingDirectory":{
"description":"The directory the shell starts in when it is loaded.",
"type":"string"
"type":[
"string",
"null"
]
},
"suppressApplicationTitle":{
"description":"When set to true, tabTitle overrides the default title of the tab and any title change messages from the application will be suppressed. When set to false, tabTitle behaves as normal.",
Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existent feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/nonexistent feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
@@ -138,7 +138,7 @@ The delegation repeats the same dance as above as well:
The terminal will be its own complete presentation and input solution on top of a ConPTY connection, separating the concerns between API servicing and the user experience.
Today the Terminal knows how to start and then launches a ConPTY under it. The Terminal will need to be updated to accept a pre-existing ConPTY connection on launch (or when the multi-process model arrives, as an inbound connection), and connect that to a new tab/pane instead of using the `winconpty.lib` libraries to make its own.
Today the Terminal knows how to start and then launches a ConPTY under it. The Terminal will need to be updated to accept a preexisting ConPTY connection on launch (or when the multi-process model arrives, as an inbound connection), and connect that to a new tab/pane instead of using the `winconpty.lib` libraries to make its own.
For now, I'm considering only the fresh-start scenario.
- The Terminal will have to detect the inbound connection through ~~its argument parsing (or through~~ a new entrypoint in the COM alternative ~~)~~ and store the PTY in/out/signal handles for that connection in the startup arguments information
@@ -201,7 +201,7 @@ Concerns:
### Accessibility
Accessibility applications are the most likely to resort to a method of spelunking the process tree or window handles to attempt to find content to read out. Presuming they have hardcoded rules for console-type applications, these algorithms could be surprised by the substitution of another terminal environment.
Accessibility applications are the most likely to resort to a method of spelunking the process tree or window handles to attempt to find content to read out. Presuming they have hard-coded rules for console-type applications, these algorithms could be surprised by the substitution of another terminal environment.
The major players here that I am considering are NVDA, JAWS, and Narrator. As far as I am aware, all of these applications attempt to drive their interactivity through UI Automation where possible. And we have worked with all of these applications in the past in improving their support for both `conhost.exe` and the Windows Terminal product. I have relatively high confidence that we will be able to work with them again to help update these assistive products to understand the new UI delegation, if necessary.
This spec describes a new set of key bindings that allows the user to create and update a selection without the use of a mouse or stylus.
## Inspiration
ConHost allows the user to modify a selection using the keyboard. Holding `Shift` allows the user to move the second selection endpoint in accordance with the arrow keys. The selection endpoint updates by one cell per key event, allowing the user to refine the selected region.
### Creating a selection
Mark Mode is a ConHost feature that allows the user to create a selection using only the keyboard. In CMD, pressing <kbd>ctrl+m</kbd> enters mark mode. The current cursor position becomes a selection endpoint. The user can use the arrow keys to move that endpoint. While the user then holds <kbd>shift</kbd>, the selection endpoint ('start') is anchored to it's current position, and the arrow keys move the other selection endpoint ('end').
Additionally, pressing <kbd>shift+arrow</kbd> also initiates a selection, but it anchors the first selection endpoint to the cursor position.
Other terminal emulators have different approaches to this feature. iTerm2, for example, has Copy Mode (documentation [linked here](https://iterm2.com/documentation-copymode.html)). Here, <kbd>cmd+shift+c</kbd> makes the current cursor position become a selection endpoint. The arrow keys can be used to move that endpoint. However, unlike Mark Mode, a key binding <kbd>c+space</kbd> is used to change the start/stop selecting. The first time it's pressed, the 'start' endpoint is anchored. The second time it's pressed, the 'end' endpoint is set. After this, you can still move a cursor, but the selection persists until a new selection is created (either by pressing the key binding again, or using the mouse).
Though tmux is not a terminal emulator, it does also have Copy Mode that behaves fairly similarly to that of iTerm2's.
## Solution Design
The fundamental solution design for keyboard selection is that the responsibilities between the Terminal Control and Terminal Core must be very distinct. The Terminal Control is responsible for handling user interaction and directing the Terminal Core to update the selection. The Terminal Core will need to update the selection according to the direction of the Terminal Control. Terminal Core maintains the state of the selection.
Relatively recently, TerminalControl was split into `TerminalControl`, `ControlInteractivity`, and `ControlCore`. Changes made to `ControlInteractivity`, `ControlCore`, and below propagate functionality to all consumers, meaning that the WPF terminal would benefit from these changes with no additional work required.
### Fundamental Terminal Control Changes
`ControlCore::TrySendKeyEvent()` is responsible for handling the key events after key bindings are dealt with in `TermControl`. At the time of writing this spec, there are 2 cases handled in this order:
- Clear the selection (except in a few key scenarios)
- Send Key Event
The first branch will be updated to _modify_ the selection instead of usually _clearing_ it. This will happen by converting the key event into parameters to forward to `TerminalCore`, which then updates the selection appropriately.
#### Abandoned Idea: Make keyboard selection a collection of standard keybindings
One idea is to introduce an `updateSelection` action that conditionally works if a selection is active (similar to the `copy` action). For these key bindings, if there is no selection, the key events are forwarded to the application.
Thanks to Keybinding Args, there would only be 1 new command:
| Action | Keybinding Args | Description |
|--|--|--|
| `updateSelection` | | If a selection exists, moves the last selection endpoint. |
| | `Enum direction { up, down, left, right }` | The direction the selection will be moved in. |
| | `Enum mode { char, word, view, buffer }` | The context for which to move the selection endpoint to. (defaults to `char`) |
By default, the following keybindings will be set:
These are in accordance with ConHost's keyboard selection model.
This idea was abandoned due to several reasons:
1. Keyboard selection should be a standard way to interact with a terminal across all consumers (i.e. WPF control, etc.)
2. There isn't really another set of key bindings that makes sense for this. We already hard-coded <kbd>ESC</kbd> as a way to clear the selection. This is just an extension of that.
3. Adding 12 conditionally effective key bindings takes the spot of 12 potential non-conditional key bindings. It would be nice if a different key binding could be set when the selection is not active, but that makes the settings design much more complicated.
4. 12 new items in the command palette is also pretty excessive.
5. If proven wrong when this is in WT Preview, we can revisit this and make them customizable then. It's better to add the ability to customize it later than take it away.
#### Abandoned Idea: Make keyboard selection a simulation of mouse selection
It may seem that some effort can be saved by making the keyboard selection act as a simulation of mouse selection. There is a union of mouse and keyboard activity that can be represented in a single set of selection motion interfaces that are commanded by the TermControl's Mouse/Keyboard handler and adapted into appropriate motions in the Terminal Core.
However, the mouse handler operates by translating a pixel coordinate on the screen to a text buffer coordinate. This would have to be rewritten and the approach was deemed unworthy.
### Fundamental Terminal Core Changes
The Terminal Core will need to expose a `UpdateSelection()` function that is called by the keybinding handler. The following parameters will need to be passed in:
-`enum SelectionDirection`: the direction that the selection endpoint will attempt to move to. Possible values include `Up`, `Down`, `Left`, and `Right`.
-`enum SelectionExpansion`: the selection expansion mode that the selection endpoint will adhere to. Possible values include `Char`, `Word`, `View`, `Buffer`.
#### Moving by Cell
For `SelectionExpansion = Char`, the selection endpoint will be updated according to the buffer's output pattern. For **horizontal movements**, the selection endpoint will attempt to move left or right. If a viewport boundary is hit, the endpoint will wrap appropriately (i.e.: hitting the left boundary moves it to the last cell of the line above it).
For **vertical movements**, the selection endpoint will attempt to move up or down. If a **viewport boundary** is hit and there is a scroll buffer, the endpoint will move and scroll accordingly by a line.
If a **buffer boundary** is hit, the endpoint will not move. In this case, however, the event will still be considered handled.
**NOTE**: An important thing to handle properly in all cases is wide glyphs. The user should not be allowed to select a portion of a wide glyph; it should be all or none of it. When calling `_ExpandWideGlyphSelection` functions, the result must be saved to the endpoint.
#### Moving by Word
For `SelectionExpansion = Word`, the selection endpoint will also be updated according to the buffer's output pattern, as above. However, the selection will be updated in accordance with "chunk selection" (performing a double-click and dragging the mouse to expand the selection). For **horizontal movements**, the selection endpoint will be updated according to the `_ExpandDoubleClickSelection` functions. The result must be saved to the endpoint. As before, if a boundary is hit, the endpoint will wrap appropriately. See [Future Considerations](#FutureConsiderations) for how this will interact with line wrapping.
For **vertical movements**, the movement is a little more complicated than before. The selection will still respond to buffer and viewport boundaries as before. If the user is trying to move up, the selection endpoint will attempt to move up by one line, then selection will be expanded leftwards. Alternatively, if the user is trying to move down, the selection endpoint will attempt to move down by one line, then the selection will be expanded rightwards.
#### Moving by Viewport
For `SelectionExpansion = View`, the selection endpoint will be updated according to the viewport's height. Horizontal movements will be updated according to the viewport's width, thus resulting in the endpoint being moved to the left/right boundary of the viewport.
#### Moving by Buffer
For `SelectionExpansion = Buffer`, the selection endpoint will be moved to the beginning or end of all the text within the buffer. If moving up or left, set the position to 0,0 (the origin of the buffer). If moving down or right, set the position to the last character in the buffer.
**NOTE**: In all cases, horizontal movements attempting to move past the left/right viewport boundaries result in a wrap. Vertical movements attempting to move past the top/bottom viewport boundaries will scroll such that the selection is at the edge of the screen. Vertical movements attempting to move past the top/bottom buffer boundaries will be clamped to be within buffer boundaries.
**NOTE**: If `copyOnSelect` is enabled, we need to make sure we **DO NOT** update the clipboard on every change in selection. The user must explicitly choose to copy the selected text from the buffer.
### Mark Mode
Mark Mode is a mode where the user can create and modify a selection using only the keyboard.
When no selection is present, the user may use the `markMode` action to enter mark mode. Upon doing so, a selection will be created at the current cursor position.
When in mark mode, the user may...
- press <kbd>ESC</kbd> to clear the selection and exit mark mode
- invoke the `markMode` action to exit mark mode
- invoke the `copy` action (this includes right-clicking the terminal) to copy the selected text, clear the selection, and exit mark mode
- move the cursor in the following ways:
- arrow keys --> move by character
- ctrl + left/right --> move by word
- ctrl + home/end --> move to the beginning/end of the buffer
- home/end --> move to the beginning/end of the line respectively
- pgup/pgdn --> move up/down by viewport respectively
- expand the selection in the following ways:
- shift + arrow keys --> move the "end" endpoint by character
- ctrl + shift + left/right --> move the "end" endpoint by word
- ctrl + shift + home/end --> move the "end" endpoint to the beginning/end of the buffer
- shift + home/end --> move the "end" endpoint to the beginning/end of the line respectively
- shift + pgup/pgdn --> move the "end" endpoint up/down by viewport respectively
As with mouse selections, keybindings are still respected and pressing a key that is not bound to a keybinding (or mentioned above) will clear the selection and exit mark mode.
#### Corner cases
- In mark mode, if a selection was created via the keyboard, moving the cursor moves at the "end" endpoint. This is consistent with conhost.
- If a user creates a selection using the mouse, then enters mark mode, mark mode inherits the existing selection as if it was made using the keyboard.
- If `copyOnSelect` is enabled, the selection is copied when the selection operation is "complete". Thus, the selection is copied when the `copy` keybinding is used or the selection is copied using the mouse.
- If `copyOnSelect` is enabled, `ESC` is interpreted as "cancelling" the selection, so nothing is copied. Keys that generate input are also interpreted as "cancelling" the selection. Only the `copy` keybinding or copying using the mouse is considered "completing" the selection operation, and copying the content to the clipboard.
**NOTE** - Related to #3884:
If the user has chosen to have selections persist after a copy operation, the selection created by Copy Mode is treated no differently than one created with the mouse. The selection will persist after a copy operation. However, if the user exits Copy Mode in any of the other situations, the selection is cleared.
#### Block Selection
A user can normally create a block selection by holding <kbd>alt</kbd> then creating a selection.
If the user is in Mark Mode, and desires to make a block selection, they can use the `toggleBlockSelection()` action. `toggleBlockSelection()` takes an existing selection, and transforms it into a block selection (or vice-versa).
All selections created in Mark Mode will have block selection disabled by default.
#### Rendering during Copy Mode
Since we are just moving the selection endpoints, rendering the selection rects should operate normally. We need to ensure that we still scroll when we move a selection point past the top/bottom of the viewport.
In ConHost, output would be paused when a selection was present. Windows Terminal does not pause the output when a selection is present, however, it does not scroll to the new output.
#### Interaction with Mouse Selection
If a selection exists, the user is basically already in Copy Mode. The user should be modifying the "end" endpoint of the selection when using the `updateSelection()` bindings. The existing selection should not be cleared (contrary to prior behavior). However, the half-y-beam will not be drawn. Once the user presses the `copyMode` or `moveSelectionPoint` keybinding, the half-y-beam is drawn on the targeted endpoint (which will then be "start").
During Copy Mode, if the user attempts to create a selection using the mouse, any existing selections are cleared and the mouse creates a selection normally. However, contrary to prior behavior, the user will still be in Copy Mode. The target endpoint being modified in Copy Mode, however, will be the "end" endpoint of the selection, instead of the cursor (as explained earlier in the flowchart).
#### Abandoned Idea: Copy Mode
Copy Mode is a more complex version of Mark Mode that is intended to provide a built-in way to switch the active selection endpoint. This idea was abandoned because we would then run into a user education issue. Rather than reinventing the wheel, selection should feel natural like that of a text editor, and any diversion from that model should be introduced separately (i.e. keybindings). Doing so ensures that users can "hit the ground running" when trying to make a selection, but won't be hindered by new functionality that is available.
Copy Mode is a mode where the user can create and modify a selection using only the keyboard. The following flowchart covers how the new `copymode()` action works:
**NOTE**: `copyMode()` refers to the action, whereas `updateSelection()` refers to the underlying function that is being called in the code.
If a selection is not active, a "start" and "end" selection point is created at the cursor position. `updateSelection()` calls then move "start" and "end" together as one position.
Invoking `copyMode()` again, will then anchor "start" (meaning that it will be kept in place). Subsequent `updateSelection()` calls move the "end" selection point.
Invoking `copyMode()` essentially cycles between which selection point is targeted.
## UI/UX Design
### Key Bindings
| Action | Keybinding Args | Description |
|--|--|--|
| `selectAll` | none | Select the entire text buffer. |
| `markMode` | none | Toggle mark mode. If no selection exists, create a selection at the cursor position. Otherwise, use the existing selection as one in mark mode. |
| `toggleBlockSelection` | none | Transform the existing selection between a block selection and a line selection. |
| `switchSelectionEndpoint` | none | If a selection is present, switch which selection endpoint is targeted when in mark mode or another keyboard selection mode (i.e. modified a mouse selection using the keyboard). |
By default, the following key binding will be set:
```JS
{"command":"selectAll","keys":"ctrl+shift+a"},
// Copy Mode
{"command":"copyMode","keys":"ctrl+shift+m"},
{"command":"toggleBlockSelection"},
{"command":"switchSelectionEndpoint"},
```
### Selection Markers
A y-beam will be used to identify which selection endpoint is currently being moved when in mark mode. The y-beam will match the cursor color and the font size so that it essentially fills a cell in the buffer.
When we're moving the cursor (this happens when mark mode is entered from no existing selection), a full y-beam will be displayed at the cursor position.
When <kbd>shift</kbd> is held, we're expanding the selection. In this case, the y-beam will be split, and the relevant half will be rendered on the active endpoint functioning as a selection marker.
If the selection is up against the end (or beginning) of the line, the selection marker can't be rendered normally because there is no space to render it off the side of the terminal. Instead, the selection marker will be horizontally flipped. Alternatively, it can be rendered on the next available cell (i.e. end of line translates to the beginning of the next line), but that would cause issues when the selection is positioned at the beginning or end of the buffer, thus the idea was abandoned.
If the active endpoint crosses the inactive endpoint, the selection marker will be flipped. In a sense, the flag will always point away from the selection.
The y-beam doesn't make as much sense for block selections, so instead an L-shaped marker will be placed hugging the corner of the active selection endpoint.
**NOTE:** Both half y-beams could have been presented as shown in the image below. This idea was omitted because then there is no indication for which half y-beam is currently focused.
When mark mode is enabled, the cursor will stop blinking.
## Capabilities
### Accessibility
Using the keyboard is generally a more accessible experience than using the mouse. Being able to modify a selection by using the keyboard is a good first step towards making selecting text more accessible.
We will be expected to send "selection changed" events via UIA every time the cursor moves or selection updates (both are considered the same event).
### Security
N/A
### Reliability
With regards to the Terminal Core, the newly introduced code should rely on already existing and tested code. Thus no crash-related bugs are expected.
With regards to Terminal Control and the settings model, crash-related bugs are not expected. However, ensuring that the selection is updated and cleared in general use-case scenarios must be ensured.
### Compatibility
N/A
### Performance, Power, and Efficiency
N/A
## Potential Issues
### Grapheme Clusters
When grapheme cluster support is inevitably added to the Text Buffer, moving by "cell" is expected to move by "character" or "cluster". This is similar to how wide glyphs are handled today. Either all of it is selected, or none of it.
### Circling the buffer
As usual, if the buffer is circling, the selection should be updated to follow the content (and "scroll up" appropriately).
In the event that one endpoint "scrolls" off the buffer, we must clamp "start" to the buffer origin. Conversely, in the event that both endpoints "scroll" off the buffer, the selection must be considered cleared.
## Future considerations
### Word Selection Wrap
At the time of writing this spec, expanding or moving by word is interrupted by the beginning or end of the line, regardless of the wrap flag being set. In the future, selection and the accessibility models will respect the wrap flag on the text buffer.
This spec describes a new set of non-configurable keybindings that allows the user to update a selection without the use of a mouse or stylus.
## Inspiration
ConHost allows the user to modify a selection using the keyboard. Holding `Shift` allows the user to move the second selection endpoint in accordance with the arrow keys. The selection endpoint updates by one cell per key event, allowing the user to refine the selected region.
Mark mode allows the user to create a selection using only the keyboard, then edit it as mentioned above.
## Solution Design
The fundamental solution design for keyboard selection is that the responsibilities between the Terminal Control and Terminal Core must be very distinct. The Terminal Control is responsible for handling user interaction and directing the Terminal Core to update the selection. The Terminal Core will need to update the selection according to the preferences of the Terminal Control.
Relatively recently, TerminalControl was split into `TerminalControl`, `ControlInteractivity`, and `ControlCore`. Changes made to `ControlInteractivity`, `ControlCore`, and below propagate functionality to all consumers, meaning that the WPF terminal would benefit from these changes with no additional work required.
### Fundamental Terminal Control Changes
`ControlCore::TrySendKeyEvent()` is responsible for handling the key events after key bindings are dealt with in `TermControl`. At the time of writing this spec, there are 2 cases handled in this order:
- Clear the selection (except in a few key scenarios)
- Send Key Event
The first branch will be updated to _modify_ the selection instead of usually _clearing_ it. This will happen by converting the key event into parameters to forward to `TerminalCore`, which then updates the selection appropriately.
#### Idea: Make keyboard selection a collection of standard keybindings
One idea is to introduce an `updateSelection` action that conditionally works if a selection is active (similar to the `copy` action). For these key bindings, if there is no selection, the key events are forwarded to the application.
Thanks to Keybinding Args, there would only be 1 new command:
| Action | Keybinding Args | Description |
|--|--|--|
| `updateSelection` | | If a selection exists, moves the last selection endpoint. |
| | `Enum direction { up, down, left, right }` | The direction the selection will be moved in. |
| | `Enum mode { char, word, view, buffer }` | The context for which to move the selection endpoint to. (defaults to `char`) |
By default, the following keybindings will be set:
These are in accordance with ConHost's keyboard selection model.
This idea was abandoned due to several reasons:
1. Keyboard selection should be a standard way to interact with a terminal across all consumers (i.e. WPF control, etc.)
2. There isn't really another set of key bindings that makes sense for this. We already hardcoded <kbd>ESC</kbd> as a way to clear the selection. This is just an extension of that.
3. Adding 12 conditionally effective key bindings takes the spot of 12 potential non-conditional key bindings. It would be nice if a different key binding could be set when the selection is not active, but that makes the settings design much more complicated.
4. 12 new items in the command palette is also pretty excessive.
5. If proven wrong when this is in WT Preview, we can revisit this and make them customizable then. It's better to add the ability to customize it later than take it away.
#### Idea: Make keyboard selection a simulation of mouse selection
It may seem that some effort can be saved by making the keyboard selection act as a simulation of mouse selection. There is a union of mouse and keyboard activity that can be represented in a single set of selection motion interfaces that are commanded by the TermControl's Mouse/Keyboard handler and adapted into appropriate motions in the Terminal Core.
However, the mouse handler operates by translating a pixel coordinate on the screen to a text buffer coordinate. This would have to be rewritten and the approach was deemed unworthy.
### Fundamental Terminal Core Changes
The Terminal Core will need to expose a `UpdateSelection()` function that is called by the keybinding handler. The following parameters will need to be passed in:
-`enum SelectionDirection`: the direction that the selection endpoint will attempt to move to. Possible values include `Up`, `Down`, `Left`, and `Right`.
-`enum SelectionExpansion`: the selection expansion mode that the selection endpoint will adhere to. Possible values include `Char`, `Word`, `View`, `Buffer`.
#### Moving by Cell
For `SelectionExpansion = Char`, the selection endpoint will be updated according to the buffer's output pattern. For **horizontal movements**, the selection endpoint will attempt to move left or right. If a viewport boundary is hit, the endpoint will wrap appropriately (i.e.: hitting the left boundary moves it to the last cell of the line above it).
For **vertical movements**, the selection endpoint will attempt to move up or down. If a **viewport boundary** is hit and there is a scroll buffer, the endpoint will move and scroll accordingly by a line.
If a **buffer boundary** is hit, the endpoint will not move. In this case, however, the event will still be considered handled.
**NOTE**: An important thing to handle properly in all cases is wide glyphs. The user should not be allowed to select a portion of a wide glyph; it should be all or none of it. When calling `_ExpandWideGlyphSelection` functions, the result must be saved to the endpoint.
#### Moving by Word
For `SelectionExpansion = Word`, the selection endpoint will also be updated according to the buffer's output pattern, as above. However, the selection will be updated in accordance with "chunk selection" (performing a double-click and dragging the mouse to expand the selection). For **horizontal movements**, the selection endpoint will be updated according to the `_ExpandDoubleClickSelection` functions. The result must be saved to the endpoint. As before, if a boundary is hit, the endpoint will wrap appropriately. See [Future Considerations](#FutureConsiderations) for how this will interact with line wrapping.
For **vertical movements**, the movement is a little more complicated than before. The selection will still respond to buffer and viewport boundaries as before. If the user is trying to move up, the selection endpoint will attempt to move up by one line, then selection will be expanded leftwards. Alternatively, if the user is trying to move down, the selection endpoint will attempt to move down by one line, then the selection will be expanded rightwards.
#### Moving by Viewport
For `SelectionExpansion = View`, the selection endpoint will be updated according to the viewport's height. Horizontal movements will be updated according to the viewport's width, thus resulting in the endpoint being moved to the left/right boundary of the viewport.
#### Moving by Buffer
For `SelectionExpansion = Buffer`, the selection endpoint will be moved to the beginning or end of all the text within the buffer. If moving up or left, set the position to 0,0 (the origin of the buffer). If moving down or right, set the position to the last character in the buffer.
**NOTE**: In all cases, horizontal movements attempting to move past the left/right viewport boundaries result in a wrap. Vertical movements attempting to move past the top/bottom viewport boundaries will scroll such that the selection is at the edge of the screen. Vertical movements attempting to move past the top/bottom buffer boundaries will be clamped to be within buffer boundaries.
Every combination of the `SelectionDirection` and `SelectionExpansion` will map to a keybinding. These pairings are shown below in the UI/UX Design --> Keybindings section.
**NOTE**: If `copyOnSelect` is enabled, we need to make sure we **DO NOT** update the clipboard on every change in selection. The user must explicitly choose to copy the selected text from the buffer.
## UI/UX Design
### Key Bindings
There will only be 1 new command that needs to be added:
| Action | Keybinding Args | Description |
|--|--|--|
| `selectAll` | | Select the entire text buffer.
By default, the following key binding will be set:
```JS
{"command":"selectAll","keys":"ctrl+shift+a"},
```
## Capabilities
### Accessibility
Using the keyboard is generally a more accessible experience than using the mouse. Being able to modify a selection by using the keyboard is a good first step towards making selecting text more accessible.
### Security
N/A
### Reliability
With regards to the Terminal Core, the newly introduced code should rely on already existing and tested code. Thus no crash-related bugs are expected.
With regards to Terminal Control and the settings model, crash-related bugs are not expected. However, ensuring that the selection is updated and cleared in general use-case scenarios must be ensured.
### Compatibility
N/A
### Performance, Power, and Efficiency
## Potential Issues
### Grapheme Clusters
When grapheme cluster support is inevitably added to the Text Buffer, moving by "cell" is expected to move by "character" or "cluster". This is similar to how wide glyphs are handled today. Either all of it is selected, or none of it.
## Future considerations
### Word Selection Wrap
At the time of writing this spec, expanding or moving by word is interrupted by the beginning or end of the line, regardless of the wrap flag being set. In the future, selection and the accessibility models will respect the wrap flag on the text buffer.
## Mark Mode
This functionality will be expanded to create a feature similar to Mark Mode. This will allow a user to create a selection using only the keyboard.
@@ -114,7 +114,7 @@ The jumplist will have to be saved each time a profile change occurs but the fre
#### Should it open a new instance of the terminal or open in a new tab?
#### What should happen if a nonexistent profile is launched
#### What should happen if a nonexistent profile is launched
The jumplist is only updated when the application is running so the profiles could be modified or deleted outside and the jumplist will not be updated. Handling will be done by whatever handles the command line parsing.
## Future considerations
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
