This change adds a different label to the property sheet which will be
displayed when conhostv1 is missing. It explains why the legacy console
checkbox is not enabled.
Related work items: MSFT-46195288
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 41871b6f4c0bba64852bfbaa9255f7677246d6fe
In the Settings UI's Color Scheme page (where you edit the color scheme itself), update the color chip buttons to include the RGB value in the tooltip and screen reader announcements.
Closes#15985Closes#15983
## Validation Steps Performed
Tooltip and screen reader announcement is updated on launch and when a new value is selected.
This PR enables alternate scroll mode by default, and also fixes the
precedence so if there is any other mouse tracking mode enabled, that
will take priority.
## Validation Steps Performed
I've manually tested by viewing a file with `less`, and confirmed that
it can now scroll using the mouse wheel by default. Also tested mouse
mouse in vim and confirmed that still works.
## PR Checklist
Closes#13187
This pull request started out very differently. I was going to move all
the EDP code from the internal `conint` project into the public, because
EDP is [fully documented]!
Well, it doesn't have any headers in the SDK.
Or import libraries.
And it's got a deprecation notice:
> [!NOTE]
> Starting in July 2022, Microsoft is deprecating Windows Information
> Protection (WIP) and the APIs that support WIP. Microsoft will
continue
> to support WIP on supported versions of Windows. New versions of
Windows
> won't include new capabilities for WIP, and it won't be supported in
> future versions of Windows.
So I'm blasting it out the airlock instead.
[fully documented]:
https://learn.microsoft.com/en-us/windows/win32/devnotes/windows-information-protection-api
The tolerance value for a similar repo was changed from 0.8 to 0.75.
This is because I changed the backend service for this to use pinecone
instead of Azure AI search (see here
f72fa59e23
) and the metric changed as a result of that. They are slightly lower
than they were before, so this should offset that.
While #16444 left wavy lines in an amazing state already, there were
a few more things that could be done to make GDI look more consistent
with other well known Windows applications.
But before that, a couple unrelated, but helpful changes were made:
* `GdiEngine::UpdateFont` was heavily modified to do all calculations
in floats. All modern CPUs have fast FPUs and even the fairly slow
`lroundf` function is so fast (relatively) nowadays that in a cold
path like this, we can liberally call it to convert back to `int`s.
This makes intermediate calculation more accurate and consistent.
* `GdiEngine::PaintBufferGridLines` was exception-unsafe due to its
use of a `std::vector` with catch clause and this PR fixes that.
Additionally, the vector was swapped out with a `til::small_vector`
to reduce heap allocations. (Arena allocators!)
* RenderingTests was updated to cover styled underlines
With that in place, these improvements were done:
* Word's double-underline algorithm was ported over from `AtlasEngine`.
It uses a half underline-width (aka `thinLineWidth`) which will now
also be used for wavy lines to make them look a bit more filigrane.
* The Bézier curve for wavy/curly underlines was modified to use
control points at (0.5,0.5) and (0.5,-0.5) respectively. This results
in a maxima at y=0.1414 which is much closer to a sine curve with a
maxima at 1/(2pi) = 0.1592. Previously, the maxima was a lot higher
(roughly 4x) depending on the aspect ratio of the glyphs.
* Wavy underlines don't depend on the aspect ratio of glyphs anymore.
This previously led to several problems depending on the exact font.
The old renderer would draw exactly 3 periods of the wave into
each cell which would also ensure continuity between cells.
Unfortunately, this meant that waves could look inconsistent.
The new approach always uses the aforementioned sine-like waves.
* The wavy underline offset was clamped so that it's never outside of
bounds of a line. This avoids clipping.
* Compile RenderingTests and run it
* Using Consolas, MS Gothic and Cascadia Code while Ctrl+Scrolling
up and down works as expected without clipping ✅
(cherry picked from commit 99193c9a3f)
Service-Card-Id: 91356394
Service-Version: 1.19
Fixes Curlyline being drawn as single underline in some cases
**Detailed Description**
- Curlyline is drawn at all font sizes.
- We might render a curlyline that is clipped in cases where we don't
have enough space to draw a full curlyline. This is to give users a
consistent view of Curlylines. Previously in those cases, it was drawn
as a single underline.
- Removed minimum threshold `minCurlyLinePeakHeight` for Curlyline
drawing.
- GDIRender changes:
- Underline offset now points to the (vertical) mid position of the
underline. Removes redundant `underlineMidY` calculation inside the draw
call.
Closes#16288
(cherry picked from commit f5b45c25c9)
Service-Card-Id: 91349182
Service-Version: 1.19
Add support for underline style and color in the renderer
> [!IMPORTANT]
> The PR adds underline style and color feature to AtlasEngine (WT) and
GDIRenderer (Conhost) only.
After the underline style and color feature addition to Conpty, this PR
takes it further and add support for rendering them to the screen!
Out of five underline styles, we already supported rendering for 3 of
those types (Singly, Doubly, Dotted) in some form in our (Atlas)
renderer. The PR adds the remaining types, namely, Dashed and Curly
underlines support to the renderer.
- All renderer engines now receive both gridline and underline color,
and the latter is used for drawing the underlines. **When no underline
color is set, we use the foreground color.**
- Curly underline is rendered using `sin()` within the pixel shader.
- To draw underlines for DECDWL and DECDHL, we send the line rendition
scale within `QuadInstance`'s texcoord attribute.
- In GDI renderer, dashed and dotted underline is drawn using `HPEN`
with a desired style. Curly line is a cubic Bezier that draws one wave
per cell.
## PR Checklist
- ✅ Set the underline color to underlines only, without affecting the
gridline color.
- ❌ Port to DX renderer. (Not planned as DX renderer soon to be replaced
by **AtlasEngine**)
- ✅ Port underline coloring and style to GDI renderer (Conhost).
- ✅ Wide/Tall `CurlyUnderline` variant for `DECDWL`/`DECDHL`.
Closes#7228
(cherry picked from commit e268c1c952)
Service-Card-Id: 91349180
Service-Version: 1.19
Even with the previous fixes we still randomly encounter win32-
input-mode sequences that are broken up in exactly such a way that
e.g. lone escape keys are encounters. Those for instance clear the
current prompt. The remaining parts of the sequence are then visible.
This changeset fixes the issue by skipping the entire force-to-ground
code whenever we saw at least 1 win32-input-mode sequence.
Related to #16343
## Validation Steps Performed
* Host a ConPTY inside ConPTY (= double the trouble) with cmd.exe
* Paste random amounts of text
* In the old code spurious `[..._` strings are seen
* In the new code they're consistently gone ✅
(cherry picked from commit bc18348967)
Service-Card-Id: 91337332
Service-Version: 1.19
Added wrapping to highlighted selection when selecting a word, added
tests for it
## Detailed Description of the Pull Request / Additional comments
- Modified GetWordStart and GetWordEnd and their helpers to no longer be
bounded by the right and left viewport ranges
- Kept same functionality (does not wrap) when selecting wrapped
whitespace
- Added tests to TextBufferTests.cpp to include cases of wrapping text
## Validation Steps Performed
- Ran locally and verified selection works properly
- Tests passed locally
Closes#4009
Even with the previous fixes we still randomly encounter win32-
input-mode sequences that are broken up in exactly such a way that
e.g. lone escape keys are encounters. Those for instance clear the
current prompt. The remaining parts of the sequence are then visible.
This changeset fixes the issue by skipping the entire force-to-ground
code whenever we saw at least 1 win32-input-mode sequence.
Related to #16343
## Validation Steps Performed
* Host a ConPTY inside ConPTY (= double the trouble) with cmd.exe
* Paste random amounts of text
* In the old code spurious `[..._` strings are seen
* In the new code they're consistently gone ✅
This makes 3 improvements:
* 16x larger input buffer size improves behavior when pasting
clipboard contents while the win32-input-mode is enabled,
as each input character is roughly 15-20x longer after encoding.
* Translate UTF8 to UTF16 outside of the console lock.
* Preserve the UTF16 buffer between reads for less mallocs.
(cherry picked from commit 171a21ad48)
Service-Card-Id: 91347494
Service-Version: 1.19
This is just a minor, unimportant cleanup to remove code duplication
in `_flushBuffer`, which called `SetCursorPosition` twice each time
the cursor position changed.
17cc109 and e9de646 both made the same mistake: When cleaning up our
telemetry code they also removed the calls to `TraceLoggingRegister`
which also broke regular tracing. Windows Defender in particular uses
the "CookedRead" event to monitor for malicious shell commands.
This doesn't fix it the "right way", because destructors of statics
aren't executed when DLLs are unloaded. But I felt like that this is
fine because we have way more statics than that in conhost land,
all of which have the same kind of issue.
While #16444 left wavy lines in an amazing state already, there were
a few more things that could be done to make GDI look more consistent
with other well known Windows applications.
But before that, a couple unrelated, but helpful changes were made:
* `GdiEngine::UpdateFont` was heavily modified to do all calculations
in floats. All modern CPUs have fast FPUs and even the fairly slow
`lroundf` function is so fast (relatively) nowadays that in a cold
path like this, we can liberally call it to convert back to `int`s.
This makes intermediate calculation more accurate and consistent.
* `GdiEngine::PaintBufferGridLines` was exception-unsafe due to its
use of a `std::vector` with catch clause and this PR fixes that.
Additionally, the vector was swapped out with a `til::small_vector`
to reduce heap allocations. (Arena allocators!)
* RenderingTests was updated to cover styled underlines
With that in place, these improvements were done:
* Word's double-underline algorithm was ported over from `AtlasEngine`.
It uses a half underline-width (aka `thinLineWidth`) which will now
also be used for wavy lines to make them look a bit more filigrane.
* The Bézier curve for wavy/curly underlines was modified to use
control points at (0.5,0.5) and (0.5,-0.5) respectively. This results
in a maxima at y=0.1414 which is much closer to a sine curve with a
maxima at 1/(2pi) = 0.1592. Previously, the maxima was a lot higher
(roughly 4x) depending on the aspect ratio of the glyphs.
* Wavy underlines don't depend on the aspect ratio of glyphs anymore.
This previously led to several problems depending on the exact font.
The old renderer would draw exactly 3 periods of the wave into
each cell which would also ensure continuity between cells.
Unfortunately, this meant that waves could look inconsistent.
The new approach always uses the aforementioned sine-like waves.
* The wavy underline offset was clamped so that it's never outside of
bounds of a line. This avoids clipping.
## Validation Steps Performed
* Compile RenderingTests and run it
* Using Consolas, MS Gothic and Cascadia Code while Ctrl+Scrolling
up and down works as expected without clipping ✅
**FIRST TIME CONTRIBUTOR**
Follows the existing selection code as much as possible.
Updated logic that finds selection rectangles to also identify search
rectangles.
Right now, this feature only works in the new Atlas engine -- it uses
the background and foreground color bitmaps to quickly and efficiently
set the colors of a whole region of text.
Closes#7561
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
This makes 3 improvements:
* 16x larger input buffer size improves behavior when pasting
clipboard contents while the win32-input-mode is enabled,
as each input character is roughly 15-20x longer after encoding.
* Translate UTF8 to UTF16 outside of the console lock.
* Preserve the UTF16 buffer between reads for less mallocs.
The `GenRTF(...)` was using `\highlight` control word for sending
background text color in the RTF format during a copy command. This
doesn't work correctly, since many applications (E.g. MSWord) don't
support full RGB with `\highlight`, and instead uses an approximation of
what is received. For example, `rgb(197, 15, 31)` becomes `rgb(255, 0,
255)`. Also, the standard way of using background colors is `\cbN`
control word, which isn't supported as per the [RTF Spec 1.9.1]
in Word.
But it briefly mentioned a workaround at Pg. 23, which seems to work on
all the RTF editors I tested.
The PR makes the changes to use `\chshdng0\chcbpatN` for the background
coloring.
Also did some refactoring to make the implementation concise.
## Validation Steps Performed
Verified that the background is correctly copied on below editors:
- MSWord
- WordPad
- LibreOffice
- Outlook
[RTF Spec 1.9.1]: https://msopenspecs.azureedge.net/files/Archive_References/[MSFT-RTF].pdf
(cherry picked from commit 310814bb30)
Service-Card-Id: 91349195
Service-Version: 1.19
Fixes Curlyline being drawn as single underline in some cases
**Detailed Description**
- Curlyline is drawn at all font sizes.
- We might render a curlyline that is clipped in cases where we don't
have enough space to draw a full curlyline. This is to give users a
consistent view of Curlylines. Previously in those cases, it was drawn
as a single underline.
- Removed minimum threshold `minCurlyLinePeakHeight` for Curlyline
drawing.
- GDIRender changes:
- Underline offset now points to the (vertical) mid position of the
underline. Removes redundant `underlineMidY` calculation inside the draw
call.
Closes#16288
This prevents an issue in conhost where older versions of Windows
Terminal (including the ones currently inbox in Windows, as well as
stable and preview) will *still* cause WSL interop to hang on startup.
Since VT input is erroneously re-encoded as Win32 input events on those
versions, we need to make sure we request the cursor position *before*
enabling Win32 input mode. That way, the CPR we get back is properly
encoded.
(cherry picked from commit 17867af534)
Service-Card-Id: 91301135
Service-Version: 1.19
This prevents an issue in conhost where older versions of Windows
Terminal (including the ones currently inbox in Windows, as well as
stable and preview) will *still* cause WSL interop to hang on startup.
Since VT input is erroneously re-encoded as Win32 input events on those
versions, we need to make sure we request the cursor position *before*
enabling Win32 input mode. That way, the CPR we get back is properly
encoded.
Changes any references of `> **Note**\` with `> [!NOTE]` to match the
new syntax for markdown files in GitHub.
Fixes the 14 November 2023 update to the alerts syntax in markdown
files:
> ## Update - 14 November 2023
> * The initial syntax using e.g. **Note** isn't supported any longer.
>
> https://github.com/orgs/community/discussions/16925
This changeset fixes an issue caused by #15991 where "chunked" escape
sequences would get corrupted. The fix is to simply not flush eagerly
anymore. I tried my best to keep the input lag reduction from #15991,
but unfortunately this isn't possible for console APIs.
Closes#16079
## Validation Steps Performed
* `type ascii.com` produces soft font ASCII characters ✅
(cherry picked from commit bdf2f6f274)
Service-Card-Id: 91283205
Service-Version: 1.19
This is my proposal to avoid aborting ConPTY input parsing because a
read accidentally got split up into more than one chunk. This happens a
lot with WSL for me, as I often get (for instance) a
`\x1b[67;46;99;0;32;` input followed immediately by a `1_` input. The
current logic would cause both of these to be flushed out to the client
application.
This PR fixes the issue by only flushing either a standalone escape
character or a escape+character combination. It basically limits the
previous code to just `VTStates::Ground` and `VTStates::Escape`.
I'm not using the `_state` member, because `VTStates::OscParam` makes no
distinction between `\x1b]` and `\x1b]1234` and I only want to flush the
former. I felt like checking the contents of `run` directly is easier to
understand.
Related to #16343
## Validation Steps Performed
* win32-input-mode sequences are now properly buffered ✅
* Standalone alt-key combinations are still being flushed ✅
(cherry picked from commit 5f5ef10571)
Service-Card-Id: 91270261
Service-Version: 1.19
Upgrades check-spelling to [v0.0.22](https://github.com/check-spelling/check-spelling/releases/tag/v0.0.22)
* refreshes workflow
* enables dependabot PRs to trigger CI (so that in the future you'll be
able to see breaking changes to the dictionary paths)
* refreshes metadata
* built-in handling of `\n`/`\r`/`\t` is removed -- This means that the
`patterns/0_*.txt` files can be removed.
* this specific PR includes some shim content, in
`allow/check-spelling-0.0.21.txt` -- once it this PR merges, it can be
removed on a branch and the next CI will clean out items from
`expect.txt` relating to the `\r` stuff and suggest replacement content.
* talking to the bot is enabled for forks (but not the master
repository)
* SARIF reporting is enabled for PRs w/in a single repository (not
across forks)
* In job reports, there's a summary table (space permitting) linking to
instances (this is a poor man's SARIF report)
* When a pattern splits a thing that results in check-spelling finding
an unrecognized token, that's reported with a distinct category
* When there are items in expect that not longer match anything but more
specific items do (e.g. `microsoft` vs. `Microsoft`), there's now a
specific category with help/advice
* Fancier excludes suggestions (excluding directories, file types, ...)
* Refreshed dictionaries
* The comment now links to the job summary (which includes SARIF link if
available, the details view, and a generated commit that people can use
if they're ok w/ the expect changes and don't want to run perl)
Validation
----------
1. the branch was developed in
https://github.com/check-spelling-sandbox/terminal/actions?query=branch%3Acheck-spelling-0.0.22
2. ensuring compatibility with 0.0.21 was done in
https://github.com/check-spelling-sandbox/terminal/pull/3
3. this version has been in development for a year and has quite a few
improvements, we've been actively dogfooding it throughout this period 😄
Additional Fixes
----------------
spelling: the
spelling: shouldn't
spelling: no
spelling: macos
spelling: github
spelling: fine-grained
spelling: coarse-grained
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
## Summary of the Pull Request
Added some Punctuation Marks as Required.
## References and Relevant Issues
None.
## Detailed Description of the Pull Request / Additional comments
There were some missing Punctuation Marks(Ex: Colon(:) and Full
Stop(.)), so I have added them.
## Validation Steps Performed
This is my proposal to avoid aborting ConPTY input parsing because a
read accidentally got split up into more than one chunk. This happens a
lot with WSL for me, as I often get (for instance) a
`\x1b[67;46;99;0;32;` input followed immediately by a `1_` input. The
current logic would cause both of these to be flushed out to the client
application.
This PR fixes the issue by only flushing either a standalone escape
character or a escape+character combination. It basically limits the
previous code to just `VTStates::Ground` and `VTStates::Escape`.
I'm not using the `_state` member, because `VTStates::OscParam` makes no
distinction between `\x1b]` and `\x1b]1234` and I only want to flush the
former. I felt like checking the contents of `run` directly is easier to
understand.
Related to #16343
## Validation Steps Performed
* win32-input-mode sequences are now properly buffered ✅
* Standalone alt-key combinations are still being flushed ✅
`EnableScrollbar()` and especially `SetScrollInfo()` are prohibitively
expensive functions nowadays. This improves throughput of good old
`type` in cmd.exe by ~10x, by briefly releasing the console lock.
## Validation Steps Performed
* `type`ing a file in `cmd` is as fast while the window is scrolling
as it is while it isn't scrolling ✅
* Scrollbar pops in and out when scroll-forward is disabled ✅
When ConPTY exits it should attempt to restore the state as it was
before it started. This is particularly important for the win32
input mode sequences, as Linux shells don't know what to do with it.
Related to #16343
## Validation Steps Performed
* Replace conhost with this
* Launch a Win32 application inside WSL
* Exit that application
* Shell prompt doesn't get filled with win32 input mode sequences ✅
(cherry picked from commit 70e51ae28d)
Service-Card-Id: 91246943
Service-Version: 1.19
When ConPTY exits it should attempt to restore the state as it was
before it started. This is particularly important for the win32
input mode sequences, as Linux shells don't know what to do with it.
Related to #16343
## Validation Steps Performed
* Replace conhost with this
* Launch a Win32 application inside WSL
* Exit that application
* Shell prompt doesn't get filled with win32 input mode sequences ✅
The final parameter, `updateBottom`, controls not just whether the
`_virtualBottom` is updated, but also whether the position is clamped
to be within the existing `_virtualBottom`. Setting this to `false`
thus broke scroll-forward as the `_virtualBottom` was now a constant.
## Validation Steps Performed
* Disable scroll-foward
* Press and hold Ctrl+C
* It scrolls past the viewport bottom ✅
(cherry picked from commit ab7a2f10c5)
Service-Card-Id: 91258882
Service-Version: 1.19
This changeset avoids re-encoding output from `AdaptDispatch`
via the win32-input-mode mechanism when VT input is enabled.
That is, an `AdaptDispatch` output like `\x1b[C` would otherwise
result in dozens of characters of input.
Related to #16343
## Validation Steps Performed
* Replace conhost with this
* Launch a Win32 application inside WSL
* ASCII keyboard inputs are represented as single `INPUT_RECORD`s ✅
(cherry picked from commit 0da37a134a)
Service-Card-Id: 91246942
Service-Version: 1.19
tl;dr: A coroutine lambda does not hold onto captured variables.
This causes an AV crash when closing tabs. I randomly noticed this
in a Debug build as the memory contents got replaced with 0xCD.
In a Release build this bug is probably fairly subtle and not common.
(cherry picked from commit 91fd7d0101)
Service-Card-Id: 91258717
Service-Version: 1.19
This enables AtlasEngine by default in the 1.19 release branch.
A future change will remove the alternative DxEngine entirely.
(cherry picked from commit 204ebf3b19)
Service-Card-Id: 91158876
Service-Version: 1.19
The final parameter, `updateBottom`, controls not just whether the
`_virtualBottom` is updated, but also whether the position is clamped
to be within the existing `_virtualBottom`. Setting this to `false`
thus broke scroll-forward as the `_virtualBottom` was now a constant.
## Validation Steps Performed
* Disable scroll-foward
* Press and hold Ctrl+C
* It scrolls past the viewport bottom ✅
This changeset avoids re-encoding output from `AdaptDispatch`
via the win32-input-mode mechanism when VT input is enabled.
That is, an `AdaptDispatch` output like `\x1b[C` would otherwise
result in dozens of characters of input.
Related to #16343
## Validation Steps Performed
* Replace conhost with this
* Launch a Win32 application inside WSL
* ASCII keyboard inputs are represented as single `INPUT_RECORD`s ✅
tl;dr: A coroutine lambda does not hold onto captured variables.
This causes an AV crash when closing tabs. I randomly noticed this
in a Debug build as the memory contents got replaced with 0xCD.
In a Release build this bug is probably fairly subtle and not common.
During `!measureOnly` the old code would increment `distance` twice.
Now it doesn't. :)
Closes#16356
## Validation Steps Performed
See updated test instructions in `doc/COOKED_READ_DATA.md`
(cherry picked from commit 654b755161)
Service-Card-Id: 91232745
Service-Version: 1.19
Since all VT parameters are treated to be at least 1 (and 1 if they're
absent or 0), `modifierParam > 0` was always true. This meant that
`ENHANCED_KEY` was always being set. It's unclear why `ENHANCED_KEY`
was used there, but it's likely not needed in general.
Closes#16266
## Validation Steps Performed
* Can't test this unless we fix the win32 input mode issue #16343❌
(cherry picked from commit be9fc200c7)
Service-Card-Id: 91159301
Service-Version: 1.19
Dustin Howett