## Summary of the Pull Request
Adds implicit stdexcept header include to u8u16test tool.
## PR Checklist
* [x] Closes regression introduced when moving from VS 16.5 to VS 16.6 (which the CI did of its own accord)
* [x] I work here.
* [x] Built it.
* [x] No doc.
* [x] Am core contributor.
## Detailed Description of the Pull Request / Additional comments
In VS 16.5, the <stdexcept> header was pulled in by `<string>` or `<string_view>` or `<array>` or `<algorithm>` implicitly. In VS 16.6, that's gone. No one wrote it in the header because it was just automatically there in the past. Now I wrote it in the header.
## Validation Steps Performed
* [x] Built it on my machine after upgrading to VS `16.6.0`.
* [x] Built it in CI.
Fixes#6079 by implementing support for IStorageItem clipboard contents. Manually tested, seems to work for both types of address-copying from Explorer (as well as normal text).
## PR Checklist
* [x] Closes#6079
* Not sure what tests would be useful here, it's mostly to do with what Explorer's doing
Not enormously familiar with C++ or this codebase, so happy to make changes as requested.
## Validation Steps Performed
Ran the terminal, pasted from several different sources (explorer's various copy functions + plaintext)
## Summary of the Pull Request
When using an _Input Method Editor_ in conhost for East Asian languages, the text cursor is temporarily hidden while the characters are being composed. When the composition is complete, the cursor visibility is meant to be restored, but that doesn't always happen if the IME composition is cancelled. This PR makes sure the cursor visibility is always restored, regardless of how the IME is closed.
## PR Checklist
* [x] Closes#810
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Requires documentation to be 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.
## Detailed Description of the Pull Request / Additional comments
The original implementation hid the cursor whenever `ConsoleImeInfo::WriteCompMessage` was called (which could be multiple times in the course of a composition), and then only restored the visibility when `ConsoleImeInfo::WriteResultMessage` was called. If a composition is cancelled, though, `WriteResultMessage` would never be called, so the cursor visibility wouldn't be restored.
I've now made the `SaveCursorVisibility` and `RestoreCursorVisibility` methods public, so they can instead be called from the `ImeStartComposition` and `ImeEndComposition` functions. This makes sure `RestoreCursorVisibility` is always called, regardless of how the composition ended, and `SaveCursorVisibility` is only called once at the start of the composition (which isn't essential, but seems cleaner to me).
## Validation Steps Performed
I've manually tested opening and closing the IME, both while submitting characters and while cancelling a composition, and in all cases the cursor visibility was correctly restored.
## Summary of the Pull Request
This is an enormously trivial nit - when we launch maximized, we don't draw the maximize button in the "restore" state.
This PR changes the terminal to manually update the Maximize button on launch, once the titlebar is added to the UI tree.
## PR Checklist
* [x] Closes#3440
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Summary of the Pull Request
When we maximize the window, shrink the caption buttons (the min, max, close buttons) down to 32px tall, to be the same height as the `TabRowControl`. This way, the tabs will be flush with the top of the display.
## PR Checklist
* [x] Closes#2541
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I tried for a couple hours this morning to do this as a `VisualState`. First I tried doing it as one on the TabRow, which I had very little success with. Then, I eventually realized that the TabRow wasn't even responsible for the padding there, it was being created by the fact that the caption buttons were too tall. Again, I tried to use the existing `VisualState`s they have defined for this, but I couldn't figure out how to do that.
I think the visual state solution would be _cleaner_, so if someone knows how to do that instead, please let me know.
## Validation Steps Performed
* Maximized/restored the Terminal on my display with the taskbar on the bottom
* Maximized/restored the Terminal on my display with the taskbar on the top
There is a range of 216 colors in the default 256-color table that is
meant to be initialized with a 6x6x6 color cube, with each color
component iterating over the values `00`, `5F`, `87`, `AF`, `D7`, and
`FF`. A few of the entries incorrectly had the _red_ component has `DF`,
when it should have been `D7`. This PR corrects those entries. It also
removes a bit of unnecessary whitespace in the first 100 entries.
## Validation Steps Performed
I have a visual test script that renders the full 256-color palette,
using both the indexed color sequence (`SGR 38;5`) and the equivalent
rgb representation (`SGR 38;2`) side by side. Although the difference
was subtle when it was incorrect, I can now see that it has been fixed.
Closes#5994
This removes all glyphs from the emoji list that do not default to
"emoji presentation" (EPres). It removes all local overrides, but retains
the comments about the emoji we left out that are Microsoft-specific.
This brings us fully in line with the most popular Terminals on OS X,
except that we squash our emoji down to fit in one cell and they let
them hang over the edges and damage other characters. Oh well.
## Detailed Description of the Pull Request / Additional comments
Late Friday evening, I tested my emoji test file on iTerm2. In so doing, I realized
that @j4james and @leonMSFT were right the entire time in #5914: Emoji
that require `U+FE0F` must not be double-width by default.
I finally banged up a powershell script that parses the UCD and emits a codepoint
width table. Once checked in, this will be definitive.
Refs #900, #5914.
Fixes#5941.
The `bcz.cmd` script calls a powershell helper script (bx.ps1), but
(previous to this change) did not pass `-NoProfile`, which means that
powershell.exe would load and run one's personal profile script, which
can only slow things down, and worse, can change default behaviors (such
as turning on strict mode by default, which will cause scripts that
don't run cleanly with strict mode to generate lots of errors--such as
bx.ps1).
This change amends the powershell.exe command line to pass -NoProfile,
as well as to set the execution policy and ensure that interactive
prompts can't inadvertently show up (normal best practices for use of
powershell in build scripts).
This change will speed things up (probably negligibly, but still) and
(more importantly) prevent non-determinism and errors that could result
from running people's profile scripts when running the helper bx.ps1.
This pull request moves swaths of Cascadia to use `til::color` for color
interop. There are still some places where we use `COLORREF`, such as in
the ABI boundaries between WinRT components.
I've also added two more til::color helpers - `with_alpha`, which takes
an existing color and sets its alpha component, and a
`Windows::UI::Color` convertor pair.
Future direction might include a `TerminalSettings::Color` type at the
idl boundary so we can finally stop using UInt32s (!) for color.
## Validation Steps Performed
Tested certain fragile areas:
* [x] setting the background with OSC 11
* [x] setting the background when acrylic is in use (which requires
low-alpha)
The AKB serializer is used in the tracelogging pipeline.
Chatted with @zadjii-msft about ganking the deserializers. The form
they'll take in the future is probably very different from this.
We'll need to have some better tracking of the _source_ or _pass_ a
setting was read during so that we can accurately construct an internal
settings attribution model. Diffing was very extremely cool, but we
didn't end up needing it.
This apparently drops our binary size by a whopping _zero bytes_ because
the optimizer was smarter than us and actually totally deleted it.
This seems to be in line with the emoji-sequences table in the latest
version of the Unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.
Fixes#5910.
Yes, I hate this.
My workflow is to use Sublime's <kbd>Ctrl+P</kbd> shortcut to navigate to files by name. However, the propsheet version of the files _always_ comes up before the `TerminalApp` one does. This results in me having to close the file and re-open the right one.
This PR renames the propsheet one, so it's unambiguous which one I'm opening.
It's really the most trivial nit.
## Summary of the Pull Request
When we're dragging the tab around, if you execute a `ClosePane`/`CloseTab`, then we should make sure to actually activate a new tab, so that focus doesn't just fall into the void.
## References
* This is almost exactly #5799, but with rearranging tabs
## PR Checklist
* [x] Closes#5559
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
We suppress `_OnTabItemsChanged` events during a rearrange, so if a tab is closed while we're rearranging tabs, the we don't fire the `SelectionChanged` event that we usually do during a close that would select the new tab.
## Validation Steps Performed
* Tested manually
- Confirmed that tragging a tab out, closing it, then dragging it back in does nothing.
This PR reverts a relatively minor change that was made incorrectly to
ConPTY in #5771.
In that PR, I authored two tests. One of them actually caught the bug
that was supposed to be fixed by #5771. The other test was simply
authored during the investigation. I believed at the time that the test
revealed a bug in conpty that was fixed by _removing_ this block of
code. However, an investigation itno #5839 revealed that this code was
actually fairly critical.
So, I'm also _skipping_ this buggy test for now. I'm also adding a
specific test case to this bug.
The problem in the bugged case of `WrapNewLineAtBottom` is that
`WriteCharsLegacy` is wrapping the bottom row of the ConPTY buffer,
which is causing the cursor to automatically move to the next line in
the buffer. This is because `WriteCharsLegacy` isn't being called with
the `WC_DELAY_EOL_WRAP` flag. So, in that test case,
* The client emits a wrapped line to conpty
* conpty fills the bottom line with that text, then dutifully increments
the buffer to make space for the cursor on a _new_ bottom line.
* Conpty reprints the last `~` of the wrapped line
* Then it gets to the next line, which is being painted _before_ the
client emits the rest of the line of text to fill that row.
* Conpty thinks this row is empty, (it is) and manually breaks the row.
However, the test expects this row to be emitted as wrapped. The problem
comes from the torn state in the middle of these frames - the original
line probably _should_ remain wrapped, but this is a sufficiently rare
case that the fix is being punted into the next release.
It's possible that improving how we handle line wrapping might also fix
this case - currently we're only marking a row as wrapped when we print
the last cell of a row, but we should probably mark it as wrapped
instead when we print the first char of the _following_ row. That work
is being tracked in #5800
### The real bug in this PR
The problem in the `DeleteWrappedWord` test is that the first line is
still being marked as wrapped. So when we get to painting the line below
it, we'll see that there are no characters to be printed (only spaces),
we emit a `^[20X^[20C`, but the cursor is still at the end of the first
line. Because it's there, we don't actually clear the text we want to
clear.
So DeleteWrappedWord, #5839 needs the `_wrappedRow = std::nullopt;`
statement here.
## References
* I guess just look at #5800, I put everything in there.
## Validation Steps Performed
* Tested manually that this was fixed for the Terminal
* ran tests
Closes#5839
A couple of codepoints, namely the card suites, male and female signs,
and white and black smiling faces were changed to have a two-column
width as part of #5795 since they were specified as emoji in Unicode's
emoji list v13.0[1].
These particular glyphs also show up in some of the most fundamental
code pages, such as CP437[2] and WGL4[3]. We should
not be touching the width of the glyphs in these codepages, as suddenly
changing a long-time-running narrow glyph to use two-columns all of a
sudden will surely break (and has already broken) things.
[1] https://www.unicode.org/Public/13.0.0/ucd/emoji/emoji-data.txt
[2] https://en.wikipedia.org/wiki/Code_page_437
[3] https://en.wikipedia.org/wiki/Windows_Glyph_List_4Closes#5822
Terminal should try not to join the choir invisible when the clipboard
API straight up horks it.
This accounts for ~3% of the crashes seen in 1.0RC1 and ~1% of the
crashes seen all-up in the last 14 days.
## Repro (prior to this commit)
Set `"copyOnSelect": true`.
Copy something small.
Hold down <kbd>Ctrl+Shift+V</kbd>
Double-click like your life depends on it. Double-click like you're
playing cookie clicker again. 2013 called, it wants its cookies back.
Fixes#4906.
It turns out that we weren't really adequately guarding calls to
SetSelectionEnd and friends.
We're clearing the active selection when the window resizes, but we're
doing so by nulling out the std::optional<Selection> it lives in. Later,
though, when we set the selection endpoint we're using "_selection->".
Optional's operator-> has undefined behavior when the optional doesn't
have a value in it.
In our case, it looks like it was returning whatever the value was prior
to it being emptied out. PivotSelection would attempt to access an
out-of-bounds coordinate when the buffer got smaller during a resize.
The solution is to guard both levels of selection endpoint manipulation
in a check for an active selection.
Apparently, this accounts for somewhere between 7% and 14% of our
crashes on 1.0RC1.
Repro was:
Use Win+Arrow to snap the window while in the middle of a selection.
## Summary of the Pull Request
Adds user settings to adjust rendering behavior to mitigate blurry text on some devices.
## References
- #778 introduced this, almost certainly.
## PR Checklist
* [x] Closes#5759, mostly
* [x] I work here.
* [ ] We need community verification that this will help.
* [x] Updated schema and schema doc.
* [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT.
## Detailed Description of the Pull Request / Additional comments
When we switched from full-screen repaints to incremental rendering, it seems like we exposed a situation where some display drivers and hardware combinations do not handle scroll and/or dirty regions (from `IDXGISwapChain::Present1`) without blurring the data from the previous frame. As we're really close to ship, I'm offering two options to let people in this situation escape it on their own. We hope in the future to figure out what's actually going on here and mitigate it further in software, but until then, these escape hatches are available.
1. `experimental.rendering.forceFullRepaint` - This one restores the pre-778 behavior to the Terminal. On every single frame paint, we'll invalidate the entire screen and repaint it.
2. `experimental.rendering.software` - This one uses the software WARP renderer instead of using the hardware and display driver directly. The theory is that this will sidestep any driver bugs or hardware variations.
One, the other, or both of these may be field-applied by users who are experiencing this behavior.
Reverting #778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. We don't believe that's acceptable when seemingly a majority of the users are experiencing the performance benefit with no detriment to graphical display.
## Validation Steps Performed
- [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline
- [ ] Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue.
This is an attempt to simplify the SGR (Select Graphic Rendition)
implementation in conhost, to cut down on the number of methods required
in the `ConGetSet` interface, and pave the way for future improvements
and bug fixes. It already fixes one bug that prevented SGR 0 from being
correctly applied when combined with meta attributes.
* This a first step towards fixing the conpty narrowing bugs in issue
#2661
* I'm hoping the simplification of `ConGetSet` will also help with
#3849.
* Some of the `TextAttribute` refactoring in this PR overlaps with
similar work in PR #1978.
## Detailed Description of the Pull Request / Additional comments
The main point of this PR was to simplify the
`AdaptDispatch::SetGraphicsRendition` implementation. So instead of
having it call a half a dozen methods in the `ConGetSet` API, depending
on what kinds of attributes needed to be set, there is now just one call
to get current attributes, and another call to set the new value. All
adjustments to the attributes are made in the `AdaptDispatch` class, in
a simple switch statement.
To help with this refactoring, I also made some change to the
`TextAttribute` class to make it easier to work with. This included
adding a set of methods for setting (and getting) the individual
attribute flags, instead of having the calling code being exposed to the
internal attribute structures and messing with bit manipulation. I've
tried to get rid of any methods that were directly setting legacy, meta,
and extended attributes.
Other than the fix to the `SGR 0` bug, the `AdaptDispatch` refactoring
mostly follows the behaviour of the original code. In particular, it
still maps the `SGR 38/48` indexed colors to RGB instead of retaining
the index, which is what we ultimately need it to do. Fixing that will
first require the color tables to be unified (issue #1223), which I'm
hoping to address in a followup PR.
But for now, mapping the indexed colors to RGB values required adding an
an additional `ConGetSet` API to lookup the color table entries. In the
future that won't be necessary, but the API will still be useful for
other color reporting operations that we may want to support. I've made
this API, and the existing setter, standardise on index values being in
the "Xterm" order, since that'll be essential for unifying the code with
the terminal adapter one day.
I should also point out one minor change to the `SGR 38/48` behavior,
which is that out-of-range RGB colors are now ignored rather than being
clamped, since that matches the way Xterm works.
## Validation Steps Performed
This refactoring has obviously required corresponding changes to the
unit tests, but most were just minor updates to use the new
`TextAttribute` methods without any real change in behavior. However,
the adapter tests did require significant changes to accommodate the new
`ConGetSet` API. The basic structure of the tests remain the same, but
the simpler API has meant fewer values needed to be checked in each test
case. I think they are all still covering the areas there were intended
to, though, and they are all still passing.
Other than getting the unit tests to work, I've also done a bunch of
manual testing of my own. I've made sure the color tests in Vttest all
still work as well as they used to. And I've confirmed that the test
case from issue #5341 is now working correctly.
Closes#5341
The table that we refer to in `CodepointWidthDetector.cpp` to determine
whether or not a codepoint should be rendered as Wide vs Narrow was
based off EastAsianWidth[1]. If a codepoint wasn't included in this
table, they're considered Narrow. Many emojis aren't specified in the
EAW list, so this PR supplements our table with emoji codepoints from
emoji-data[2] in order to render most, if not all, emojis as full-width.
There are certain codepoints I've added to the comments (in case we want
to add them officially to the table in the future) that Microsoft
decided to give an emoji presentation even if it's specified as
Narrow/Ambiguous in the EAW list and are _not_ specified in the Unicode
emoji list. These include all of the Mahjong Tiles block, different
direction pencils (✎✐), different pointing index fingers (☜, ☞) among
others. I have no idea if I've captured all of them, as I don't know of
an easy way to detect which are Microsoft specific emojis.
## Validation Steps Performed
I have looked at so many emojis that I dream emoji.
These screenshots aren't encompassing _all_ emoji but I've tried to grab
a couple from all across the codepoint ranges:
Before:
After:
[1] http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
[2] https://www.unicode.org/Public/13.0.0/ucd/emoji/emoji-data.txtCloses#900
## Summary of the Pull Request
We accidentally missed switching one `TriggerRedrawAll` to `TriggerScroll`. This does that.
## References
#5185 - applies logic from this PR
## PR Checklist
* [X] Closes#5756
## Validation Steps Performed
Followed bug repro steps.
## Summary of the Pull Request
This PR resolves an issue with the Git for Windows (MSYS) version of `less`. It _doesn't_ use VT processing for emitting text tothe buffer, so when it hits `WriteCharsLegacy`, `WC_DELAY_EOL_WRAP` is NOT set.
When this happens, `less` is writing some text that's longer than the width of the buffer to the last line of the buffer. We're hitting the
```c++
Status = AdjustCursorPosition(screenInfo, CursorPosition, WI_IsFlagSet(dwFlags, WC_KEEP_CURSOR_VISIBLE), psScrollY);
```
call in `_stream.cpp:560`.
The cursor is _currently_ at `{40, 29}`, the _start_ of the run of text that wrapped. We're trying to adjust it to `{0, 30}`, which would be the start of the next line of the buffer. However, the buffer is only 30 lines tall, so we've got to `IncrementCircularBuffer` first, so we can move the cursor there.
When that happens, we're going to paint frame. At the end of that frame, we're going to try and paint the cursor position. The cursor is still at `{40, 29}` here, so unfortunately, the `cursorIsInDeferredWrap` check in `XtermEngine::PaintCursor` is `false`. That means, conpty is going to try to move the cursor to where the console thinks the cursor actually is at the end of this frame, which is `{40, 29}`.
If we're painting the frame because we circled the buffer, then the cursor might still be in the position it was before the text was written to the buffer to cause the buffer to circle. In that case, then we DON'T want to paint the cursor here either, because it'll cause us to manually break this line. That's okay though, the frame will be painted again, after the circling is complete.
## PR Checklist
* [x] Closes#5691
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I suppose that's the detailed description above
## Validation Steps Performed
* ran tests
* checked that the bug was actually fixed in the Terminal
This allows me to make the build pipeline, instead of the release
engineer, put the version number in the package name.
It also lets us sign multiple packages (if we ever produce more than
one.)
## Summary of the Pull Request
Identifies and scales glyphs in the box and line drawing ranges U+2500-U+259F to fit their cells.
## PR Checklist
* [x] Closes#455
* [x] I work here.
* [x] Manual tests. This is all graphical.
* [x] Metric ton of comments
* [x] Math spreadsheet included in PR.
* [x] Double check RTL glyphs.
* [x] Why is there the extra pixel?
* [x] Scrolling the mouse wheel check is done.
* [x] Not drawing outline?
* [x] Am core contributor. Roar.
* [x] Try suppressing negative scale factors and see if that gets rid of weird shading.
## Detailed Description of the Pull Request / Additional comments
### Background
- We want the Terminal to be fast at drawing. To be fast at drawing, we perform differential drawing, or only drawing what is different from the previous frame. We use DXGI's `Present1` method to help us with this as it helps us compose only the deltas onto the previous frame at drawing time and assists us in scrolling regions from the previous frame without intervention. However, it only works on strictly integer pixel row heights.
- Most of the hit testing and size-calculation logic in both the `conhost` and the Terminal products are based on the size of an individual cell. Historically, a cell was always dictated in a `COORD` structure, or two `SHORT` values... which are integers. As such, when we specify the space for any individual glyph to be displayed inside our terminal drawing region, we want it to fall perfectly inside of an integer box to ensure all these other algorithms work correctly and continue to do so.
- Finally, we want the Terminal to have font fallback and locate glyphs that aren't in the primary selected font from any other font it can find on the system that contains the glyph, per DirectWrite's font fallback mechanisms. These glyphs won't necessarily have the same font or glyph metrics as the base font, but we need them to fit inside the same cell dimensions as if they did because the hit testing and other algorithms aren't aware of which particular font is sourcing each glyph, just the dimensions of the bounding box per cell.
### How does Terminal deal with this?
- When we select a font, we perform some calculations using the design metrics of the font and glyphs to determine how we could fit them inside a cell with integer dimensions. Our process here is that we take the requested font size (which is generally a proxy for height), find the matching glyph width for that height then round it to an integer. We back convert from that now integer width to a height value which is almost certainly now a floating point number. But because we need an integer box value, we add line padding above and below the glyphs to ensure that the height is an integer as well as the width. Finally, we don't add the padding strictly equally. We attempt to align the English baseline of the glyph box directly onto an integer pixel multiple so most characters sit crisply on a line when displayed.
- Note that fonts and their glyphs have a prescribed baseline, line gap, and advance values. We use those as guidelines to get us started, but then to meet our requirements, we pad out from those. This results in fonts that should be properly authored showing gaps. It also results in fonts that are improperly authored looking even worse than they normally would.
### Now how does block and line drawing come in?
- Block and Line drawing glyphs are generally authored so they will look fine when the font and glyph metrics are followed exactly as prescribed by the font. (For some fonts, this still isn't true and we want them to look fine anyway.)
- When we add additional padding or rounding to make glyphs fit inside of a cell, we can be adding more space than was prescribed around these glyphs. This can cause a gap to be visible.
- Additionally, when we move things like baselines to land on a perfect integer pixel, we may be drawing a glyph lower in the bounding box than was prescribed originally.
### And how do we solve it?
- We identify all glyphs in the line and block drawing ranges.
- We find the bounding boxes of both the cell and the glyph.
- We compare the height of the glyph to the height of the cell to see if we need to scale. We prescribe a scale transform if the glyph wouldn't be tall enough to fit the box. (We leave it alone otherwise as some glyphs intentionally overscan the box and scaling them can cause banding effects.)
- We inspect the overhang/underhang above and below the boxes and translate transform them (slide them) so they cover the entire cell area.
- We repeat the previous two steps but in the horizontal direction.
## Validation Steps Performed
- See these commments:
- https://github.com/microsoft/terminal/issues/455#issuecomment-620248375
- https://github.com/microsoft/terminal/issues/455#issuecomment-621533916
- https://github.com/microsoft/terminal/issues/455#issuecomment-622585453
Also see the below one with more screenshots:
- https://github.com/microsoft/terminal/pull/5743#issuecomment-624940567
If we're fullscreen, the TabView isn't `Visible`. If it's not `Visible`,
it's _not_ going to raise a `SelectionChanged` event, which is what we
usually use to focus another tab. Instead, we'll have to do it manually
here.
So, what we're going to try to do is move the focus to the tab to the
left, within the bounds of how many tabs we have.
EX: we have 4 tabs: [A, B, C, D]. If we close:
* A (`tabIndex=0`): We'll want to focus tab B (now in index 0)
* B (`tabIndex=1`): We'll want to focus tab A (now in index 0)
* C (`tabIndex=2`): We'll want to focus tab B (now in index 1)
* D (`tabIndex=3`): We'll want to focus tab C (now in index 2)
`_UpdatedSelectedTab` will do the work of setting up the new tab as the
focused one, and unfocusing all the others.
Also, we need to _manually_ set the SelectedItem of the tabView here. If
we don't, then the TabView will technically not have a selected item at
all, which can make things like ClosePane not work correctly.
## PR Checklist
* [x] Closes#5799
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Played with it a bunch
## Summary of the Pull Request
This adds a new appxmanifest for 'Windows Terminal (Preview)' and links the resources.
Code-wise, split up `WindowsTerminalReleaseBuild` into...
- WindowsTerminalOfficialBuild: [true, false]
- WindowsTerminalBranding: [Dev, Preview, Release]
Added a comment about that in release.yml
## Validation Steps Performed
used msbuild to build...
- [X] Dev
- [X] Preview
- [X] Release
then checked the msix for the correct name/icon.
[Git2Git] Merged PR 4644345: conhost: disable the DX renderer in inbox builds
We're going to be taking on some changes to the Dx renderer that are at
the very least annoying and at the very most inconsequential to the
inbox console. This commit removes support for the DX renderer from the
inbox console.
SizeBench reports that ConRenderDx contributes 55.1kb to the conhost
image (as its third largest constituent library), so this should net us
a couple pleasant WPG improvements down the line.
Related work items: #26291552 Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 6e36786d447b7975298ba31ccd77c5c649fbfbe6
Related work items: #26291552
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/200504-1008 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp bbdf04608ba96c3f8ee06cf100428cde01f3df79
Related work items: #26071826
This is actually related to another issue we have, #3917. I think if the system is set to "Dark" theme, but the app is set to light theme, then the brush lookup in `_ClearNewTabButtonColor` still returns to us the dark theme brushes.
Fortunately, since we're not actually setting the color of the new tab button anymore, we can just remove the call to that method now, and loop back on it later.
## References
* regressed in #3789
* related to #3917
## PR Checklist
* [x] Closes#5741
The Erase All VT sequence (`^[[2J`) is supposed to erase the entire
contents of the viewport. The way it usually does this is by shifting
the entirety of the viewport contents into scrollback, and starting the
new viewport below it.
Currently, conpty doesn't propagate that state change correctly. When
conpty gets a 2J, it simply erases the content of the connected
terminal's viewport, by writing over it with spaces. Conpty didn't
really have a good way of communicating "your viewport should move", it
only knew "the buffer is now full of spaces".
This would lead to bugs like #2832, where pressing <kbd>ctrl+L</kbd> in
`bash` would delete the current contents of the viewport, instead of
moving the viewport down.
This PR makes sure that when conpty sees a 2J, it passes that through
directly to the connected terminal application as well. Fortunately, 2J
was already implemented in the Windows Terminal, so this actually fixes
the behavior of <kbd>ctrl+L</kbd>/`clear` in WSL in the Terminal.
## References
* #4252 - right now this isn't the _most_ optimal scenario, we're
literally just printing a 2J, then we'll perform "erase line" `height`
times. The erase line operations are all redundant at this point - the
entire viewport is blank, but conpty doesn't really know that.
Fortunately, #4252 was already filed for me to come through and
optimize this path.
## PR Checklist
* [x] Closes#2832
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* ran tests
* compared <kbd>ctrl+L</kbd> with its behavior in conhost
* compared `clear` with its behavior in conhost
I never got to fixing these in the original #3789 PR, but I messed up that branch way too many times already that I figured I'd just do it in post.
* [x] Fixes the typo bot in `master`
* [x] I work here
This commit introduces a context menu for Tab and a new item,
"Color...", which will display a color picker.
A flyout menu, containing a custom flyout, is attached to each tab. The
flyout displays a palette of 16 preset colors and includes a color
picker. When the user selects or clears color, an event is fired, which
is intercepted by the tab to which the flyout belongs.
The changing of the color is achieved by putting the selected color in
the resource dictionary of the tab, using well-defined dictionary keys
(e.g. TabViewItemHeaderBackground). Afterwards the visual state of the
tab is toggled, so that the color change is visible immediately.
Custom-colored tabs will be desaturated (somewhat) by alpha blending
them with the tab bar background.
The flyout menu also contains a 'Close' flyout item.
## Validation Steps Performed
I've validated the behavior manually: start the program via the start
menu. Right click on the tab -> Choose a tab color.
The color flyout is going to be shown. Click a color swatch or click
'Select a custom color' to use the color picker. Use the 'Clear the
current color' to remove the custom color.
Closes#2994. References #3327.
Add a note that the user needs to hide dynamic profiles, not just delete them.
* [x] I work here
* [x] Is documentation.
* related to discussion in #3231
<!-- 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 fixes the RTL regression caused in #4747. We create the rectangle taking the direction (through the BiDi Level) into account, and then the rendering works again. The GlyphRun shaping could still probably use some work to be a polished thingy, and there are still issues with RTL getting chopped up a lot when there's font fallback going on, but this fixes the regression, and it's now functional again.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4779#4747
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4779
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be 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
The baseline is actually direction dependent. So when it was being initialized, the unconditional baseline as left broke it, setting the box off to right of the text. We just check if the `GlyphRun->bidiLevel` is set, and if so, we adjust it so that the baseline lines up with the right, not with the left.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- 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
Tooltip texts is an important element of each software! Added tooltip text to close button, minimize, restore down, and new tab. Moved from original.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
Connected to #5355
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [X] Closes#5355
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [X] No Docs
* [ ] 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: #5355
<!-- 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
I'm pretty sure most ppl know what a tooltip text is, but for those who don't, it's a text that tells you what a button does when you over the button with your mouse.
This commit introduces a NOTICE.html file that will be embedded into the
package. It will be stamped down with the real notices during a branded
release build (as part of the build pipeline.)
It, in part, reverts some of the really good work in determining the
commit hash at build time. That work will be preserved in history.
This is more compliant with our duties to the OSS we consume.
## Summary of the Pull Request
This PR implements a pair of shims for `cmd` and `powershell`, so that their `cls` and `Clear-Host` functions will clear the entire terminal buffer (like they do in conhost), instead of just the viewport. With the conpty viewport and buffer being the same size, there's effectively no way to know if an application is calling these API's in this way with the intention of clearing the buffer or the viewport. We absolutely have to guess.
Each of these shims checks to see if the way that the API is being called exactly matches the way `cmd` or `powershell` would call these APIs. If it does, we manually write a `^[[3J` to the connected terminal, to get he Terminal to clear it's own scrollback.
~~_⚠️ If another application were trying to clear the **viewport** with an exactly similar API call, this would also cause the terminal scrollback to get cleared ⚠️_~~
* [x] Should these shims be restricted to when the process that's calling them is actually `cmd.exe` or `powershell.exe`? Can I even do this? I think we've done such a good job of isolating the client process information from the rest of the host code that I can't figure out how to do this.
- YES, this can be done, and I did it.
* [ ] **TODO**: _While I'm here_, should I have `DoSrvPrivateEraseAll` (the implementation for `^[[2J`, in `getset.cpp`) also manually trigger a EraseAll in the terminal in conpty mode?
## PR Checklist
* [x] Closes#3126
* [x] Actually closes#1305 too, which is really the same thing, but probably deserves a callout
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* ran tests
* checked `cls` in the Terminal
* checked `Clear-Host` in the Terminal
* Checked running `powershell clear-host` from `cmd.exe`
We've got a weird crash that happens terribly inconsistently, but pretty
readily on migrie's laptop, only in Debug mode. Apparently, there's some
weird ref-counting magic that goes on during teardown, and our
Application doesn't get closed quite right, which can cause us to crash
into the debugger. This of course, only happens on exit, and happens
somewhere in the `...XamlHost.dll` code.
Crazily, if we _manually leak the `Application`_ here, then the crash
doesn't happen. This doesn't matter, because we really want the
Application to live for _the entire lifetime of the process_, so the only
time when this object would actually need to get cleaned up is _during
exit_. So we can safely leak this `Application` object, and have it just
get cleaned up normally when our process exits.
* [x] I discussed this with @DHowett-MSFT and we both agree this is mental
* [x] I'm pretty sure there's not an actual bug on our repo for this
* [x] I verified on my machine where I can crash the terminal 100% of the time on exit in debug, this fixes it
* [x] I verified that it doesn't introduce a _new_ crash in Release on my machine
Turns out we're still being a bit too aggressive when removing spaces.
If there are spaces at the end of the first run painted to a bottom
line, _and the bottom line was a different color than the previous_,
then we can't trim those spaces off the string. We still need to emit
those to make sure the terminal has colored spaces in it as well.
## References
* there's like 80 PRs in the last month for this function
## PR Checklist
* [x] Closes#5502
* [x] I work here
* [x] Tests added/passed
## Validation Steps
* [x] ran the tests
* [x] checked that vtpipeterm still worked
* [x] Checked that the bug was fixed in the Terminal
For our release builds, we're just going to integrate the UWPDesktop CRT
into our package and delete the package dependencies. It's very
difficult for users who do not have access to the store to get our
dependency packages, and we want to be robust and deployable everywhere.
Since these libraries can be redistributed, it's easiest if we simply
redistribute them.
Our package grows by ~550kb per architecture (compressed) because of
this. I've added validation that we don't have both the libs _and_ the
dependencies in the same package.
Fixes#3097.
## Validation
The script does it!
## Summary of the Pull Request
Based on the discussion in #5479, it seems that the crash is caused by a race condition due to not obtaining the write lock before calling `TriggerFontChange`.
I'm not totally sure if my approach is the right one, but I've taken the lock out of `_RefreshSize` since it seems like all calls of `_RefreshSize` come after a `TriggerFontChange`/`UpdateFont`. Then I just
made sure all calls of `TriggerFontChange`/`UpdateFont` are preceded with a `LockForWriting`.
## PR Checklist
* [x] Closes#5479
* [x] CLA signed.
* [x] Tests added/passed
## Validation Steps Performed
Scrolling to change my font size does not kill the Terminal anymore! 🙌
If a class has a constructor which can be called with a single argument,
then this constructor becomes conversion constructor because such a
constructor allows conversion of the single argument to the class being
constructed. To ensure these constructors are passed the argument of its
type, I labeled them explicit.
In some header files, there were constructors that took a value that
could involve implicit conversions, so I added explicit to ensure that
does not happen.
Hide any commandline (cooked read) we have before we begin a resize, and
show it again after the resize.
## References
* I found #5618 while I was working on this.
## PR Checklist
* [x] Closes#1856
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Basically, during a resize, we try to restore the viewport position
correctly, and part of that checks where the current commandline ends.
However, when we do that, the commandline's _current_ state still
reflects the _old_ buffer size, so resizing to be smaller can cause us
to throw an exception, when we find that the commandline doesn't fit in
the new viewport cleanly.
By hiding it, then redrawing it, we avoid this problem entirely. We
don't need to perform the check on the old commandline contents (since
they'll be empty), and we'll redraw it just fine for the new buffer size
## Validation Steps Performed
* ran tests
* checked resizing, snapping in conhost with a cooked read
* checked resizing, snapping in the Terminal with a cooked read
Web apps apparently will paste the <title> as plaintext before the
actual HTML content from the clipboard. Since this seems to be
widespread behavior across web apps, this isn't just a bug in _some
app_, this is a bug on us. We shouldn't emit the title.
This PR removes the title tag from the generated HTML.
Closes#5347
<!-- 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
In tonight's episode of "Can we be even faster?", we will... you know what, just take a look at the code.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be 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
It is actually a quite common technique seen inside the codebase to first reserve the spaces before pushing something into vectors. I don't know why it is not used here.
Before:
After:
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- 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
In tonight's episode of "I wanna my CPU back", we'll see a quite familiar face whose name is Mr.AttrRow.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#2937
<!-- 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
* [ ] Requires documentation to be 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
I knew this is possible a long time ago. Just didn't got the chance to actually implement this. I understand that you guys are busy preparing the v1.0 release. So if this is a bad time, this can wait.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manually tested. If all goes well, nothing will be broken.
## Summary of the Pull Request
This PR clamp the "new rows" scrolling value to a positive number. We can't create a negative number of new rows. It also adds a test.
## References
## PR Checklist
* [x] Closes#5540
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
The origin of this bug is that as newlines are emitted, we'll accumulate an enormous scroll delta into a selection region, to the point of overflowing a `SHORT`. When the overflow occurs, the `Terminal` would fail to send a `NotifyScroll()` to the `TermControl` hosting it.
For this bug to repro, we need to:
- Have a sufficiently large buffer, because each newline we'll accumulate a delta of (0, ~bufferHeight), so (bufferHeight^2 + bufferHeight) > SHRT_MAX
- Have a selection
## Validation Steps Performed
* Dustin verified this actually
* Created a new insane test case
## Summary of the Pull Request
Before this, if the Search Box was open, new selections would not notify automation clients. This was because the UiaEngine (responsible for notifying automation clients) would remain disabled. Now we're enabling it before the early exit in TermControl's FocusHandler
## PR Checklist
* [X] Will close issue #5421 upon verification
## Validation Steps Performed
Verified using NVDA.
Narrator's behavior is not impacted, for some reason.
This PR fixes#5525 by re-adding range checks that were erroneously removed in
a9c9714.
## Validation Steps Performed
* Enabled a German keyboard layout
* Entered `<`, `+`, `7`, `8`, `9`, `0` while holding either Alt+Ctrl or AltGr and...
* Ensuring that both produce `|`, `~`, `{`, `[`, `]`, `}`
Closes#5525
## Summary of the Pull Request
This PR will add a link to the version of `NOTICE.md` in GitHub at the commit that the build was on. It uses the same approach for generating our settings files, where we'll create a header file with the commit hash assigned to a `wstring_view` during build time.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#5139
* [x] CLA signed.
* [x] Tests added/passed
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
The link is there and goes to the expected `NOTICE.md`.
## Summary of the Pull Request
This PR performs a number of miscellaneous clean-up tasks on our schema:
- [X] allow null for some settings
- [X] update some default values to be more useful
- [X] consistently use " instead of '
- [X] remove colorTable
- [X] provide missing description for `backgroundImageOpacity`
- [X] update cursorShape to have options match order displayed in vs code
- [X] if a setting has multiple options, provide a list of those options with a short description on each
- this one I only did a few times
- [X] remove a little bit of ambiguity on some descriptions
## PR Checklist
Closes#5279
## Detailed Description of the Pull Request / Additional comments
Validation was performed for...
- [X] Global Settings
- [X] Profile Settings
- [x] Keybinding Actions
## Validation Steps Performed
I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
This PR fixes a couple of issues with TSFInputControl alignment:
1. The emoji picker IME in particular would show up overlapping the
current buffer row because I stupidly didn't realize that
`TextBlock.ActualHeight` is 0 right after initialization and before
it has any text. So, the emoji picker will show up on the bottom of
the 0 height TextBlock, which overlaps the current buffer row. This
isn't a problem with CJK because inputting text _causes_ the IME to
show up, so by the time the IME shows up, the TextBlock has text and
accordingly has a height.
2. It turns out the emoji picker IME doesn't follow the `TextBlock`
bottom, unlike Chinese and Japanese IME, so if a user were to compose
near the edge of the screen and let the `TextBlock` start line
wrapping, the emoji IME doesn't follow the bottom of the `TextBlock`
as it grows. This means that the `TextBlock` position doesn't update
in the middle of composition, and the `LayoutRequested` event that it
fires at the beginning of composition is the only chance we get to
tell the emoji IME where to place itself. It turns out when we reset
`TextBlock.Text`, the ActualHeight doesn't get immediately reset back
to the min size. So if a user were to bring up the emoji IME before
`ActualHeight` is reset, the IME will show up way below the current
buffer row.
3. We don't currently `TryRedrawCanvas` when the window position changes
(resizing, dragging the window around), so sometimes dragging or
resizing the Terminal doesn't update the position of the IME. Ideally
it should be listening to some "window position changed" event, but
alas we don't have that and it would be much harder than this
incoming fix. We'll just track the window bounds as part of
`TryRedrawCanvas` and redraw if it changes. For the most part, this
will allow the IME to update to where the new window position is, but
it'll only be called if we receive a `LayoutRequested` event.
## PR Checklist
* [x] Closes#5470
* [x] CLA signed.
* [x] Tests added/passed
## Validation Steps Performed
I play with it for quite a bit.
<!-- 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
A tiny performance fix in `renderer.cpp`.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be 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
The cluster construction code is intensively called during rendering. Even though a single `back()` is fast, but accumulated `back()`s still take a noticiable amount of CPU cycles.
Before:
After:
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manually validated.
This property was deprecated in 0.11. We probably should have also added a warning
message to help the community figure out that this property is gone and won't work
anymore.
This PR adds that warning.
* I'm not going to list the enormous number of duped threads _wait yes I am_
* #5581
* #5547
* #5555
* #5557
* #5573
* #5532
* #5527
* #5535
* #5510
* #5511
* #5512
* #5513
* #5516
* #5515
* #5521
* This literally isn't even all of them
* [x] Also mainly related to #5458
* [x] I work here
* [x] Tests added/passed
Followup to ea61aa3b.
The default foreground in the iTerm2 defaults for the Tango Dark color
scheme is too bright, use the value for ANSI 7 (white) instead.
References #5305
Sorry, I should have really done this in the original PR.
Signed-off-by: Rafael Kitover <rkitover@gmail.com>
<!-- 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
Simple fix to update the example documentation with the recent changes to 0.11.
Also known as "Kill HRGN II: Kills Regions Dead (#5485)"
Copying the description from @greg904 in #4778.
--- 8< ---
My understanding is that the XAML framework uses another way of getting
mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It
looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`.
Before, we were cutting (with `HRGN`s) the drag bar part of the XAML
islands window in order to catch mouse messages and be able to implement
the drag bar that can move the window. However this "cut" doesn't only
apply to input (mouse messages) but also to the graphics so we had to
paint behind with the same color as the drag bar using GDI to hide the
fact that we were cutting the window.
The main issue with this is that we have to replicate exactly the
rendering on the XAML drag bar using GDI and this is bad because:
1. it's hard to keep track of the right color: if a dialog is open, it
will cover the whole window including the drag bar with a transparent
white layer and it's hard to keep track of those things.
2. we can't do acrylic with GDI
So I found another method, which is to instead put a "drag window"
exactly where the drag bar is, but on top of the XAML islands window (in
Z order). I've found that this lets us receive the `WM_LBUTTONDOWN`
messages.
--- >8 ---
Dustin's notes: I've based this on the implementation of the input sink
window in the UWP application frame host.
Tested manually in all configurations (debug, release) with snap,
drag, move, double-click and double-click on the resize handle. Tested
at 200% scale.
Closes#4744Closes#2100Closes#4778 (superseded.)
Takes the lock inside two routines in `TermControl` that were changing
the selection endpoint while a rendering frame was still drawing,
resulting in several variants of graphical glitches from double-struck
selection boxes to duplicated line text.
## References
- Introduced with #5185
## PR Checklist
* [x] Closes#5471
* [x] Already signed life away to company.
* [x] Manual tests passed since it's visual.
* [x] No extra doc besides the comments.
* [x] Am core contributor: Roar.
The renderer base and specific renderer engine do a lot of work to
remember the previous selection and compensate for scrolling regions and
deltas between frames. However, all that work doesn't quite match up
when the endpoints are changed out from under it. Unfortunately,
`TermControl` doesn't have a robust history of locking correctly in step
with the renderer nor does the renderer's `IRenderData` currently
provide any way of 'snapping' state at the beginning of a frame so it
could work without a full lock. So the solution for now is for the
methods that scroll the display in `TermControl` to take the lock that
is shared with the renderer's frame painter so they can't change out of
sync.
## Validation Steps Performed
- Opened terminal with Powershell core.
Did ls a bunch of times.
Clicked to make selection and held mouse button while wheeling around.
- Opened terminal with Powershell core.;
Did ls a bunch of times.
Clicked to make selection and dragged mouse outside the window to make
auto scroll happen.
- Opened terminal with Powershell core.
Did ls a bunch of times.
Clicked to make selection and released. Wheeled around like a crazy
person to make sure I didn't regress that.
Literally just <kbd>ctrl+f</kbd> find-and-replace all the old `profiles.json` that are sitting around in the repo with `settings.json`. I didn't touch the specs, since it seemed better to leave them in the state that they were originally authored in.
* [x] closes#5522
* [x] I work here.
* [x] This is docs.
These were already in the `SettingsSchema.md`, so I just updated the `profiles.schema.json` to have the descriptions as well.
* [x] closes#5520
* [x] I work here.
* [x] This is docs.
It was brought to our attention that shipping a font with ligatures as our default
font could be an accessibility issue for the visually-impaired. Unfortunately, we
don't have a renderer setting to disable ligatures (#759). Fortunately however, we
DO already have a version of Cascadia that doesn't have ligatures.
If we ship that and set it as our default font, we'll at least let people _opt_ to
have ligatures enabled by switching from `Cascadia Mono` to `Cascadia Code`.
## PR Checklist
* [x] Closes internal discussion
* [x] CLA signed
* [ ] Tests added/passed
* [x] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
In order to support a transparent background for the acrylic effect, the
renderer sets the alpha value to zero for the default background color.
However, when the _reversed video_ attribute is set, the background is
actually filled with the foreground color, and will not be displayed
correctly if it is made transparent. This PR addresses that issue by
making sure the rendered background color is opaque if the reversed
video attribute is set.
## References
* This is not a major issue at the moment, since the _reverse video_
attribute is not typically forwarded though conpty, but that will
change once #2661 is fixed.
## PR Checklist
* [x] Closes#5498
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #5498
## Detailed Description of the Pull Request / Additional comments
This simply adds an additional check in `Terminal::GetBackgroundColor`
to make sure the returned color is opaque if the _reverse video_
attribute is set. At some point in the future this check may need to be
extended to support the `DECSCNM` reverse screen mode, but for now
that's not an issue.
## Validation Steps Performed
I've run the test case from issue #5498, and confirmed that it now works
as expected. I've also got an experimental fix for #2661 that I've
tested with this patch, and that now displays _reverse video_ attributes
correctly too.
Closes#5498
If Terminal is spawned by a shortcut that requests that it run in a new process group
while attached to a console session, that request is nonsense. That request will, however,
cause WT to start with Ctrl-C disabled. This wouldn't matter, because it's a Windows-subsystem
application. Unfortunately, that state is heritable. In short, if you start WT using cmd in
a weird way, ^C stops working inside the terminal. Mad.
Fixes#5460.
## Summary of the Pull Request
- Adjusts scaling practices in `DxEngine` (and related scaling practices in `TerminalControl`) for pixel-perfect row baselines and spacing at High DPI such that differential row-by-row rendering can be applied at High DPI.
## References
- #5185
## PR Checklist
* [x] Closes#5320, closes#3515, closes#1064
* [x] I work here.
* [x] Manually tested.
* [x] No doc.
* [x] Am core contributor. Also discussed with some of them already via Teams.
## Detailed Description of the Pull Request / Additional comments
**WAS:**
- We were using implicit DPI scaling on the `ID2D1RenderTarget` and running all of our processing in DIPs (Device-Independent Pixels). That's all well and good for getting things bootstrapped quickly, but it leaves the actual scaling of the draw commands up to the discretion of the rendering target.
- When we don't get to explicitly choose exactly how many pixels tall/wide and our X/Y placement perfectly, the nature of floating point multiplication and division required to do the presentation can cause us to drift off slightly out of our control depending on what the final display resolution actually is.
- Differential drawing cannot work unless we can know the exact integer pixels that need to be copied/moved/preserved/replaced between frames to give to the `IDXGISwapChain1::Present1` method. If things spill into fractional pixels or the sizes of rows/columns vary as they are rounded up and down implicitly, then we cannot do the differential rendering.
**NOW:**
- When deciding on a font, the `DxEngine` will take the scale factor into account and adjust the proposed height of the requested font. Then the remainder of the existing code that adjusts the baseline and integer-ifies each character cell will run naturally from there. That code already works correctly to align the height at normal DPI and scale out the font heights and advances to take an exact integer of pixels.
- `TermControl` has to use the scale now, in some places, and stop scaling in other places. This has to do with how the target's nature used to be implicit and is now explicit. For instance, determining where the cursor click hits must be scaled now. And determining the pixel size of the display canvas must no longer be scaled.
- `DxEngine` will no longer attempt to scale the invalid regions per my attempts in #5185 because the cell size is scaled. So it should work the same as at 96 DPI.
- The block is removed from the `DxEngine` that was causing a full invalidate on every frame at High DPI.
- A TODO was removed from `TermControl` that was invalidating everything when the DPI changed because the underlying renderer will already do that.
## Validation Steps Performed
* [x] Check at 150% DPI. Print text, scroll text down and up, do selection.
* [x] Check at 100% DPI. Print text, scroll text down and up, do selection.
* [x] Span two different DPI monitors and drag between them.
* [x] Giant pile of tests in https://github.com/microsoft/terminal/pull/5345#issuecomment-614127648
Co-authored-by: Dustin Howett <duhowett@microsoft.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
## Summary of the Pull Request
Users were not able to intercept Ctrl-C input using `$Host.UI.RawUI.ReadKey("IncludeKeyUp")`, because we weren't sending a Ctrl-C KeyUp event. This PR simply adds a KeyUp event alongside the existing KeyDown.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#1894
* [x] CLA signed.
* [x] Tests added/passed
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
The repro script in #1894 now works, both options for `ReadKey`: `IncludeKeyUp` and `IncludeKeyDown` work fine.
This PR adds a test for #5428. Mysteriously, after #5398 merged, 5428 went away. However, I already wrote this test for it, so we might as well add it to our collection.
* [x] Closes#5428
* [x] I work here
* [x] Is a test
- build: move oss required to build conhost out of dep/
This change is necessary as the dep/ folder is not synced into the
Windows source tree.
I've also added a build rule producing a lib for {fmt}.
This will be required for our next OS ingestion.
Related work items: #26069643
This change is necessary as the dep/ folder is not synced into the
Windows source tree.
I've also added a build rule producing a lib for {fmt}.
This will be required for our next OS ingestion.
* Cleaning up the whitelist a bit.
* The magic to exclude repeated characters worked 👍
* Every successful run on master now logs its suggested cleanup, e.g. for 5740e197c2 has https://github.com/microsoft/terminal/runs/596271627#step:4:37
* ⚠️ This check-spelling 0.0.15a+ tolerates Windows line endings in the `whitelist.txt` file (another project I touched had some `.gitconfig` magic which required supporting them).
This means that if someone edits the file w/ something that likes Windows line endings, the file will successfully convert (instead of it being ignored and check-spelling complaining about everything). Most likely anyone else who then edits the file will use something that will maintain the line endings.
Improve wide glyph support in UIA (GH-4946)
Add enhanced key support for ConPty (GH-5021)
Set DxRenderer non-text alias mode (GH-5149)
Reduce CursorChanged Events for Accessibility (GH-5196)
Add more object ID tracing for Accessibility (GH-5215)
Add SS3 cursor key encoding to ConPty (GH-5383)
UIA: Prevent crash from invalid UTR endpoint comparison (GH-5399)
Make CodepointWidthDetector::GetWidth faster (CC-3727)
add til::math, use it for float conversions to point, size (GH-5150)
Add support for renderer backoff, don't FAIL_FAST on 3x failures, add UI (GH-5353)
Fix a deadlock and a bounding rects issue in UIA (GH-5385)
Don't duplicate spaces from potentially-wrapped EOL-deferred lines (GH-5398)
Reimplement the VT tab stop functionality (CC-5173)
Clamp parameter values to a maximum of 32767. (CC-5200)
Prevent the cursor type being reset when changing the visibility (CC-5251)
Make RIS switch back to the main buffer (CC-5248)
Add support for the DSR-OS operating status report (CC-5300)
Update the virtual bottom location if the cursor moves below it (CC-5317)
ci: run spell check in CI, fix remaining issues (CC-4799) (CC-5352)
Set Cascadia Code as default font (GH-5121)
Show a double width cursor for double width characters (GH-5319)
Delegate all character input to the character event handler (CC-4192)
Update til::bitmap to use dynamic_bitset<> + libpopcnt (GH-5092)
Merged PR 4465022: [Git2Git] Merged PR 4464559: Console: Ingest OSS changes up to e0550798
Correct scrolling invalidation region for tmux in pty w/ bitmap (GH-5122)
Render row-by-row instead of invalidating entire screen (GH-5185)
Make conechokey use ReadConsoleInputW by default (GH-5148)
Manually pass mouse wheel messages to TermControls (GH-5131)
This fixes C-M-space for WSL but not for Win32, but I'm not sure there's a problem in Win32 quite yet. (GH-5208)
Fix copying wrapped lines by implementing better scrolling (GH-5181)
Emit lines wrapped due to spaces at the end correctly (GH-5294)
Remove unneeded whitespace (CC-5162)
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/200414-1630 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 90031afa8114b7d95e3993573fc8449a1524a7fd
Related work items: #25439646
2020-04-21 17:44:56 +00:00
476 changed files with 10729 additions and 483895 deletions
[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
</summary>
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. 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:
* ... **misspelled**, then please *correct* them instead of using the command.
* ... *names*, please add them to `.github/actions/spelling/allow/names.txt`.
* ... APIs, you can add them to a file in `.github/actions/spelling/allow/`.
* ... just things you're using, please add them to an appropriate file in `.github/actions/spelling/expect/`.
* ... tokens you only need in one place and shouldn't *generally be used*, you can add an item in an appropriate file in `.github/actions/spelling/patterns/`.
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>If the flagged items are :exploding_head: false positives</summary>
If items relate to a ...
* binary file (or some other file you wouldn't want to check at all).
Please add a file path to the `excludes.txt` file matching the containing file.
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](
../tree/HEAD/README.md) (on whichever branch you're using).
* 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 )
@@ -125,7 +125,7 @@ Team members will be happy to help review specs and guide them to completion.
### Help Wanted
Once the team have approved an issue/spec, development can proceed. If no developers are immediately available, the spec can be parked ready for a developer to get started. Parked specs' issues will be labeled "Help Wanted". To find a list of development opportunities waiting for developer involvement, visit the Issues and filter on [the Help-Wanted label](https://github.com/microsoft/terminal/labels/Help-Wanted).
Once the team have approved an issue/spec, development can proceed. If no developers are immediately available, the spec can be parked ready for a developer to get started. Parked specs' issues will be labeled "Help Wanted". To find a list of development opportunities waiting for developer involvement, visit the Issues and filter on [the Help-Wanted label](https://github.com/microsoft/terminal/labels/Help%20Wanted).
---
@@ -155,4 +155,4 @@ Once your code has been reviewed and approved by the requisite number of team me
## Thank you
Thank you in advance for your contribution! Now, [what's next on the list](https://github.com/microsoft/terminal/labels/Help-Wanted)? 😜
Thank you in advance for your contribution! Now, [what's next on the list](https://github.com/microsoft/terminal/labels/Help%20Wanted)? 😜
@@ -10,6 +11,7 @@ This repository contains the source code for:
Related repositories include:
* [Windows Terminal Documentation](https://docs.microsoft.com/windows/terminal) ([Repo: Contribute to the docs](https://github.com/MicrosoftDocs/terminal))
* [Console API Documentation](https://github.com/MicrosoftDocs/Console-Docs)
Install the [Windows Terminal from the Microsoft Store][store-install-link]. This allows you to always be on the latest version when we release new builds with automatic upgrades.
Install the [Windows Terminal from the Microsoft Store][store-install-link]. This allows you to always be on the latest version when we release new builds with automatic upgrades.
This is our preferred method.
@@ -34,6 +36,14 @@ For users who are unable to install Terminal from the Microsoft Store, Terminal
> * Be sure to install the [Desktop Bridge VC++ v14 Redistributable Package](https://www.microsoft.com/en-us/download/details.aspx?id=53175) otherwise Terminal may not install and/or run and may crash at startup
> * 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!
#### Via Windows Package Manager CLI (aka winget)
[winget](https://github.com/microsoft/winget-cli) users can download and install the latest Terminal release by installing the `Microsoft.WindowsTerminal` package:
```powershell
wingetinstall--id=Microsoft.WindowsTerminal-e
```
#### Via Chocolatey (unofficial)
[Chocolatey](https://chocolatey.org) users can download and install the latest Terminal release by installing the `microsoft-windows-terminal` package:
The plan for delivering Windows Terminal v1.0 [is described here](/doc/terminal-v1-roadmap.md), and will be updated as the project proceeds.
---
## Terminal & Console Overview
Please take a few minutes to review the overview below before diving into the code:
@@ -131,7 +135,7 @@ Solution: Make sure you're building & deploying the `CascadiaPackage` project in
## Documentation
All project documentation is located in the `./doc` folder. If you would like to contribute to the documentation, please submit a pull request.
All project documentation is located at aka.ms/terminal-docs. If you would like to contribute to the documentation, please submit a pull request on the [Windows Terminal Documentation repo](https://github.com/MicrosoftDocs/terminal).
---
@@ -226,4 +230,4 @@ For more information see the [Code of Conduct FAQ][conduct-FAQ] or contact [open
Properties listed below affect the entire window, regardless of the profile settings.
@@ -21,6 +21,9 @@ Properties listed below affect the entire window, regardless of the profile sett
| `tabWidthMode` | Optional | String | `equal` | Sets the width of the tabs. Possible values: `"equal"`, `"titleLength"` |
| `wordDelimiters` | Optional | String | <code> /\()"'-:,.;<>~!@#$%^&*|+=[]{}~?│</code><br>_(`│` is `U+2502 BOX DRAWINGS LIGHT VERTICAL`)_ | Determines the delimiters used in a double click selection. |
| `confirmCloseAllTabs` | Optional | Boolean | `true` | When set to `true` closing a window with multiple tabs open WILL require confirmation. When set to `false` closing a window with multiple tabs open WILL NOT require confirmation. |
| `disabledProfileSources` | Optional | Array[String] | `[]` | Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup. This array can contain any combination of `Windows.Terminal.Wsl`, `Windows.Terminal.Azure`, or `Windows.Terminal.PowershellCore`. For more information, see [UsingJsonSettings.md](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#dynamic-profiles) |
| `experimental.rendering.forceFullRepaint` | Optional | Boolean | `false` | When set to true, we will redraw the entire screen each frame. When set to false, we will render only the updates to the screen between frames. |
| `experimental.rendering.software` | Optional | Boolean | `false` | When set to true, we will use the software renderer (a.k.a. WARP) instead of the hardware one. |
## Profiles
Properties listed below are specific to each unique profile.
@@ -42,8 +45,9 @@ Properties listed below are specific to each unique profile.
| `cursorColor` | Optional | String | | Sets the cursor color of the profile. Overrides `cursorColor` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
| `cursorHeight` | Optional | Integer | | Sets the percentage height of the cursor starting from the bottom. Only works when `cursorShape` is set to `"vintage"`. Accepts values from 25-100. |
| `cursorShape` | Optional | String | `bar` | Sets the cursor shape for the profile. Possible values: `"vintage"` ( ▃ ), `"bar"` ( ┃ ), `"underscore"` ( ▁ ), `"filledBox"` ( █ ), `"emptyBox"` ( ▯ ) |
| `fontFace` | Optional | String | `Cascadia Code` | Name of the font face used in the profile. We will try to fallback to Consolas if this can't be found or is invalid. |
| `fontFace` | Optional | String | `Cascadia Mono` | Name of the font face used in the profile. We will try to fallback to Consolas if this can't be found or is invalid. |
| `fontSize` | Optional | Integer | `12` | Sets the font size. |
| `fontWeight` | Optional | String | `normal` | Sets the weight (lightness or heaviness of the strokes) for the given font. Possible values: `"thin"`, `"extra-light"`, `"light"`, `"semi-light"`, `"normal"`, `"medium"`, `"semi-bold"`, `"bold"`, `"extra-bold"`, `"black"`, `"extra-black"`, or the corresponding numeric representation of OpenType font weight. |
| `foreground` | Optional | String | | Sets the foreground color of the profile. Overrides `foreground` set in color scheme if `colorscheme` is set. Uses hex color format: `#rgb` or `"#rrggbb"`. |
| `hidden` | Optional | Boolean | `false` | If set to true, the profile will not appear in the list of profiles. This can be used to hide default profiles and dynamically generated profiles, while leaving them in your settings file. |
| `historySize` | Optional | Integer | `9001` | The number of lines above the ones displayed in the window you can scroll back to. |
@@ -92,7 +96,7 @@ Properties listed below are specific to each custom key binding.
| Property | Necessity | Type | Description |
| -------- | ---- | ----------- | ----------- |
| `command` | _Required_ | String | The command executed when the associated key bindings are pressed. |
| `keys` | _Required_ | Array[String] | Defines the key combinations used to call the command. |
| `keys` | _Required_ | Array[String] or String | Defines the key combinations used to call the command. |
| `action` | Optional | String | Adds additional functionality to certain commands. |
"description":"The index of the profile in the new tab dropdown to open"
"description":"The index of the profile in the new tab dropdown (starting at 0)"
}
},
"type":"object"
@@ -134,7 +141,7 @@
"singleLine":{
"type":"boolean",
"default":false,
"description":"If true, newlines are removed and whitespace is maintained. If false, whitespace is removed and newlines are maintained."
"description":"If true, the copied content will be copied as a single line (even if there are hard line breaks presentin the text). If false, newlines persist from the selected text."
}
}
}
@@ -214,11 +221,11 @@
"split":{
"$ref":"#/definitions/SplitState",
"default":"auto",
"description":"The orientation to split the pane in, either vertical (think [|]), horizontal (think [-]), or auto (splits pane based on remaining space)"
"description":"The orientation to split the pane in. Possible values:\n -\"auto\" (splits pane based on remaining space)\n -\"horizontal\" (think [-])\n -\"vertical\" (think [|])"
},
"splitMode":{
"default":"duplicate",
"description":"Control how the pane splits. Only accepts `duplicate` which will duplicate the focused pane's profile into a new pane."
"description":"Control how the pane splits. Only accepts \"duplicate\" which will duplicate the focused pane's profile into a new pane."
}
}
}
@@ -242,7 +249,7 @@
]
},
"keys":{
"description":"Defines the key combinations used to call the command.",
"description":"Defines the key combinations used to call the command. It must be composed of...\n -any number of modifiers (ctrl/alt/shift)\n -a non-modifier key",
"oneOf":[
{
"$ref":"#/definitions/KeyChordSegment"
@@ -269,7 +276,7 @@
"properties":{
"alwaysShowTabs":{
"default":true,
"description":"When set to true, tabs are always displayed. When set to false and showTabsInTitlebar is set to false, tabs only appear after opening a new tab.",
"description":"When set to true, tabs are always displayed. When set to false and \"showTabsInTitlebar\" is set to false, tabs only appear after opening a new tab.",
"type":"boolean"
},
"copyOnSelect":{
@@ -284,7 +291,22 @@
},
"defaultProfile":{
"$ref":"#/definitions/ProfileGuid",
"description":"Sets the default profile. Opens by clicking the '+' icon or typing the key binding assigned to 'newTab'. The guid of the desired default profile is used as the value."
"description":"Sets the default profile. Opens by clicking the \"+\" icon or typing the key binding assigned to \"newTab\". The \"guid\" of the desired default profile is used as the value."
},
"disabledProfileSources":{
"description":"Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup.",
"items":{
"$ref":"#/definitions/DynamicProfileSource"
},
"type":"array"
},
"experimental.rendering.forceFullRepaint":{
"description":"When set to true, we will redraw the entire screen each frame. When set to false, we will render only the updates to the screen between frames.",
"type":"boolean"
},
"experimental.rendering.software":{
"description":"When set to true, we will use the software renderer (a.k.a. WARP) instead of the hardware one.",
"type":"boolean"
},
"initialCols":{
"default":120,
@@ -295,7 +317,7 @@
},
"initialPosition":{
"$ref":"#/definitions/Coordinates",
"description":"The position of the top left corner of the window upon first load. On a system with multiple displays, these coordinates are relative to the top left of the primary display. If launchMode is set to maximized, the window will be maximized on the monitor specified by those coordinates."
"description":"The position of the top left corner of the window upon first load. On a system with multiple displays, these coordinates are relative to the top left of the primary display. If \"launchMode\" is set to maximized, the window will be maximized on the monitor specified by those coordinates."
},
"initialRows":{
"default":30,
@@ -315,10 +337,10 @@
},
"rowsToScroll":{
"default":"system",
"description":"The number of rows to scroll at a time with the mouse wheel. This will override the system setting if the value is not zero or 'system'.",
"description":"The number of rows to scroll at a time with the mouse wheel. This will override the system setting if the value is not zero or \"system\".",
"maximum":999,
"minimum":0,
"type":["integer","string"]
"type":["integer","string"]
},
"keybindings":{
"description":"Properties are specific to each custom key binding.",
@@ -329,7 +351,7 @@
},
"theme":{
"default":"system",
"description":"Sets the theme of the application.",
"description":"Sets the theme of the application. The special value \"system\" refers to the active Windows system theme.",
"enum":[
"light",
"dark",
@@ -344,17 +366,17 @@
},
"showTerminalTitleInTitlebar":{
"default":true,
"description":"When set to true, titlebar displays the title of the selected tab. When set to false, titlebar displays 'Windows Terminal'.",
"description":"When set to true, titlebar displays the title of the selected tab. When set to false, titlebar displays \"Windows Terminal\".",
"type":"boolean"
},
"snapToGridOnResize":{
"default":false,
"description":"When set to true, the window will snap to the nearest character boundary on resize. When false, the window will resize 'smoothly'",
"description":"When set to true, the window will snap to the nearest character boundary on resize. When false, the window will resize smoothly",
"type":"boolean"
},
"tabWidthMode":{
"default":"equal",
"description":"Sets the width of the tabs.",
"description":"Sets the width of the tabs. Possible values include:\n -\"equal\" sizes each tab to the same width\n -\"titleLength\" sizes each tab to the length of its title",
"enum":[
"equal",
"titleLength"
@@ -368,8 +390,8 @@
},
"confirmCloseAllTabs":{
"default":true,
"description":"When set to `true` closing a window with multiple tabs open WILL require confirmation. When set to `false` closing a window with multiple tabs open WILL NOT require confirmation.",
"type":"boolean"
"description":"When set to \"true\" closing a window with multiple tabs open will require confirmation. When set to \"false\", the confirmation dialog will not appear.",
"type":"boolean"
}
},
"required":[
@@ -401,11 +423,11 @@
"background":{
"$ref":"#/definitions/Color",
"default":"#0c0c0c",
"description":"Sets the background color of the profile. Overrides background set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\".",
"description":"Sets the background color of the text. Overrides \"background\" from the colorscheme. Uses hex color format: \"#rrggbb\".",
"type":["string","null"]
},
"backgroundImage":{
"description":"Sets the file location of the Image to draw over the window background.",
"description":"Sets the file location of the image to draw over the window background.",
"type":["string","null"]
},
"backgroundImageAlignment":{
@@ -421,12 +443,14 @@
"topLeft",
"topRight"
],
"description":"Sets how the background image aligns to the boundaries of the window. Possible values: \"center\", \"left\", \"top\", \"right\", \"bottom\", \"topLeft\", \"topRight\", \"bottomLeft\", \"bottomRight\"",
"type":"string"
},
"backgroundImageOpacity":{
"description":"(Not in SettingsSchema.md)",
"maximum":1,
"minimum":0,
"default":1.0,
"description":"Sets the transparency of the background image. Accepts floating point values from 0-1.",
"maximum":1.0,
"minimum":0.0,
"type":"number"
},
"backgroundImageStretchMode":{
@@ -442,7 +466,7 @@
},
"closeOnExit":{
"default":"graceful",
"description":"Sets how the profile reacts to termination or failure to launch. Possible values:\"graceful\" (close when exit is typed or the process exits normally), \"always\" (always close) and \"never\" (never close).true and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
"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.",
"oneOf":[
{
"enum":[
@@ -462,109 +486,27 @@
"description":"Name of the terminal color scheme to use. Color schemes are defined under \"schemes\".",
"type":"string"
},
"colorTable":{
"description":"Array of colors used in the profile if colorscheme is not set. Colors use hex color format: \"#rrggbb\". Ordering is as follows: [black, red, green, yellow, blue, magenta, cyan, white, bright black, bright red, bright green, bright yellow, bright blue, bright magenta, bright cyan, bright white]",
"items":{
"additionalProperties":false,
"properties":{
"background":{
"$ref":"#/definitions/Color",
"description":"Sets the background color of the color table."
},
"black":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI black."
},
"blue":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI blue."
},
"brightBlack":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright black."
},
"brightBlue":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright blue."
},
"brightCyan":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright cyan."
},
"brightGreen":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright green."
},
"brightPurple":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright purple."
},
"brightRed":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright red."
},
"brightWhite":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright white."
},
"brightYellow":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI bright yellow."
},
"cyan":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI cyan."
},
"foreground":{
"$ref":"#/definitions/Color",
"description":"Sets the foreground color of the color table."
},
"green":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI green."
},
"purple":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI purple."
},
"red":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI red."
},
"white":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI white."
},
"yellow":{
"$ref":"#/definitions/Color",
"description":"Sets the color used as ANSI yellow."
}
},
"type":"object"
},
"type":"array"
},
"commandline":{
"description":"Executable used in the profile.",
"type":"string"
},
"connectionType":{
"$ref":"#/definitions/ProfileGuid",
"description":"A GUID reference to a connection type. Currently undocumented as of 0.3, this is used for Azure Cloud Shell"
},
"cursorColor":{
"$ref":"#/definitions/Color",
"description":"Sets the cursor color of the profile. Overrides cursor color set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\"."
"oneOf":[
{"$ref":"#/definitions/Color"},
{"type":"null"}
],
"description":"Sets the color of the cursor. Overrides the cursor color from the color scheme. Uses hex color format: \"#rrggbb\"."
},
"cursorHeight":{
"description":"Sets the percentage height of the cursor starting from the bottom. Only works when cursorShape is set to \"vintage\". Accepts values from 25-100.",
"maximum":100,
"minimum":25,
"type":["integer","null"]
"type":["integer","null"],
"default":25
},
"cursorShape":{
"default":"bar",
"description":"Sets the cursor shape for the profile. Possible values: \"vintage\" ( ▃ ), \"bar\" ( ┃, default ), \"underscore\" ( ▁ ), \"filledBox\" ( █ ), \"emptyBox\" ( ▯ )",
"description":"Sets the shape of the cursor. Possible values:\n -\"bar\" ( ┃, default )\n -\"emptyBox\" ( ▯ )\n -\"filledBox\" ( █ )\n -\"underscore\" ( ▁ )\n -\"vintage\" ( ▃ )",
"enum":[
"bar",
"emptyBox",
@@ -579,20 +521,46 @@
"type":"boolean"
},
"fontFace":{
"default":"Cascadia Code",
"default":"Cascadia Mono",
"description":"Name of the font face used in the profile.",
"type":"string"
},
"fontSize":{
"default":12,
"description":"Sets the font size.",
"description":"Size of the font in points.",
"minimum":1,
"type":"integer"
},
"fontWeight":{
"default":"normal",
"description":"Sets the weight (lightness or heaviness of the strokes) for the given font. Possible values:\n -\"thin\"\n -\"extra-light\"\n -\"light\"\n -\"semi-light\"\n -\"normal\" (default)\n -\"medium\"\n -\"semi-bold\"\n -\"bold\"\n -\"extra-bold\"\n -\"black\"\n -\"extra-black\" or the corresponding numeric representation of OpenType font weight.",
"oneOf":[
{
"enum":[
"thin",
"extra-light",
"light",
"semi-light",
"normal",
"medium",
"semi-bold",
"bold",
"extra-bold",
"black",
"extra-black"
],
"type":"string"
},
{
"maximum":990,
"minimum":100,
"type":"integer"
}
}
"foreground":{
"$ref":"#/definitions/Color",
"default":"#cccccc",
"description":"Sets the foreground color of the profile. Overrides foreground set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\".",
"description":"Sets the text color. Overrides \"foreground\" from the colorscheme. Uses hex color format: \"#rrggbb\".",
"type":["string","null"]
},
"guid":{
@@ -621,7 +589,7 @@
},
"padding":{
"default":"8, 8, 8, 8",
"description":"Sets the padding around the text within the window. Can have three different formats:\"#\" sets the same padding for all sides, \"#, #\" sets the same padding for left-right and top-bottom, and \"#, #, #, #\" sets the padding individually for left, top, right, and bottom.",
"description":"Sets the padding around the text within the window. Can have three different formats:\n -\"#\" sets the same padding for all sides \n -\"#, #\" sets the same padding for left-right and top-bottom\n -\"#, #, #, #\" sets the padding individually for left, top, right, and bottom.",
"description":"Sets the selection background color of the profile. Overrides selection background set in color scheme if colorscheme is set. Uses hex color format: \"#rrggbb\"."
"oneOf":[
{"$ref":"#/definitions/Color"},
{"type":"null"}
],
"description":"Sets the background color of selected text. Overrides selectionBackground set in the color scheme. Uses hex color format: \"#rrggbb\"."
},
"snapOnInput":{
"default":true,
@@ -653,7 +624,8 @@
},
"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.",
"type":"boolean"
"type":"boolean",
"default":false
},
"tabTitle":{
"description":"If set, will replace the name as the title to pass to the shell on startup. Some shells (like bash) may choose to ignore this initial value, while others (cmd, powershell) may use this value over the lifetime of the application.",
Creates a new pane in the currently focused tab by splitting the given pane
vertically or horizontally.
vertically or horizontally. <sup>[[1](#footnote-1)]</sup>
**Parameters**:
*`-H`, `-V`: Used to indicate which direction to split the pane. `-V` is
"vertically" (think `[|]`), and `-H` is "horizontally" (think `[-]`). If
omitted, defaults to "auto", which splits the current pane in whatever the
larger dimension is. If both `-H` and `-V` are provided, defaults to vertical.
*`-H,--horizontal`, `-V,--vertical`: Used to indicate which direction to split
the pane. `-V` is "vertically" (think `[|]`), and `-H` is "horizontally"
(think `[-]`). If omitted, defaults to "auto", which splits the current pane
in whatever the larger dimension is. If both `-H` and `-V` are provided,
defaults to vertical.
*`[terminal_parameters]`: See [[terminal_parameters]](#terminal_parameters).
#### `focus-tab`
@@ -89,6 +90,10 @@ following:
selected profile. If the user wants to use a `;` in this commandline, it
should be escaped as `\;`.
### Notes
* <span id="footnote-1"></span> [1]: If you try to run a `wt` commandline while running in a Windows Terminal window, the commandline will _always_ create a new window by default. Being able to run `wt` commandlines in the _current_ window is planned in the future - for more information, refer to [#4472].
## Examples
### Open Windows Terminal in the current directory
@@ -120,9 +125,77 @@ This creates a new Windows Terminal window with one tab, and 3 panes:
*`split-pane -p "Windows PowerShell"`: This will create a new pane, split from
the parent with the default profile. This pane will open with the "Windows
PowerShell" profile
*`split-pane -H wsl.exe`: This will create a third pane, slit _horizontally_
*`split-pane -H wsl.exe`: This will create a third pane, split _horizontally_
from the "Windows PowerShell" pane. It will be running the default profile,
and will use `wsl.exe` as the commandline (instead of the default profile's
`commandline`).
### Using multiple commands from PowerShell
The Windows Terminal uses the semicolon character `;` as a delimiter for
separating subcommands in the `wt` commandline. Unfortunately, `powershell` also
uses `;` as a command separator. To work around this you can use the following
tricks to help run multiple wt sub commands from powershell. In all the
following examples, we'll be creating a new Terminal window with three panes -
one running `cmd`, one with `powershell`, and a last one running `wsl`.
In each of the following examples, we're using the `Start-Process` command to
run `wt`. For more information on why we're using `Start-Process`, see ["Using
`start`"](#using-start) below.
#### Single quoted parameters (if you aren't calculating anything):
In this example, we'll wrap all the parameters to `wt` in single quotes (`'`)
@@ -25,7 +25,7 @@ NOTE: The default shell is PowerShell; you can change this using the _Running a
### Command line options
None at this time. See issue [#607](https://github.com/microsoft/terminal/issues/607)
Windows Terminal has implemented a rich set of command-line options in part as response to issue [#607](https://github.com/microsoft/terminal/issues/607). See [UsingCommandlineArguments.md](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingCommandlineArguments.md) for details.
## Multiple Tabs
@@ -45,7 +45,7 @@ To customize the shell list, see the _Configuring Windows Terminal_ section belo
## Starting a new PowerShell tab with admin privilege
There is no current plan to support this feature for security reasons. See issue [#623](https://github.com/microsoft/terminal/issues/632)
There is no current plan to support this feature for security reasons. See issue [#632](https://github.com/microsoft/terminal/issues/632)
## Selecting and Copying Text in Windows Terminal
@@ -61,7 +61,7 @@ Copy and paste operations can also be keybound. For more information on how to b
## Add a "Open Windows Terminal Here" to File Explorer
Not currently supported "out of the box". See issue [#1060](https://github.com/microsoft/terminal/issues/1060)
Not currently supported "out of the box" (See issue [#1060](https://github.com/microsoft/terminal/issues/1060)). However, you can open Windows Terminal in current directory by typing `wt -d .` in the Explorer address bar.
## Configuring Windows Terminal
@@ -87,4 +87,5 @@ For an introduction to the various settings, see [Using Json Settings](UsingJson
2. Terminal zoom can be changed by holding <kbd>Ctrl</kbd> and scrolling with mouse.
3. Background opacity can be changed by holding <kbd>Ctrl</kbd>+<kbd>Shift</kbd> and scrolling with mouse. Note that acrylic transparency is limited by the OS only to focused windows.
4. Open Windows Terminal in current directory by typing `wt -d .` in the address bar.
5. Please add more Tips and Tricks.
5. Pin the Windows Terminal to the taskbar. Now it can be launched using the Windows shortcut <kbd>Win</kbd>+<kbd>Number</kbd> (e.g. <kbd>Win</kbd>+<kbd>1</kbd> or any other number based on the position in the taskbar!). Press <kbd>Win</kbd>+<kbd>Shift</kbd>+<kbd>Number</kbd> to always launch a new window.
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.
