maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/.github/actions/spelling/expect/expect.txt

2896 lines
24 KiB
Plaintext
Raw Normal View History

ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
AAAAAABBBBBBCCC
AAAAABBBBBBBCCC
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
AAAAABBBBBBCCC
Added even more quick exit in InsertAttrRuns (#5644) <!-- 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.
2020-04-29 22:08:37 +02:00
AAAAABCCCCCCCCC
AAAAADCCCCCCCCC
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ABANDONFONT
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
abcd
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ABCDEFGHIJKLMNO
ABCG
abf
Make til::color's COLORREF conversion more optimal (#7619) Clang (10) has no trouble optimizing the COLORREF conversion operator to a simple 32-bit load with mask (!) even though it's a series of bit shifts across multiple struct members. MSVC (19.24) doesn't make the same optimization decision, and it emits three 8-bit loads and some shifting. In any case, the optimization only applies at -O2 (clang) and above. In this commit, we leverage the spec-legality of using unions for type conversions and the overlap of four uint8_ts and a uint32_t to make the conversion very obvious to both compilers. x86_64 msvc | O0 | O1 | O2 ------------|----|----|-------------------- shifts | 12 | 11 | 11 (fully inlined) union | 5 | 1 | 1 (fully inlined) x86_64 clang | O0 | O1 | O2 + O3 -------------|----|----|-------------------- shifts | 14 | 5 | 1 (fully inlined) union | 9 | 3 | 1 (fully inlined) j4james brought up some concerns about til::color's minor wastefulness in https://github.com/microsoft/terminal/pull/7578#discussion_r487355989. This is a clear, simple transformation that saves us a few instructions in a relatively common case, so I'm accepting a micro-optimization even though we don't have data showing this to be a hot spot.
2020-09-14 20:51:03 +02:00
abgr
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
abi
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
ACCESSTOKEN
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
acec
acf
acidev
ACIOSS
ACover
actctx
ACTCTXW
activatable
ACTIVEBORDER
ACTIVECAPTION
ADDALIAS
ci: fix spelling
2021-02-11 22:48:28 +01:00
ADDB
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ADDREF
addressof
ADDSTRING
ADDTOOL
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
aef
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
AEnd
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
AFew
AFill
AFX
AHelper
ahz
AImpl
AInplace
ALIGNRIGHT
alloc
allocing
alpc
ALTERNATENAME
ALTF
ALTNUMPAD
ALWAYSTIP
amd
ansd
ansicode
ansicpg
ANSISYS
ANSISYSRC
ANSISYSSC
antialias
antialiasing
ANull
anycpu
AOn
APARTMENTTHREADED
APCs
api
APIENTRY
apiset
apos
APPBARDATA
appconsult
APPICON
appium
applet
appletname
applicationmodel
APPLMODAL
appmodel
apps
APPWINDOW
appx
appxbundle
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
appxerror
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
appxmanifest
APrep
apsect
APSTUDIO
archeologists
architected
argb
argc
args
argv
ARRAYSIZE
ARROWKEYS
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
asan
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ASBRST
ASBSET
ASDF
asdfghjkl
ASetting
ASingle
asm
asmv
asmx
aspnet
aspx
astextplain
AStomps
ASYNCWINDOWPOS
atch
ATest
attr
ATTRCOLOR
aumid
Authenticode
AUTOBUDDY
AUTOCHECKBOX
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
autogenerated
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
autohide
AUTOHSCROLL
automagically
autopositioning
AUTORADIOBUTTON
autoscrolling
Autowrap
AVerify
AVI
awch
azuredevopspodcast
azurewebsites
azzle
backend
backgrounded
ci: spelling: update to 0.0.15a; update whitelist (#5413) * 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 https://github.com/microsoft/terminal/commit/5740e197c20bea97b0afe4b396d0541691d02b2c 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.
2020-04-21 23:07:04 +02:00
Backgrounder
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
backgrounding
backport
backstory
Batang
baz
Bazz
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
BBBBBCCC
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
BBBBCCCCC
BBDM
bbwe
bc
bcount
bcrypt
bcx
bcz
BEFOREPARENT
beginthread
bgcolor
bgfx
bgidx
Bgk
BGR
BGRA
BHID
biblioscape
bigobj
binplace
binplaced
bitcoin
bitcrazed
bitflag
bitmask
BITOPERATION
bitsavers
bitset
BKCOLOR
BKGND
Bksp
blog
Blt
BLUESCROLL
bmp
BOLDFONT
BOOLIFY
bools
Add a subset of boost (#8492) In my #8489 we want to use boost's small_vector type, but that PR is kinda messy by adding boost and also making a meaningful change. So here I'm splitting out the boost addition to its own PR so that one can be more focused on the allocation improvement and consumption of boost.
2020-12-05 02:25:55 +01:00
boostorg
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Borland
BOTTOMLEFT
BOTTOMRIGHT
boutput
BPBF
bpp
BPPF
branchconfig
BRK
Browsable
bsearch
BSODs
bstr
BTNFACE
buf
bufferout
buffersize
buflen
bugfix
buildtransitive
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
BUILDURI
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
burriter
BValue
byref
bytearray
bytebuffer
Cac
callee
cang
capslock
CARETBLINKINGENABLED
CARRIAGERETURN
cascadia
Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)
2020-07-01 20:00:24 +02:00
cassert
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
catid
cazamor
CBash
cbegin
cbiex
CBN
CBoolean
cbt
cbuffer
CCCBB
ccf
cch
CCHAR
cci
CCmd
ccolor
CCom
CComp
CConsole
CConversion
CCRT
cctype
CDATA
cdd
cdecl
CDeclaration
CEdit
CELLSIZE
cend
cerr
cfae
Cfg
cfie
cfiex
cfte
CFuzz
cgscrn
chafa
changelist
charinfo
charlespetzold
charset
CHARSETINFO
chcp
checkbox
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
checkboxes
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
chh
Childitem
chk
chrono
CHT
ci
Cic
cjk
ckuehl
cla
Clcompile
CLE
cleartype
CLICKACTIVE
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
clickdown
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
climits
clipbrd
CLIPCHILDREN
CLIPSIBLINGS
cliutils
Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)
2020-07-01 20:00:24 +02:00
clocale
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
closetest
cloudconsole
cls
CLSCTX
clsid
CLUSTERMAP
Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)
2020-07-01 20:00:24 +02:00
cmath
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
cmatrix
cmder
CMDEXT
Cmdlet
cmdline
CMOUSEBUTTONS
cmp
cmt
cmyk
CNL
cnt
CNTRL
codebase
Codeflow
codepage
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
codepath
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
codepoint
specs: draft spec for adding profiles to the Windows jumplist (#5350) _This is literally just #1357, but moved to the `drafts/` folder_. Since @dsafa doesn't have the time to finish this on their own, we'll take it from here for 2.0 ☺️ ## Summary of the Pull Request Adds a spec describing jumplist integration and adding profiles to the jumplist. Includes details about previous investigations into adding the jumplist. ## PR Checklist * [x] Specs #576 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [n/a] Tests added/passed * [x] 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: #576 ## Detailed Description of the Pull Request / Additional comments Details in the spec. ## Validation Steps Performed N/A Co-authored-by: Brandon Chong <brndnchong@gmail.com>
2020-04-14 22:17:15 +02:00
codeproject
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
COINIT
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
COLLECTIONURI
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
colorizing
colororacle
colorref
colorscheme
colorspaces
colorspec
colortable
colortbl
colortool
COLR
combaseapi
combobox
comctl
COMDAT
commandline
commctrl
commdlg
COMMITID
compat
componentization
conapi
conareainfo
conattrs
conbufferout
concat
concfg
ci: fix spelling issues from inbox merge
2021-03-10 02:46:43 +01:00
conclnt
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
conddkrefs
condrv
conechokey
conemu
config
configurability
conhost
conhostv
conime
conimeinfo
conint
conintegrity
conintegrityuwp
coninteractivitybase
coninteractivityonecore
coninteractivitywin
conio
coniosrv
CONKBD
conlibk
conmsgl
CONNECTINFO
CONOUT
conpixels
conprops
conpropsp
conpty
conptylib
conserv
consoleapi
CONSOLECONTROL
CONSOLEENDTASK
tools: add Get-OSSConhostLog (#7250) This script takes a range of commits and generates a commit log with the git2git-excluded file changes filtered out. It also replaces GitHub issue numbers with GH-XXX so as to not confuse Git2Git or Azure DevOps. Community contributions are tagged with CC- so they can be detected later. The output looks like this: ``` Carlos Zamora (2) * Pass mouse button state into HandleMouse instead of asking win32 (GH-6765) Dustin L. Howett (6) * Disable MinimalCoreWin when OpenConsoleUniversalApp is false (GH-7203) James Holderness (1) * Add support for the "doubly underlined" graphic rendition attribute (CC-7223) ``` Yes, the numbers are wrong. No, it doesn't really matter.
2020-08-11 22:08:03 +02:00
consolegit
Fix the spellbot (#8259)
2020-11-13 18:45:08 +01:00
consolehost
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
CONSOLEIME
consoleinternal
Consoleroot
Consolescreen
CONSOLESETFOREGROUND
consoletaeftemplates
CONSOLEV
Consolewait
CONSOLEWINDOWOWNER
consrv
constexpr
constexprable
constness
contentfiles
conterm
CONTEXTMENU
contsf
contypes
convarea
conwinuserrefs
coord
coordnew
COPYCOLOR
CORESYSTEM
cotaskmem
countof
cout
CPG
cpinfo
CPINFOEX
cplinfo
cplusplus
cpp
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
CPPCORECHECK
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
cppcorecheckrules
cpprest
cpprestsdk
cppwinrt
CProc
cpx
crbegin
CREATESCREENBUFFER
CREATESTRUCT
CREATESTRUCTW
creativecommons
cred
cref
crend
CRLFs
crloew
crt
CRTLIBS
csbi
csbiex
csharp
CSHORT
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
CSIDL
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
csproj
Csr
csrmsg
CSRSS
csrutil
Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)
2020-07-01 20:00:24 +02:00
cstdarg
cstddef
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
cstdio
Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)
2020-07-01 20:00:24 +02:00
cstdlib
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
cstr
cstring
cstyle
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
csv
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
CSwitch
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
CTerminal
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
CText
Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)
2020-07-01 20:00:24 +02:00
ctime
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ctl
ctlseqs
Ctlv
ctor
CTRLEVENT
CTRLKEYSHORTCUTS
Ctx
Ctxt
ctype
CUF
cupxy
curated
CURRENTFONT
currentmode
CURRENTPAGE
CURSORCOLOR
CURSORSIZE
CURSORTYPE
CUU
cw
Cwa
cwch
cwchar
cwctype
cwd
cx
add til::math, use it for float conversions to point, size (#5150) This pull request introduces the `til::math` namespace, which provides some casting functions to be used in support of `til::point` and `til::size`. When point/size want to ingest a floating-point structure, they _must_ be instructed on how to convert those floating-point values into integers. This enables: ``` Windows::Foundation::Point wfPoint = /* ... */; til::point tp{ til::math::rounding, wfPoint }; ``` Future thoughts: should the TilMath types be stackable? Right now, you cannot get "checked + rounding" behavior (where it throws if it doesn't fit) so everything is saturating. ## PR Checklist * [x] Closes a request by Michael * [x] I've discussed this with core contributors already
2020-03-27 23:48:49 +01:00
cxcy
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
CXFRAME
CXFULLSCREEN
CXHSCROLL
CXMIN
CXPADDEDBORDER
CXSIZE
CXSMICON
CXVIRTUALSCREEN
CXVSCROLL
cxx
CYFRAME
CYFULLSCREEN
cygwin
CYHSCROLL
CYMIN
CYPADDEDBORDER
CYSIZE
CYSIZEFRAME
CYSMICON
CYVIRTUALSCREEN
CYVSCROLL
dahall
dai
DATABLOCK
DATAVIEW
DATAW
DBatch
dbcs
DBCSCHAR
DBCSFONT
dbg
DBGALL
DBGCHARS
DBGFONTS
DBGOUTPUT
dbh
dblclk
DBlob
dbproj
DBUILD
DColor
DCOLORVALUE
dcommon
DCompile
dcompiler
Spec for Windows Terminal Process Model 2.0 (#7240) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
2021-02-05 13:19:32 +01:00
DComposition
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
dde
DDESHARE
DDevice
DEADCHAR
dealloc
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
Debian
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
debolden
debounce
DECALN
DECANM
DECAUPSS
DECAWM
DECCKM
DECCOLM
Add support for double-width/double-height lines in conhost (#8664) This PR adds support for the VT line rendition attributes, which allow for double-width and double-height line renditions. These renditions are enabled with the `DECDWL` (double-width line) and `DECDHL` (double-height line) escape sequences. Both reset to the default rendition with the `DECSWL` (single-width line) escape sequence. For now this functionality is only supported by the GDI renderer in conhost. There are a lot of changes, so this is just a general overview of the main areas affected. Previously it was safe to assume that the screen had a fixed width, at least for a given point in time. But now we need to deal with the possibility of different lines have different widths, so all the functions that are constrained by the right border (text wrapping, cursor movement operations, and sequences like `EL` and `ICH`) now need to lookup the width of the active line in order to behave correctly. Similarly it used to be safe to assume that buffer and screen coordinates were the same thing, but that is no longer true. Lots of places now need to translate back and forth between coordinate systems dependent on the line rendition. This includes clipboard handling, the conhost color selection and search, accessibility location tracking and screen reading, IME editor positioning, "snapping" the viewport, and of course all the rendering calculations. For the rendering itself, I've had to introduce a new `PrepareLineTransform` method that the render engines can use to setup the necessary transform matrix for a given line rendition. This is also now used to handle the horizontal viewport offset, since that could no longer be achieved just by changing the target coordinates (on a double width line, the viewport offset may be halfway through a character). I've also had to change the renderer's existing `InvalidateCursor` method to take a `SMALL_RECT` rather than a `COORD`, to allow for the cursor being a variable width. Technically this was already a problem, because the cursor could occupy two screen cells when over a double-width character, but now it can be anything between one and four screen cells (e.g. a double-width character on the double-width line). In terms of architectural changes, there is now a new `lineRendition` field in the `ROW` class that keeps track of the line rendition for each row, and several new methods in the `ROW` and `TextBuffer` classes for manipulating that state. This includes a few helper methods for handling the various issues discussed above, e.g. position clamping and translating between coordinate systems. ## Validation Steps Performed I've manually confirmed all the double-width and double-height tests in _Vttest_ are now working as expected, and the _VT100 Torture Test_ now renders correctly (at least the line rendition aspects). I've also got my own test scripts that check many of the line rendition boundary cases and have confirmed that those are now passing. I've manually tested as many areas of the conhost UI that I could think of, that might be affected by line rendition, including things like searching, selection, copying, and color highlighting. For accessibility, I've confirmed that the _Magnifier_ and _Narrator_ correctly handle double-width lines. And I've also tested the Japanese IME, which while not perfect, is at least useable. Closes #7865
2021-02-18 06:44:50 +01:00
DECDHL
DECDWL
Spec for Improved keyboard handling in Conpty (#5887) ## Summary of the Pull Request We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. ## PR Checklist * [x] Specs #4999 * [x] I work here * [x] is a spec ## Detailed Description of the Pull Request / Additional comments _read the spec_
2020-06-04 14:42:33 +02:00
DECEKBD
Add DECID to spellbot
2021-01-25 20:38:33 +01:00
DECID
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DECKPAM
DECKPM
DECKPNM
DECLRMM
decls
declspec
decltype
declval
DECNKM
DECNRCM
DECOM
deconstructed
DECPCTERM
DECRC
Add support for the DECREQTPARM report (#7939) This PR adds support for the `DECREQTPARM` (Request Terminal Parameters) escape sequence, which was originally used on the VT100 terminal to report the serial communication parameters. Modern terminal emulators simply hardcode the reported values for backward compatibility. The `DECREQTPARM` sequence has one parameter, which was originally used to tell the terminal whether it was permitted to send unsolicited reports or not. However, since we have no reason to send an unsolicited report, we don't need to keep track of that state, but the permission parameter does still determine the value of the first parameter in the response. The response parameters are as follows: | Parameter | Value | Meaning | | ---------------- | ------ | ------------------------ | | response type | 2 or 3 | unsolicited or solicited | | parity | 1 | no parity | | data bits | 1 | 8 bits per character | | transmit speed | 128 | 38400 baud | | receive speed | 128 | 38400 baud | | clock multiplier | 1 | | | flags | 0 | | There is some variation in the baud rate reported by modern terminal emulators, and 9600 baud seems to be a little more common than 38400 baud, but I thought the higher speed was probably more appropriate, especially since that's also the value reported by XTerm. ## Validation Steps Performed I've added a couple of adapter and output engine tests to verify that the sequence is dispatched correctly, and the expected responses are generated. I've also manually tested in Vttest and confirmed that we now pass the `DECREQTPARM` test in the _Test of terminal reports_. Closes #7852
2020-10-16 00:50:02 +02:00
DECREQTPARM
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DECRLM
Spec for Improved keyboard handling in Conpty (#5887) ## Summary of the Pull Request We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. ## PR Checklist * [x] Specs #4999 * [x] I work here * [x] is a spec ## Detailed Description of the Pull Request / Additional comments _read the spec_
2020-06-04 14:42:33 +02:00
DECRQM
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DECRST
DECSASD
DECSC
DECSCA
DECSCNM
DECSCPP
DECSCUSR
DECSED
DECSEL
DECSET
Refactor VT control sequence identification (#7304) This PR changes the way VT control sequences are identified and dispatched, to be more efficient and easier to extend. Instead of parsing the intermediate characters into a vector, and then having to identify a sequence using both that vector and the final char, we now use just a single `uint64_t` value as the identifier. The way the identifier is constructed is by taking the private parameter prefix, each of the intermediate characters, and then the final character, and shifting them into a 64-bit integer one byte at a time, in reverse order. For example, the `DECTLTC` control has a private parameter prefix of `?`, one intermediate of `'`, and a final character of `s`. The ASCII values of those characters are `0x3F`, `0x27`, and `0x73` respectively, and reversing them gets you 0x73273F, so that would then be the identifier for the control. The reason for storing them in reverse order, is because sometimes we need to look at the first intermediate to determine the operation, and treat the rest of the sequence as a kind of sub-identifier (the character set designation sequences are one example of this). When in reverse order, this can easily be achieved by masking off the low byte to get the first intermediate, and then shifting the value right by 8 bits to get a new identifier with the rest of the sequence. With 64 bits we have enough space for a private prefix, six intermediates, and the final char, which is way more than we should ever need (the _DEC STD 070_ specification recommends supporting at least three intermediates, but in practice we're unlikely to see more than two). With this new way of identifying controls, it should now be possible for every action code to be unique (for the most part). So I've also used this PR to clean up the action codes a bit, splitting the codes for the escape sequences from the control sequences, and sorting them into alphabetical order (which also does a reasonable job of clustering associated controls). ## Validation Steps Performed I think the existing unit tests should be good enough to confirm that all sequences are still being dispatched correctly. However, I've also manually tested a number of sequences to make sure they were still working as expected, in particular those that used intermediates, since they were the most affected by the dispatch code refactoring. Since these changes also affected the input state machine, I've done some manual testing of the conpty keyboard handling (both with and without the new Win32 input mode enabled) to make sure the keyboard VT sequences were processed correctly. I've also manually tested the various VT mouse modes in Vttest to confirm that they were still working correctly too. Closes #7276
2020-08-18 20:57:52 +02:00
DECSLPP
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DECSLRM
Spec for Improved keyboard handling in Conpty (#5887) ## Summary of the Pull Request We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. ## PR Checklist * [x] Specs #4999 * [x] I work here * [x] is a spec ## Detailed Description of the Pull Request / Additional comments _read the spec_
2020-06-04 14:42:33 +02:00
DECSMKR
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DECSR
decstandar
DECSTBM
DECSTR
Add support for double-width/double-height lines in conhost (#8664) This PR adds support for the VT line rendition attributes, which allow for double-width and double-height line renditions. These renditions are enabled with the `DECDWL` (double-width line) and `DECDHL` (double-height line) escape sequences. Both reset to the default rendition with the `DECSWL` (single-width line) escape sequence. For now this functionality is only supported by the GDI renderer in conhost. There are a lot of changes, so this is just a general overview of the main areas affected. Previously it was safe to assume that the screen had a fixed width, at least for a given point in time. But now we need to deal with the possibility of different lines have different widths, so all the functions that are constrained by the right border (text wrapping, cursor movement operations, and sequences like `EL` and `ICH`) now need to lookup the width of the active line in order to behave correctly. Similarly it used to be safe to assume that buffer and screen coordinates were the same thing, but that is no longer true. Lots of places now need to translate back and forth between coordinate systems dependent on the line rendition. This includes clipboard handling, the conhost color selection and search, accessibility location tracking and screen reading, IME editor positioning, "snapping" the viewport, and of course all the rendering calculations. For the rendering itself, I've had to introduce a new `PrepareLineTransform` method that the render engines can use to setup the necessary transform matrix for a given line rendition. This is also now used to handle the horizontal viewport offset, since that could no longer be achieved just by changing the target coordinates (on a double width line, the viewport offset may be halfway through a character). I've also had to change the renderer's existing `InvalidateCursor` method to take a `SMALL_RECT` rather than a `COORD`, to allow for the cursor being a variable width. Technically this was already a problem, because the cursor could occupy two screen cells when over a double-width character, but now it can be anything between one and four screen cells (e.g. a double-width character on the double-width line). In terms of architectural changes, there is now a new `lineRendition` field in the `ROW` class that keeps track of the line rendition for each row, and several new methods in the `ROW` and `TextBuffer` classes for manipulating that state. This includes a few helper methods for handling the various issues discussed above, e.g. position clamping and translating between coordinate systems. ## Validation Steps Performed I've manually confirmed all the double-width and double-height tests in _Vttest_ are now working as expected, and the _VT100 Torture Test_ now renders correctly (at least the line rendition aspects). I've also got my own test scripts that check many of the line rendition boundary cases and have confirmed that those are now passing. I've manually tested as many areas of the conhost UI that I could think of, that might be affected by line rendition, including things like searching, selection, copying, and color highlighting. For accessibility, I've confirmed that the _Magnifier_ and _Narrator_ correctly handle double-width lines. And I've also tested the Japanese IME, which while not perfect, is at least useable. Closes #7865
2021-02-18 06:44:50 +01:00
DECSWL
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DECTCEM
Dedupe
deduplicated
ci: fix spelling issues from inbox merge
2021-03-10 02:46:43 +01:00
DEFAPP
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DEFAULTBACKGROUND
DEFAULTFOREGROUND
defaultsettings
DEFAULTTONEAREST
DEFAULTTONULL
DEFAULTTOPRIMARY
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
DEFCON
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
defectdefs
DEFERERASE
deff
DEFFACE
defing
DEFPUSHBUTTON
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
defterm
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DELAYLOAD
deletable
DELETEONRELEASE
delims
Delt
demoable
depersist
deprioritized
Bundle the entire CRT with our branded Release packages (#5661) 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!
2020-04-30 09:08:43 +02:00
deps
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
deque
deref
deserialization
deserialize
deserialized
deserializer
deserializing
desktopwindowxamlsource
dest
DESTINATIONNAME
devblogs
developercommunity
devicecode
devicefamily
devops
Dext
df
DFactory
Fully regenerate CodepointWidthDetector from Unicode 13.0 (#8035) This commit also adds an override UCD and migrates all of the overrides from GetQuickCharWidth into it. GetQuickCharWidth ----------------- The removal of overrides from GQCW reduces the number of comparisons required for looking up a single character's width from 41 (32 individual ranged comparisons from GQCW + 8+1 from the binary search in CPWD) to 11 (2 from GQCW, 8+1 from CPWD). GQCW also incorrectly marked 67 reserved codepoints as `Wide` when they should have been `Narrow`. The codepoints whose definitions have changed from `Wide` to `Narrow` are: ``` 2E9A 2EF4 2EF5 2EF6 2EF7 2EF8 2EF9 2EFA 2EFB 2EFC 2EFD 2EFE 2EFF 2FD6 2FD7 2FD8 2FD9 2FDA 2FDB 2FDC 2FDD 2FDE 2FDF 2FE0 2FE1 2FE2 2FE3 2FE4 2FE5 2FE6 2FE7 2FE8 2FE9 2FEA 2FEB 2FEC 2FED 2FEE 2FEF 2FFC 2FFD 2FFE 2FFF 31E4 31E5 31E6 31E7 31E8 31E9 31EA 31EB 31EC 31ED 31EE 31EF 321F A48D A48E A48F FE1A FE1B FE1C FE1D FE1E FE1F FE53 FE67 ``` All of them are reserved, but those reserved regions are marked as narrow in the UCD. This change also offers us the chance to document exactly why we're overriding a specific character range. Comments from the override document will be copied to the generated CPWD table. New in Unicode 13.0 ------------------ Some widths have changed due to previously-reserved characters becoming _used_ such as U+32FF SQUARE ERA NAME REIWA, the Tangut components 756-768, the entire Khitan Small Script character set, and the Tangut Ideographs. A number of the changes in this diff are due to better/worse comment tracking and the removal of the Emoji/EPres comments. The script once mistakenly applied comments to packed regions (and it has been updated to not do so.) Validation ---------- I build a test application that compared codepoints 0-FFFF for GQCW against their new registered widths.
2020-10-27 18:36:28 +01:00
DFF
Add DFMT to the spelling expect list
2020-07-14 01:11:54 +02:00
DFMT
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
dh
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
dhandler
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
dialogbox
diffing
DINLINE
directio
ci: spelling: update to 0.0.15a; update whitelist (#5413) * 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 https://github.com/microsoft/terminal/commit/5740e197c20bea97b0afe4b396d0541691d02b2c 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.
2020-04-21 23:07:04 +02:00
DIRECTX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Dirs
DISABLENOSCROLL
DISPLAYATTRIBUTE
DISPLAYATTRIBUTEPROPERTY
DISPLAYCHANGE
distro
dlg
DLGC
dll
dllexport
DLLGETVERSIONPROC
dllimport
dllinit
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
dllmain
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DLLVERSIONINFO
DLOAD
DLOOK
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
dmp
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DOCTYPE
docx
DONTCARE
doskey
dotnet
doubleclick
downlevel
dpg
dpi
DPIAPI
DPICHANGE
DPICHANGED
dpix
dpiy
DRAWFRAME
DRAWITEM
DRAWITEMSTRUCT
Fix the spellbot (#8259)
2020-11-13 18:45:08 +01:00
drcs
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
dropdown
DROPDOWNLIST
DROPFILES
drv
dsm
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
dst
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
DSwap
DTest
dtor
DTTERM
DUMMYUNIONNAME
DUNICODE
DUNIT
dup'ed
dvi
dw
DWLP
dwm
dwmapi
dword
dwrite
dwriteglyphrundescriptionclustermap
dxgi
dxgidwm
dxinterop
dxttbmp
eachother
eaf
EASTEUROPE
eb
ECH
echokey
ecount
ECpp
Spec for Windows Terminal Process Model 2.0 (#7240) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
2021-02-05 13:19:32 +01:00
Edgium
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
EDITKEYS
EDITTEXT
EDITUPDATE
edputil
edu
Efast
EHsc
EJO
EK
ELEMENTNOTAVAILABLE
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
elems
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
elif
elseif
emacs
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
EMPTYBOX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
enabledelayedexpansion
endian
endif
endl
endlocal
endptr
endregion
ENQ
enqueuing
entrypoint
ENU
enum
ENUMLOGFONT
ENUMLOGFONTEX
enumranges
envvar
eol
Partially regenerate codepoint widths from Emoji 13.0 (#5934) 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.
2020-05-17 22:32:43 +02:00
EPres
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ERASEBKGND
errno
errorlevel
ETB
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
etcoreapp
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ETW
ETX
EUDC
ev
EVENTID
eventing
everytime
evflags
evt
ewdelete
exe
execd
executables
executionengine
exemain
EXETYPE
exeuwp
exewin
exitwin
expectedinput
expr
EXPUNGECOMMANDHISTORY
EXSTYLE
EXTENDEDEDITKEY
EXTKEY
EXTTEXTOUT
facename
FACENODE
FACESIZE
failfast
FAILIFTHERE
fallthrough
FARPROC
Force DebugFull PDBs on all build types (#9441) I've also taken the opportunity to kill the xxxFullPDB trick. The intermediate PDB is allowed to remain "vc141.pdb" or whatever it wants to be. PDBs are now simply named after their projects, as was always tradition.
2021-03-11 00:49:03 +01:00
fastlink
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
fcb
fcharset
fclose
fcntl
fdc
ci: spelling: update to 0.0.16a; update advice (#5922) <!-- 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 Updates the check spelling action to [0.0.16-a](https://github.com/check-spelling/check-spelling/releases/tag/0.0.16-alpha) * update advice -- [sample](https://github.com/jsoref/terminal/commit/57fc13f6c6fa0a79a06acb94de5005904a2e1222#commitcomment-39489723) -- I really do encourage others to adjust it as desired * rename `expect` (there are consumers who were not a fan of the `whitelist` nomenclature) * prune stale items * some `patterns` improvements to reduce the number of items in `expect` <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> :warning: Anyone with an inflight addition of a new file to the `whitelist` directory will be moderately unhappy as the action would only use items from there if it didn't find `expect` (and this PR includes the rename). ## 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 Runs should be ~30s faster. I was hoping to be able to offer the ability to talk to the bot, but sadly that feature is still not quite ready -- and I suspect that I may want to let projects opt in/out of that feature. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed * I added a commit with misspellings: https://github.com/jsoref/terminal/commit/57fc13f6c6fa0a79a06acb94de5005904a2e1222 ❌ and ran the command it suggested (in bash). * The commit [itself passes its own testing](https://github.com/jsoref/terminal/commit/78df00dcf6cc7b81ffe2f604881e20552d3c94be) ✔️ The commands were never `cmd`/`psh` friendly. This iteration is designed to make it easier for a bot to parse and eventually do the work in response to a GitHub request, sadly that feature is behind schedule.
2020-05-28 15:01:52 +02:00
FDD
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
fde
fdopen
fdw
fea
fesb
FFDE
FFrom
FGCOLOR
fgetc
fgetwc
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
FGHIJ
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
fgidx
FILEDESCRIPTION
fileno
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
filepath
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
FILESUBTYPE
FILESYSPATH
filesystem
FILETIME
FILETYPE
FILEW
FILLATTR
FILLCONSOLEOUTPUT
FILTERONPASTE
finalizer
FINDCASE
FINDDLG
FINDDOWN
FINDSTR
FINDSTRINGEXACT
FINDUP
FIter
FIXEDCONVERTED
Flg
flyout
fmodern
fmtarg
fmtid
Add spelling issues from {fmt} to the allowlist/dictionary
2020-04-14 22:05:38 +02:00
fmtlib
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
FOLDERID
FONTCHANGE
fontdlg
FONTENUMDATA
FONTENUMPROC
FONTFACE
FONTFAMILY
FONTHEIGHT
fontlist
FONTOK
FONTSIZE
FONTSTRING
fonttbl
FONTTYPE
FONTWEIGHT
FONTWIDTH
FONTWINDOW
forceinline
FORCEOFFFEEDBACK
FORCEONFEEDBACK
FORCEV
foreach
fprintf
framebuffer
FRAMECHANGED
fre
freopen
frontend
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
fsanitize
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Fscreen
FSCTL
FSINFOCLASS
fsproj
fstream
fte
Ftm
fullscreen
fullwidth
func
FUNCTIONCALL
fuzzer
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
fuzzmain
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
fuzzmap
fuzzwrapper
fwdecl
fwe
fwlink
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
GAUSSIAN
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
gb
gci
gcx
gcy
gdi
gdip
gdirenderer
geopol
GETALIAS
GETALIASES
GETALIASESLENGTH
GETALIASEXES
GETALIASEXESLENGTH
GETAUTOHIDEBAREX
GETCARETWIDTH
getch
getchar
Add support for the "blink" graphic rendition attribute (#7490) This PR adds support for the _blink_ graphic rendition attribute. When a character is output with this attribute set, it "blinks" at a regular interval, by cycling its color between the normal rendition and a dimmer shade of that color. The majority of the blinking mechanism is encapsulated in a new `BlinkingState` class, which is shared between the Terminal and Conhost implementations. This class keeps track of the position in the blinking cycle, which determines whether characters are rendered as normal or faint. In Windows Terminal, the state is stored in the `Terminal` class, and in Conhost it's stored in the `CONSOLE_INFORMATION` class. In both cases, the `IsBlinkingFaint` method is used to determine the current blinking rendition, and that is passed on as a parameter to the `TextAttribute::CalculateRgbColors` method when these classes are looking up attribute colors. Prior to calculating the colors, the current attribute is also passed to the `RecordBlinkingUsage` method, which keeps track of whether there are actually any blink attributes in use. This is used to determine whether the screen needs to be refreshed when the blinking cycle toggles between the normal and faint renditions. The refresh itself is handled by the `ToggleBlinkingRendition` method, which is triggered by a timer. In Conhost this is just piggybacking on the existing cursor blink timer, but in Windows Terminal it needs to have its own separate timer, since the cursor timer is reset whenever a key is pressed, which is not something we want for attribute blinking. Although the `ToggleBlinkingRendition` is called at the same rate as the cursor blinking, we actually only want the cells to blink at half that frequency. We thus have a counter that cycles through four phases, and blinking is rendered as faint for two of those four. Then every two cycles - when the state changes - a redraw is triggered, but only if there are actually blinking attributes in use (as previously recorded). As mentioned earlier, the blinking frequency is based on the cursor blink rate, so that means it'll automatically be disabled if a user has set their cursor blink rate to none. It can also be disabled by turning off the _Show animations in Windows_ option. In Conhost these settings take effect immediately, but in Windows Terminal they only apply when a new tab is opened. This PR also adds partial support for the `SGR 6` _rapid blink_ attribute. This is not used by DEC terminals, but was defined in the ECMA/ANSI standards. It's not widely supported, but many terminals just it implement it as an alias for the regular `SGR 5` blink attribute, so that's what I've done here too. ## Validation Steps Performed I've checked the _Graphic rendition test pattern_ in Vttest, and compared our representation of the blink attribute to that of an actual DEC VT220 terminal as seen on [YouTube]. With the right color scheme it's a reasonably close match. [YouTube]: https://www.youtube.com/watch?v=03Pz5AmxbE4&t=1m55s Closes #7388
2020-09-22 01:21:33 +02:00
GETCLIENTAREAANIMATION
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
GETCOMMANDHISTORY
GETCOMMANDHISTORYLENGTH
GETCONSOLEINPUT
GETCONSOLEPROCESSLIST
GETCONSOLEWINDOW
GETCOUNT
GETCP
GETCURSEL
GETCURSORINFO
GETDISPLAYMODE
GETDISPLAYSIZE
GETDLGCODE
GETDPISCALEDSIZE
GETFONTINFO
GETFONTSIZE
GETHARDWARESTATE
GETHUNGAPPTIMEOUT
GETICON
GETITEMDATA
GETKEYBOARDLAYOUTNAME
GETKEYSTATE
GETLARGESTWINDOWSIZE
GETLBTEXT
getline
GETMINMAXINFO
GETMOUSEINFO
Teach terminal to hide mouse while typing (#8629) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/5699 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments * Use SPI_GETMOUSEVANISH setting * Hide upon CharacterReceived * Unhide upon PointerMoved, PointerMoved, MouseWheel, LoseFocus
2021-01-21 02:17:59 +01:00
GETMOUSEVANISH
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
GETNUMBEROFFONTS
GETNUMBEROFINPUTEVENTS
GETOBJECT
GETPOS
GETSELECTIONINFO
getset
GETSTATE
GETTEXT
GETTEXTLEN
GETTITLE
GETWAITTOKILLSERVICETIMEOUT
GETWAITTOKILLTIMEOUT
GETWHEELSCROLLCHARACTERS
GETWHEELSCROLLCHARS
GETWHEELSCROLLLINES
getwriter
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
GFEh
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Gfun
gfx
gh
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
GHIJK
GHIJKL
GHIJKLM
tools: add Get-OSSConhostLog (#7250) This script takes a range of commits and generates a commit log with the git2git-excluded file changes filtered out. It also replaces GitHub issue numbers with GH-XXX so as to not confuse Git2Git or Azure DevOps. Community contributions are tagged with CC- so they can be detected later. The output looks like this: ``` Carlos Zamora (2) * Pass mouse button state into HandleMouse instead of asking win32 (GH-6765) Dustin L. Howett (6) * Disable MinimalCoreWin when OpenConsoleUniversalApp is false (GH-7203) James Holderness (1) * Add support for the "doubly underlined" graphic rendition attribute (CC-7223) ``` Yes, the numbers are wrong. No, it doesn't really matter.
2020-08-11 22:08:03 +02:00
gitfilters
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
github
doc: Fix the typos I introduced in #2193 (#5343)
2020-04-13 22:50:02 +02:00
gitlab
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
gle
globals
gmail
GMEM
GNUC
Goldmine
gonce
Google
goutput
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
GPUs
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Gravell's
grayscale
GREENSCROLL
Grehan
grep
Greyscale
gridline
groupbox
Improve support for VT character sets (#4496) This PR improves our VT character set support, enabling the [`SCS`] escape sequences to designate into all four G-sets with both 94- and 96-character sets, and supports invoking those G-sets into both the GL and GR areas of the code table, with [locking shifts] and [single shifts]. It also adds [`DOCS`] sequences to switch between UTF-8 and the ISO-2022 coding system (which is what the VT character sets require), and adds support for a lot more characters sets, up to around the level of a VT510. [`SCS`]: https://vt100.net/docs/vt510-rm/SCS.html [locking shifts]: https://vt100.net/docs/vt510-rm/LS.html [single shifts]: https://vt100.net/docs/vt510-rm/SS.html [`DOCS`]: https://en.wikipedia.org/wiki/ISO/IEC_2022#Interaction_with_other_coding_systems ## Detailed Description of the Pull Request / Additional comments To make it easier for us to declare a bunch of character sets, I've made a little `constexpr` class that can build up a mapping table from a base character set (ASCII or Latin1), along with a collection of mappings for the characters the deviate from the base set. Many of the character sets are simple variations of ASCII, so they're easy to define this way. This class then casts directly to a `wstring_view` which is how the translation tables are represented in most of the code. We have an array of four of these tables representing the four G-sets, two instances for the active left and right tables, and one instance for the single shift table. Initially we had just one `DesignateCharset` method, which could select the active character set. We now have two designate methods (for 94- and 96- character sets), and each takes a G-set number specifying the target of the designation, and a pair of characters identifying the character set that will be designated (at the higher VT levels, character sets are often identified by more than one character). There are then two new `LockingShift` methods to invoke these G-sets into either the GL or GR area of the code table, and a `SingleShift` method which invokes a G-set temporarily (for just the next character that is output). I should mention here that I had to make some changes to the state machine to make these single shift sequences work. The problem is that the input state machine treats `SS3` as the start of a control sequence, while the output state machine needs it to be dispatched immediately (it's literally the _Single Shift 3_ escape sequence). To make that work, I've added a `ParseControlSequenceAfterSs3` callback in the `IStateMachineEngine` interface to decide which behavior is appropriate. When it comes to mapping a character, it's simply an array reference into the appropriate `wstring_view` table. If the single shift table is set, that takes preference. Otherwise the GL table is used for characters in the range 0x20 to 0x7F, and the GR table for characters 0xA0 to 0xFF (technically some character sets will only map up to 0x7E and 0xFE, but that's easily controlled by the length of the `wstring_view`). The `DEL` character is a bit of a special case. By default it's meant to be ignored like the `NUL` character (it's essentially a time-fill character). However, it's possible that it could be remapped to a printable character in a 96-character set, so we need to check for that after the translation. This is handled in the `AdaptDispatch::Print` method, so it doesn't interfere with the primary `PrintString` code path. The biggest problem with this whole process, though, is that the GR mappings only really make sense if you have access to the raw output, but by the time the output gets to us, it would already have been translated to Unicode by the active code page. And in the case of UTF-8, the characters we eventually receive may originally have been composed from two or more code points. The way I've dealt with this was to disable the GR translations by default, and then added support for a pair of ISO-2022 `DOCS` sequences, which can switch the code page between UTF-8 and ISO-8859-1. When the code page is ISO-8859-1, we're essentially receiving the raw output bytes, so it's safe to enable the GR translations. This is not strictly correct ISO-2022 behavior, and there are edge cases where it's not going to work, but it's the best solution I could come up with. ## Validation Steps Performed As a result of the `SS3` changes in the state machine engine, I've had to move the existing `SS3` tests from the `OutputEngineTest` to the `InputEngineTest`, otherwise they would now fail (technically they should never have been output tests). I've added no additional unit tests, but I have done a lot of manual testing, and made sure we passed all the character set tests in Vttest (at least for the character sets we currently support). Note that this required a slightly hacked version of the app, since by default it doesn't expose a lot of the test to low-level terminals, and we currently identify as a VT100. Closes #3377 Closes #3487
2020-06-04 21:40:15 +02:00
gset
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
gsl
GTP
guc
gui
guidatom
GValue
GWL
GWLP
gwsz
HABCDEF
ci: spelling: update to 0.0.15a; update whitelist (#5413) * 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 https://github.com/microsoft/terminal/commit/5740e197c20bea97b0afe4b396d0541691d02b2c 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.
2020-04-21 23:07:04 +02:00
Hackathon
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
halfwidth
HALTCOND
HANGEUL
hardcoded
hardcodes
hashalg
HASSTRINGS
hbitmap
hbm
HBMMENU
hbmp
hbr
hbrush
hc
HCmd
hdc
hdr
HDROP
hdrstop
HEIGHTSCROLL
hfile
hfont
hglobal
hh
Add support for more OSC color formats (#7578) * Correct the behaviour of parsing `rgb:R/G/B`. It should be interpreted as `RR/GG/BB` instead of `0R/0G/0B` * Add support for `rgb:RRR/GGG/BBB` and `rgb:RRRR/GGGG/BBBB`. The behaviour of 12 bit variants is to repeat the first digit at the end, e.g. `rgb:123/456/789` becomes `rgb:1231/4564/7897`. * Add support for `#` formats. We are following the rules of [XParseColor] by interpreting `#RGB` as `R000G000B000`. * Add support for XOrg app color names, which are supported by xterm, VTE and many other terminal emulators. * Multi-parameter OSC 4 is now supported. * The chaining of OSC 10-12 is not yet supported. But the parameter validation is relaxed by parsing the parameters as multi-params but only use the first one, which means `\e]10;rgb:R/G/B;` and `\e]10:rgb:R/G/B;invalid` will execute `OSC 10` with the first color correctly. This fixes some of the issues mentioned in #942 but not all of them. [XParseColor]: https://linux.die.net/man/3/xparsecolor Closes #3715
2020-10-15 02:29:10 +02:00
hhh
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
hhook
hhx
HIBYTE
HICON
HIDEWINDOW
HIGHLIGHTTEXT
hinst
HINSTANCE
Hirots
HISTORYBUFS
HISTORYNODUP
HISTORYSIZE
hittest
HIWORD
hk
HKCU
hkey
hkl
HKLM
hlocal
hlsl
HMENU
hmod
hmodule
hmon
HMONITOR
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
horiz
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
HORZ
hostable
hostlib
HPA
HPAINTBUFFER
HPCON
hpj
hpp
HPR
HPROPSHEETPAGE
Hook up the WIL fallback error tracer in Terminal (#7864) This pull request introduces (a very, very stripped-down copy of) the WIL fallback error reporter. It emits error records, usually immediately before the application implodes, into the event stream. This should improve diagnosability of issues that take Terminal down, and allow us to give out a .wprp file to gather traces from users.
2020-10-10 00:20:12 +02:00
HProvider
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
HREDRAW
hresult
HRSRC
hscroll
hsl
hstr
hstring
hsv
HTCAPTION
HTCLIENT
htm
HTMAXBUTTON
HTMINBUTTON
html
HTMLTo
HTTOP
hu
hungapp
HVP
hwheel
hwnd
HWNDPARENT
hxx
IAccessibility
IAction
IApi
IApplication
IBase
icacls
iccex
icch
IChar
ico
IComponent
ICONERROR
Iconified
ICONINFORMATION
IConsole
ICONSTOP
IControl
ICONWARNING
ICore
IData
IDCANCEL
IDD
IDesktop
Convert DeviceComm into an interface and add handle exchange (#8367) This commit replaces DeviceComm with the interface IDeviceComm and the concrete implementation type ConDrvDeviceComm. This work is done in preparation for different device backends. In addition to separating out ConDrv-specific behavior, I've introduced a "handle exchange" interface. HANDLE EXCHANGE --------------- There are points where we give ConDrv opaque handle identifiers to our input buffer, output buffer and process data. The exact content of the opaque identifier is meaningless to ConDrv: the driver's only interaction with these identifiers is to hold onto them and send back whichever are pertinent for each API call. Because of that, we used the raw register-width pointer value of the input buffer, output buffer or process data _as_ the opaque handle value. This works very well for ConDrv <-> conhost using the ConDrvDeviceComm. It works less well for something like the "logging" DeviceComm that will log packets to a file: those packets *cannot* contain pointer values (!) To address this, and to afford flexibility to DeviceComm implementers, I've introduced a two-member complement of handle management functions: * `ULONG_PTR PutHandle(void*)` registers an object with the DeviceComm and returns an opaque identifier. * `void* GetHandle(ULONG_PTR)` takes an opaque identifier and returns the original object. ConDrvDeviceComm implements PutHandle and GetHandle by casting the object pointer to the "opaque handle value", which maintains wire format compatibility[1] with revisions of conhost prior to this change. Simpler DeviceComm implementations that require handle tracking but cannot bear raw pointers can implement these functions by returning an autoincrementing ID (or similar) and registering the raw object pointer in a mapping. I've audited all existing handle exchanges with the driver and updated them to use Put/GetHandle. (I intended to add DestroyHandle, but we are not equipped for handle removal at the moment. ConsoleHandleData/ConsoleProcessHandle are destroyed during wait routine completion, on client disconnect, etc. This does mean that an id<->pointer mapping will grow without bound, but at a cost of ~8 bytes per entry and a short-lived console session I am not too concerned about the cost.) [1] Wire format compatibility is not required, and later we may want to switch ConDrvDeviceComm to `EncodePointer` and `DecodePointer` just to insulate us against a spurious ConDrv packet allowing for an arbitrary 4/8-byte read and subsequent liftoff into space.
2020-12-16 00:07:43 +01:00
IDevice
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
IDictionary
IDISHWND
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
IDispatch
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
IDisposable
idl
idllib
IDOK
IDR
idth
idx
IDXGI
IDynamic
IEnd
IEnum
IEnumerable
ies
ietf
IFACEMETHODIMP
ifdef
ification
ifndef
IFont
ifstream
IGNOREEND
IHigh
Propagate IslandWindow's HWND into any component that needs it (#8391) This fixes the issue with the settings UI where clicking the browse buttons would cause an exception to be thrown when we tried to display a picker without an originating HWND. It turns out that pickers need a hosting/parent window, and Xaml Islands doesn't furnish us with a CoreWindow that's set up for that use case. Alas! Raymond Chen's [blog post on the matter] suggests that we should hand the HWND off through some classic COM interface. To do that properly, Terminal's various components need to implement that interface and propagate the HWND down where it's needed. Thanks to a [Xaml compiler issue], we can't actually do that. To work around that, we've begged and borrowed different methods for pushing HWNDs around: 1. Using IInitializeWithWindow in secret 2. A member that takes a uint64 3. An interface that offers a function that will "wire up" the HWND. I chose (1) because AppHost can implement IInitializeWithWindow, but TerminalPage cannot. We're just pretending that TerminalPage _can_. I chose (2) because none of the Xaml types in TerminalSettingsEditor can implement the interface thanks to the aforementioned compiler issue, but we don't have an escape hatch like AppHost that lives in the same module and can help us do the propagation. I chose (3) because I didn't want to commit the same sin as (2) _seven times_ for every different type of settings page that exists. (3) is backed by "IHostedInWindow", and anybody who knows they have to use IInitializeWithWindow to tie an HWND to an object can call IHostedInWindow.TryPropagateHostingWindow() on that object. House of cards. [Xaml compiler issue]: https://github.com/microsoft/microsoft-ui-xaml/issues/3331 [blog post on the matter]: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413 (cherry picked from commit f9fc9861a111925347f0362ba0fd9a14fb0765c9)
2020-11-30 20:51:42 +01:00
IHosted
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
iid
Propagate IslandWindow's HWND into any component that needs it (#8391) This fixes the issue with the settings UI where clicking the browse buttons would cause an exception to be thrown when we tried to display a picker without an originating HWND. It turns out that pickers need a hosting/parent window, and Xaml Islands doesn't furnish us with a CoreWindow that's set up for that use case. Alas! Raymond Chen's [blog post on the matter] suggests that we should hand the HWND off through some classic COM interface. To do that properly, Terminal's various components need to implement that interface and propagate the HWND down where it's needed. Thanks to a [Xaml compiler issue], we can't actually do that. To work around that, we've begged and borrowed different methods for pushing HWNDs around: 1. Using IInitializeWithWindow in secret 2. A member that takes a uint64 3. An interface that offers a function that will "wire up" the HWND. I chose (1) because AppHost can implement IInitializeWithWindow, but TerminalPage cannot. We're just pretending that TerminalPage _can_. I chose (2) because none of the Xaml types in TerminalSettingsEditor can implement the interface thanks to the aforementioned compiler issue, but we don't have an escape hatch like AppHost that lives in the same module and can help us do the propagation. I chose (3) because I didn't want to commit the same sin as (2) _seven times_ for every different type of settings page that exists. (3) is backed by "IHostedInWindow", and anybody who knows they have to use IInitializeWithWindow to tie an HWND to an object can call IHostedInWindow.TryPropagateHostingWindow() on that object. House of cards. [Xaml compiler issue]: https://github.com/microsoft/microsoft-ui-xaml/issues/3331 [blog post on the matter]: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413 (cherry picked from commit f9fc9861a111925347f0362ba0fd9a14fb0765c9)
2020-11-30 20:51:42 +01:00
IInitialize
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
IInput
IInspectable
IInteract
IInteractivity
IIo
IList
tools: add Get-OSSConhostLog (#7250) This script takes a range of commits and generates a commit log with the git2git-excluded file changes filtered out. It also replaces GitHub issue numbers with GH-XXX so as to not confuse Git2Git or Azure DevOps. Community contributions are tagged with CC- so they can be detected later. The output looks like this: ``` Carlos Zamora (2) * Pass mouse button state into HandleMouse instead of asking win32 (GH-6765) Dustin L. Howett (6) * Disable MinimalCoreWin when OpenConsoleUniversalApp is false (GH-7203) James Holderness (1) * Add support for the "doubly underlined" graphic rendition attribute (CC-7223) ``` Yes, the numbers are wrong. No, it doesn't really matter.
2020-08-11 22:08:03 +02:00
imagemagick
Imatch
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ime
Imm
Manually pass mouse wheel messages to TermControls (#5131) ## Summary of the Pull Request As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads). This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content. Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal. ## References * #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML ## PR Checklist * [x] Closes #979 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point` ## Validation Steps Performed * It works on my HP Spectre 2017 with a synaptics trackpad - I also made sure to test that `tmux` works in panes on this laptop * It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
2020-04-01 18:58:16 +02:00
IMouse
ci: spelling: update to 0.0.14a (#5270)
2020-04-07 23:58:12 +02:00
impl
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
inbox
inclusivity
INCONTEXT
INFOEX
inheritcursor
inheritdoc
inheritfrom
ini
INITCOMMONCONTROLSEX
INITDIALOG
initguid
INITMENU
Add High Contrast image assets (#6915) This commit adds image assets for High Contrast mode Tagging this issue so it contains a nice list of all the recent HC fixes: #5360 I made several changes to DHowett's script and added it to the repo: * Add support for generating high contrast icons * Add the ability to easily edit the "intermediate" (previously "zbase") files for manual hinting * Appease the spellchecker I created new SVGs for HC mode. There's one SVG for both Black and White modes -- I just invert the colors. Then I manually hinted the generated bitmaps for the production icons. I didn't bother hinting the Dev/Pre ones, so the text does get unreadable at small sizes. View the original images in #6915. Co-authored-by: Jeffrey Tippet <jtippet@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Closes #6822
2020-07-14 23:45:30 +02:00
inkscape
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
inl
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
INLINEPREFIX
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
inlines
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
INotify
inout
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
inplace
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
inproc
Inputkeyinfo
INPUTPROCESSORPROFILE
inputrc
Inputreadhandledata
INSERTMODE
intellisense
INTERACTIVITYBASE
INTERCEPTCOPYPASTE
INTERNALNAME
interop
interoperability
inthread
intptr
intsafe
INVALIDARG
INVALIDATERECT
inwap
IObservable
ioctl
iomanip
iostream
iot
ipch
ipconfig
IPersist
ipp
IProperty
IPSINK
ipsp
IRaw
IRead
IReference
IRender
IRenderer
IScheme
ISelection
IShell
isocpp
issuecomment
IState
IStoryboard
isupper
ISwap
iswdigit
iswspace
ISystem
iterm
itermcolors
ITerminal
IText
itf
Ith
itoa
IUI
IUia
IUnknown
ivalid
Add actions missing in schema, descriptions for `toggleRetroEffect` (#6806) ## Summary of the Pull Request In the wake of #6635, a couple things got missed in merges: * `toggleRetroEffect` didn't get into the schema, nor did `renameTab` or `commandPalette`. * `toggleRetroEffect` also didn't get a name Furthermore, I thought it might be a good idea to start sticking commands into `bindings` even without `keys`. So I tried doing that for `opentabColorPicker` and `toggleRetroEffect`, and found immediately that the labels for the key chord still appear even when the text is empty. So I added some XAML magic to hide those when the text is empty. ## References * #6762 * #6691 * #6557 * #6635 ## PR Checklist * [x] Closes #6762 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * See also: https://docs.microsoft.com/en-us/windows/uwp/data-binding/data-binding-quickstart#formatting-or-converting-data-values-for-display - make sure to switch to C++/WinRT at the top! ## Validation Steps Performed Removed all my manual actions, ran the Terminal: ![image](https://user-images.githubusercontent.com/18356694/86652356-f5a79400-bfa9-11ea-9131-5b7d3e835e19.png)
2020-07-07 23:46:16 +02:00
IValue
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
IVector
IWait
iwch
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
IWeb
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
IWin
IWindow
IXaml
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
IXMP
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
jconcpp
JOBOBJECT
JOBOBJECTINFOCLASS
jpe
jpeg
jpg
JPN
json
jsoncpp
jsprovider
jumplist
KAttrs
kawa
kayla
Kazu
kazum
kbd
kcub
kcud
kcuf
kcuu
Spec for Improved keyboard handling in Conpty (#5887) ## Summary of the Pull Request We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. ## PR Checklist * [x] Specs #4999 * [x] I work here * [x] is a spec ## Detailed Description of the Pull Request / Additional comments _read the spec_
2020-06-04 14:42:33 +02:00
Kd
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
kernelbase
kernelbasestaging
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
KEYBDINPUT
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
keybinding
keychord
keydown
keyevent
KEYFIRST
KEYLAST
keymap
Keymapping
keyscan
keystate
keyup
KF
khome
KILLACTIVE
KILLFOCUS
kinda
KJ
KLF
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
KLMNO
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
KLMNOPQRST
KLMNOPQRSTQQQQQ
KU
KVM
KX
langid
LANGUAGELIST
lasterror
lastexitcode
LAYOUTRTL
LBN
LBound
LBUTTON
LBUTTONDBLCLK
LBUTTONDOWN
LBUTTONUP
lcb
LCONTROL
LCTRL
lcx
LEFTALIGN
LEFTSHIFT
len
lhs
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
libpopcnt
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
libsancov
Spec for Improved keyboard handling in Conpty (#5887) ## Summary of the Pull Request We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. ## PR Checklist * [x] Specs #4999 * [x] I work here * [x] is a spec ## Detailed Description of the Pull Request / Additional comments _read the spec_
2020-06-04 14:42:33 +02:00
libtickit
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
LIMITTEXT
LINEDOWN
LINESELECTION
LINEWRAP
LINKERRCAP
LINKERROR
linkid
linkpath
linputfile
Linq
linux
listbox
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
listproperties
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
listptr
listptrsize
lk
lld
llvm
llx
LMENU
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
LMNOP
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
lnk
lnkd
lnkfile
LNM
LOADONCALL
LOBYTE
localappdata
localhost
locsrc
locstudio
Loewen
LOGFONT
LOGFONTW
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
logissue
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
lowercased
loword
lparam
Add a spec for output snapping (#2529) ## Summary of the Pull Request This proposes a change to how Terminal will scroll in response to newly generated output. The Terminal will scroll upon receiving new output if the viewport is at the bottom of the scroll history and no selection is active. This spec also explores the possibility of making this response configurable with a `snapOnOutput` profile setting. It also discusses the possibility of adding a scroll lock keybinding action. ## PR Checklist * [X] Spec for #980
2020-07-07 23:45:16 +02:00
lparen
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
LPBYTE
LPCCH
lpch
LPCHARSETINFO
LPCOLORREF
LPCPLINFO
LPCREATESTRUCT
lpcs
LPCSTR
LPCTSTR
LPCWSTR
lpdata
LPDBLIST
lpdis
LPDRAWITEMSTRUCT
lpdw
LPDWORD
lpelfe
lpfn
LPFNADDPROPSHEETPAGE
LPINT
lpl
LPMEASUREITEMSTRUCT
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
LPMINMAXINFO
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
lpmsg
LPNEWCPLINFO
LPNEWCPLINFOA
LPNEWCPLINFOW
LPNMHDR
lpntme
LPPOINT
LPPROC
LPPROPSHEETPAGE
LPPSHNOTIFY
lprc
LPRECT
lpstr
lpsz
LPTSTR
LPTTFONTLIST
lpv
LPVOID
LPW
LPWCH
LPWINDOWPOS
lpwpos
lpwstr
LRESULT
lru
lsb
lsconfig
lsproj
lss
lstatus
lstrcmp
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
lstrcmpi
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
LTEXT
LTLTLTLTL
ltype
LUID
lval
LVB
LVERTICAL
LWA
LWIN
lwkmvj
mailto
majorly
makeappx
MAKEINTRESOURCE
MAKEINTRESOURCEW
MAKELANGID
MAKELONG
MAKELPARAM
MAKELRESULT
malloc
Spec for Improved keyboard handling in Conpty (#5887) ## Summary of the Pull Request We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. ## PR Checklist * [x] Specs #4999 * [x] I work here * [x] is a spec ## Detailed Description of the Pull Request / Additional comments _read the spec_
2020-06-04 14:42:33 +02:00
manpage
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
MAPBITMAP
MAPVIRTUALKEY
MAPVK
MAXDIMENSTRING
maxing
MAXLENGTH
MAXSHORT
maxversiontested
MAXWORD
maybenull
MBUTTON
MBUTTONDBLCLK
MBUTTONDOWN
MBUTTONUP
Mbxy
mdmerge
MDs
MEASUREITEM
megamix
memallocator
memcmp
memcopy
memcpy
memmove
memset
MENUCHAR
MENUCONTROL
MENUDROPALIGNMENT
MENUITEM
MENUITEMINFO
MENUSELECT
Mersenne
messageext
metadata
metaproj
midl
mii
MIIM
milli
mimetype
mincore
mindbogglingly
mingw
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
minimizeall
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
minkernel
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
MINMAXINFO
Spec for Windows Terminal Process Model 2.0 (#7240) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
2021-02-05 13:19:32 +01:00
mintty
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
minwin
minwindef
Mip
mkdir
MMBB
mmcc
MMCPL
mmsystem
MNC
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
MNOPQ
MNOPQR
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
MODALFRAME
modelproj
MODERNCORE
MONITORINFO
MONITORINFOEXW
MONITORINFOF
monospaced
monostate
MOUSEACTIVATE
MOUSEFIRST
MOUSEHWHEEL
MOUSEMOVE
mousewheel
MOVESTART
msb
msbuild
mscorlib
msctf
msctls
msdata
msdn
msft
MSGCMDLINEF
MSGF
MSGFILTER
MSGFLG
MSGMARKMODE
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
MSGS
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
MSGSCROLLMODE
MSGSELECTMODE
msiexec
MSIL
msix
msrc
msvcrt
MSVS
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
msys
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
msysgit
mui
Mul
multiline
munged
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
munges
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
mutex
spelling I
2020-06-05 20:57:17 +02:00
mutexes
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
muxes
myapplet
mydir
myignite
MYMAX
Mypair
Myval
NAMELENGTH
nameof
namespace
namespaced
namestream
nano
natvis
nbsp
Nc
NCCALCSIZE
NCCREATE
NCLBUTTONDOWN
NCLBUTTONUP
NCMBUTTONDOWN
NCMBUTTONUP
NCPAINT
NCRBUTTONDOWN
NCRBUTTONUP
NCXBUTTONDOWN
NCXBUTTONUP
NDEBUG
ned
NEL
NEQ
netcoreapp
netstandard
NEWCPLINFO
NEWCPLINFOA
NEWCPLINFOW
newcursor
Newdelete
NEWINQUIRE
NEWINQURE
NEWPROCESSWINDOW
NEWTEXTMETRIC
NEWTEXTMETRICEX
Newtonsoft
NEXTLINE
nfe
nlength
Nls
NLSMODE
NOACTIVATE
NOAPPLYNOW
NOCLIP
NOCOLOR
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
NOCOMM
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NOCONTEXTHELP
NOCOPYBITS
nodiscard
NODUP
noexcept
Exclude more rarely-used stuff from Windows headers (#8513) This PR defines a series of `NOSOMETHING` macros in PCHs, in order to prevent `windows.h` from bringing a lot of rarely used things into the project. Theoretically this should make PCH generation and overall complication faster, but I didn't really benchmark the speed. Another benefit would be reducing the symbol noises caused by `windows.h`.
2020-12-11 20:35:23 +01:00
NOHELP
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
noinline
NOINTEGRALHEIGHT
NOINTERFACE
NOLINKINFO
nologo
Exclude more rarely-used stuff from Windows headers (#8513) This PR defines a series of `NOSOMETHING` macros in PCHs, in order to prevent `windows.h` from bringing a lot of rarely used things into the project. Theoretically this should make PCH generation and overall complication faster, but I didn't really benchmark the speed. Another benefit would be reducing the symbol noises caused by `windows.h`.
2020-12-11 20:35:23 +01:00
NOMCX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NOMINMAX
NOMOVE
NONALERT
nonbreaking
nonclient
NONCONST
NONINFRINGEMENT
NONPREROTATED
nonspace
NOOWNERZORDER
NOPAINT
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
NOPQRST
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
noprofile
NOREDRAW
NOREMOVE
NOREPOSITION
noreturn
NORMALDISPLAY
NOSCRATCH
NOSEARCH
noselect
NOSENDCHANGING
NOSIZE
NOSNAPSHOT
NOTHOUSANDS
nothrow
NOTICKS
NOTIMPL
tools: add a powershell script to generate CPWD from the UCD (#5946) This commit introduces Generate-CodepointWidthsFromUCD, a powershell (7+) script that will parse a UCD XML database in the UAX 42 format from https://www.unicode.org/Public/UCD/latest/ucdxml/ and generate CodepointWidthDetector's giant width array. By default, it will emit one UnicodeRange for every range of non-narrow glyphs with a different Width + Emoji + Emoji Presentation class; however, it can be run in "packing" and "full" mode. * Packing mode: ignore the width/emoji/pres class and combine adjacent runs that CPWD will treat the same. * This is for optimizing the number of individual ranges emitted into code. * Full mode: include narrow codepoints (helpful for visualization) It also supports overrides, provided in an XML document of the same format as the UCD itself. Entries in the overrides files are applied after the entire UCD is read and will replace any impacted ranges. The output (when packing) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD -Pack:True -Full:False // on 05/17/2020 02:47:55 (UTC) from Unicode 13.0.0. // 66182 (0x10286) codepoints covered. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa4, 0xa4, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa7, 0xa8, CodepointWidth::Ambiguous }, . . . UnicodeRange{ 0x1f210, 0x1f23b, CodepointWidth::Wide }, UnicodeRange{ 0x1f37e, 0x1f393, CodepointWidth::Wide }, UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ``` The output (when overriding) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD.ps1 -Pack:True -Full:False -NoOverrides:False // on 5/22/2020 11:17:39 PM (UTC) from Unicode 13.0.0. // 321205 (0x4E6B5) codepoints covered. // 240 (0xF0) codepoints overridden. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, ... UnicodeRange{ 0xfe20, 0xfe2f, CodepointWidth::Narrow }, // narrow combining ligatures (split into left/right halves, which take 2 columns together) ... UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ```
2020-06-03 09:16:14 +02:00
notin
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NOTNULL
tools: add Get-OSSConhostLog (#7250) This script takes a range of commits and generates a commit log with the git2git-excluded file changes filtered out. It also replaces GitHub issue numbers with GH-XXX so as to not confuse Git2Git or Azure DevOps. Community contributions are tagged with CC- so they can be detected later. The output looks like this: ``` Carlos Zamora (2) * Pass mouse button state into HandleMouse instead of asking win32 (GH-6765) Dustin L. Howett (6) * Disable MinimalCoreWin when OpenConsoleUniversalApp is false (GH-7203) James Holderness (1) * Add support for the "doubly underlined" graphic rendition attribute (CC-7223) ``` Yes, the numbers are wrong. No, it doesn't really matter.
2020-08-11 22:08:03 +02:00
NOTOPMOST
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NOTRACK
NOTSUPPORTED
nouicompat
tools: add a powershell script to generate CPWD from the UCD (#5946) This commit introduces Generate-CodepointWidthsFromUCD, a powershell (7+) script that will parse a UCD XML database in the UAX 42 format from https://www.unicode.org/Public/UCD/latest/ucdxml/ and generate CodepointWidthDetector's giant width array. By default, it will emit one UnicodeRange for every range of non-narrow glyphs with a different Width + Emoji + Emoji Presentation class; however, it can be run in "packing" and "full" mode. * Packing mode: ignore the width/emoji/pres class and combine adjacent runs that CPWD will treat the same. * This is for optimizing the number of individual ranges emitted into code. * Full mode: include narrow codepoints (helpful for visualization) It also supports overrides, provided in an XML document of the same format as the UCD itself. Entries in the overrides files are applied after the entire UCD is read and will replace any impacted ranges. The output (when packing) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD -Pack:True -Full:False // on 05/17/2020 02:47:55 (UTC) from Unicode 13.0.0. // 66182 (0x10286) codepoints covered. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa4, 0xa4, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa7, 0xa8, CodepointWidth::Ambiguous }, . . . UnicodeRange{ 0x1f210, 0x1f23b, CodepointWidth::Wide }, UnicodeRange{ 0x1f37e, 0x1f393, CodepointWidth::Wide }, UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ``` The output (when overriding) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD.ps1 -Pack:True -Full:False -NoOverrides:False // on 5/22/2020 11:17:39 PM (UTC) from Unicode 13.0.0. // 321205 (0x4E6B5) codepoints covered. // 240 (0xF0) codepoints overridden. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, ... UnicodeRange{ 0xfe20, 0xfe2f, CodepointWidth::Narrow }, // narrow combining ligatures (split into left/right halves, which take 2 columns together) ... UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ```
2020-06-03 09:16:14 +02:00
nounihan
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NOUPDATE
NOWAIT
NOYIELD
NOZORDER
NPM
npos
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
nrcs
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NSTATUS
ntapi
ntcon
ntcsrdll
ntdef
NTDEV
ntdll
ntifs
ntlpcapi
ntm
ntrtl
ntstatus
ntsubauth
NTSYSCALLAPI
nttree
nturtl
ntuser
NTVDM
ntverp
NTWIN
nuget
nullness
nullonfailure
nullopt
nullptr
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
NULs
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
numlock
numpad
NUMSCROLL
nupkg
Spec for Windows Terminal Process Model 2.0 (#7240) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
2021-02-05 13:19:32 +01:00
NVDA
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
NVIDIA
NVR
Nx
oa
OACR
oauth
objbase
ocf
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
ocolor
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
odl
oem
oemcp
OEMFONT
OEMFORMAT
offboarded
OI
Oj
OLEAUT
OLECHAR
onecore
ONECOREBASE
ONECORESDKTOOLS
ONECORESHELL
onecoreuap
onecoreuapuuid
onecoreuuid
ONECOREWINDOWS
onehalf
ONLCR
Oo
ci: fix spelling
2021-02-11 22:48:28 +01:00
openconsoleproxy
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
openbash
opencode
opencon
openconsole
OPENIF
OPENLINK
openps
opensource
openvt
openxmlformats
oq
ORIGINALFILENAME
osc
OSCBG
OSCCT
OSCFG
OSCRCC
Add support for OSC 52 (copy-to-clipboard) (#5823) With this commit, terminal will be able to copy text to the system clipboard by using OSC 52 MANIPULATE SELECTION DAATA. We chose not to implement the clipboard querying functionality offered by OSC 52, as sending the clipboard text to an application without the user's knowledge or consent is an immense security hole. We do not currently support the clipboard specifier Pc to specify which clipboard buffer should be filled # Base64 encoded `foo` $ echo -en "\e]52;;Zm9v\a" # Multiple lines # Base64 encoded `foo\r\nbar` $ echo -en "\e]52;;Zm9vDQpiYXI=\a" Closes #2946.
2020-06-30 03:55:40 +02:00
OSCSCB
tools: add Get-OSSConhostLog (#7250) This script takes a range of commits and generates a commit log with the git2git-excluded file changes filtered out. It also replaces GitHub issue numbers with GH-XXX so as to not confuse Git2Git or Azure DevOps. Community contributions are tagged with CC- so they can be detected later. The output looks like this: ``` Carlos Zamora (2) * Pass mouse button state into HandleMouse instead of asking win32 (GH-6765) Dustin L. Howett (6) * Disable MinimalCoreWin when OpenConsoleUniversalApp is false (GH-7203) James Holderness (1) * Add support for the "doubly underlined" graphic rendition attribute (CC-7223) ``` Yes, the numbers are wrong. No, it doesn't really matter.
2020-08-11 22:08:03 +02:00
OSCSCC
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
OSCWT
OSDEPENDSROOT
osfhandle
OSG
OSGENG
osign
build: move oss required to build conhost out of dep/ (#5451) 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.
2020-04-21 23:43:09 +02:00
oss
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ostream
ostringstream
Ou
ouicompat
outdir
outfile
Outof
OUTOFCONTEXT
OUTOFMEMORY
outout
Outptr
Ov
OVERLAPPEDWINDOW
OWNDC
OWNERDRAWFIXED
packageuwp
PACKCOORD
PACKVERSION
pagedown
pageup
PAINTPARAMS
PAINTSTRUCT
PALPC
pankaj
params
parentable
parms
passthrough
PATCOPY
pathcch
PATTERNID
pb
PBOOL
PBYTE
pcat
pcb
pcch
PCCHAR
PCCONSOLE
PCD
pch
PCHAR
PCIDLIST
PCIS
PCLIENT
PCLONG
PCOBJECT
pcon
PCONSOLE
PCONSOLEENDTASK
PCONSOLESETFOREGROUND
PCONSOLEWINDOWOWNER
pcoord
pcs
pcshell
PCSHORT
PCSR
PCSTR
PCUNICODE
PCWCH
PCWCHAR
PCWSTR
pda
pdb
pdbonly
pdbstr
pdf
pdp
pdtobj
pdw
PDWORD
pdx
peb
PEMAGIC
PENDTASKMSG
pfa
PFACENODE
pfed
pfi
PFILE
pfn
PFNCONSOLECREATEIOTHREAD
PFONT
PFONTENUMDATA
PFS
pgdn
pguid
pgup
PHANDLE
phhook
phwnd
pid
pidl
PIDLIST
pii
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
pinam
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
pinvoke
pipename
pipestr
pixelheight
PIXELSLIST
PJOBOBJECT
pkey
placeholders
platforming
playsound
plist
PLOGICAL
plugin
PMv
png
pnm
PNMLINK
pntm
PNTSTATUS
POBJECT
Podcast
POINTSLIST
POLYTEXTW
popd
POPF
poppack
popup
POPUPATTR
PORFLG
positionals
Move all wildcards into targets or expand them (#6406) Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must be generated by targets. We mostly use wildcards for pulling in PRI files that are dumped on disk by the translation tool. We don't want to check those in, so we can't expand references to them. To that end, I've introduced a new target that will take a list of folders containing resw files and expand wildcards under them. All[1] other wildcards have been moved into their respective targets _or_ simply expanded. [1]: Nothing has complained about the resource wildcards in CascadiaResources.build.items, so I haven't exploded it yet. Fixes #6214.
2020-06-08 23:01:47 +02:00
posix
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
POSTCHARBREAKS
POSX
POSXSCROLL
POSYSCROLL
ppci
ppf
ppguid
ppidl
pplx
PPORT
PPROC
PPROCESS
ppropvar
ppsi
ppsl
ppsp
ppsz
ppv
ppwch
PQRST
pragma
prc
prealigned
prebuilt
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
precendence
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
precomp
prect
prefast
prefilled
prefs
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
preinstalled
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
PRELOAD
PREMULTIPLIED
prepopulated
Introduce til::presorted_static_map (#7640) til::static_map can't be constexpr until we move to C++20. It can't be constexpr because std::sort isn't constexpr until then. This poses a problem: if we start using it and treating it like a map, we'll incur a potentially high cost in static initialization in both code size in .text and runtime. This commit introduces presorted_static_map, which is static_map except that it doesn't automatically sort its keys. That's the only difference. At this point, it's just a maplike interface to a constant array of pairs that does a binary search. It should be used for small tables that are used infrequently enough as to not warrant their cost in code size or initialization time. It should also be used for tables that aren't going to be edited much by developers (like the color table in #7578.)
2020-09-29 21:01:50 +02:00
presorted
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
PREVENTPINNING
PREVIEWLABEL
PREVIEWWINDOW
PREVLINE
prg
pri
printf
prioritization
processenv
processhost
PROCESSINFOCLASS
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
procs
Progman
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
proj
PROPERTYID
PROPERTYKEY
PROPERTYVAL
propsheet
PROPSHEETHEADER
PROPSHEETPAGE
propslib
propsys
PROPTITLE
propvar
propvariant
propvarutil
psa
psd
PSECURITY
pseudocode
pseudoconsole
pseudoterminal
psh
pshn
PSHNOTIFY
PSHORT
pshpack
PSINGLE
psl
psldl
psm
PSMALL
PSNRET
PSobject
psp
PSPCB
psr
PSTR
psuedoconsole
psz
ptch
ptr
ptrdiff
ptsz
PTYIn
PUCHAR
PULONG
PUNICODE
pushd
putchar
putwchar
pv
PVOID
pw
pwch
PWCHAR
PWDDMCONSOLECONTEXT
PWORD
pwsh
pwstr
pwsz
px
py
pythonw
qi
QJ
qo
Spec for Windows Terminal Window Management (#8135) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/4472-window-management/doc/specs/%235000%20-%20Process%20Model%202.0/%234472%20-%20Windows%20Terminal%20Session%20Management.md) ⇐ ## Summary of the Pull Request This is a more detailed spec for two parts of the "Process Model 2.0" work that's being tracked in #5000. In particular, this spec focuses on the management of Windows Terminal windows, including opening new tabs in existing windows. Largely, the reader is expected to have already read the spec in progress in #7240, and already be familiar with the concept of "Monarch" and "Peasant" windows as introduced by that spec. For that reason, ⚠ **THIS PR IS TARGETING THE BRANCH FOR #7240** ⚠. ### Abstract > This document is intended to serve as an addition to the [Process Model 2.0 > Spec]. That document provides a big-picture overview of changes to the entirety > of the Windows Terminal process architecture, including both the split of > window/content processes, as well as the introduction of monarch/peasant > processes. The focus of that document was to identify solutions to a set of > scenarios that were closely intertwined, and establish these solutions would > work together, without preventing any one scenario from working. What that > document did not do was prescribe specific solutions to the given scenarios. > > This document offers a deeper dive on a subset of the issues in [#5000], to > describe specifics for managing multiple windows with the Windows Terminal. This > includes features such as: > > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) ## PR Checklist * [x] Specs: #4472, Specs #2227 * [x] References: #5000, #4472, #2227, #7240 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_ ### Why are these two separate documents? I felt that the spec that is currently in review in #7240 and this doc should remain separate, yet closely related documents. #7240 is more about showing how this large set of problems discussed in #5000 can all be solved technically, and how those solutions can be used together. It establishes that none of the proposed solutions for components of #5000 will preclude the possibility of other components being solved. What it does _not_ do however is drill too deeply on the user experience that will be built on top of those architectural changes. This doc on the other hand focuses more closely on a pair of scenarios, and establishes how those scenarios will work technically, and how they'll be exposed to the user. ### TODO: * [x] A thought - How will we handle arguments like `--fullscreen`, `--initialSize r,c`? They only apply when creating a new window, right? * [x] When a `wt -s 1 split-pane` command is executed, we'll need to make sure to not _also_ create a new tab
2021-02-05 13:30:02 +01:00
QOL
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
QRSTU
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
qsort
queryable
QUESTIONMARK
quickedit
QWER
qzmp
RAII
RALT
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
rasterbar
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
rasterfont
rasterization
rawinput
RAWPATH
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
raytracers
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
razzlerc
rbar
rbegin
RBUTTON
RBUTTONDBLCLK
RBUTTONDOWN
RBUTTONUP
rcch
RCDATA
rcelms
rcl
rclsid
RCOA
RCOCA
RCOCW
RCONTROL
RCOW
rcv
rdbuf
RDONLY
rdpartysource
readback
READCONSOLE
READCONSOLEOUTPUT
READCONSOLEOUTPUTSTRING
Readline
readme
READMODE
readonly
READWRITE
realloc
reamapping
rects
redef
Redir
redirector
redist
redistributable
REDSCROLL
refactor
refactoring
REFCLSID
refcount
referencesource
REFGUID
REFIID
REFPROPERTYKEY
regex
REGISTEROS
REGISTERVDM
regkey
REGSTR
reingest
Relayout
RELBINPATH
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
remoting
renamer
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
renderengine
rendersize
spelling I
2020-06-05 20:57:17 +02:00
reparent
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
reparenting
replatformed
Replymessage
repositorypath
rescap
Resequence
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
reserialize
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
RESETCONTENT
resheader
resizable
resmimetype
restrictedcapabilities
resw
resx
retval
rfa
rfc
rftp
rgb
rgba
rgbi
rgch
rgci
rgfae
rgfte
rgi
rgn
rgp
rgpwsz
rgrc
rgs
rgui
rgw
rgwch
rhs
ri
RIGHTALIGN
RIGHTBUTTON
riid
RIPMSG
Rl
rmdir
RMENU
roadmap
robomac
roundtrip
Add a spec for output snapping (#2529) ## Summary of the Pull Request This proposes a change to how Terminal will scroll in response to newly generated output. The Terminal will scroll upon receiving new output if the viewport is at the bottom of the scroll history and no selection is active. This spec also explores the possibility of making this response configurable with a `snapOnOutput` profile setting. It also discusses the possibility of adding a scroll lock keybinding action. ## PR Checklist * [X] Spec for #980
2020-07-07 23:45:16 +02:00
rparen
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
RRF
Improve the legacy color conversions (#6358) This PR provides a faster algorithm for converting 8-bit and 24-bit colors into the 4-bit legacy values that are required by the Win32 console APIs. It also fixes areas of the code that were incorrectly using a simple 16-color conversion that didn't handle 8-bit and 24-bit values. The faster conversion algorithm should be an improvement for issues #783 and #3950. One of the main points of this PR was to fix the `ReadConsoleOutputAttribute` API, which was using a simplified legacy color conversion (the original `TextAttribute:GetLegacyAttributes` method), which could only handle values from the 16-color table. RGB values, and colors from the 256-color table, would be mapped to completely nonsensical values. This API has now been updated to use the more correct `Settings::GenerateLegacyAttributes` method. But there were also a couple of other places in the code that were using `GetLegacyAttributes` when they really had no reason to be working with legacy attributes at all. This could result in colors being downgraded to 4-bit values (often badly, as explained above), when the code was already perfectly capable of displaying the full 24-bits. This included the fill colors in the IME composer (in `ConsoleImeInfo`), and the construction of the highlighting colors in the color search/selection handler (`Selection::_HandleColorSelection`). I also got rid of some legacy attribute code in the `Popup` class, which was originally intended to update colors below the popup when the settings changed, but actually caused more problems than it solved. The other major goal of this PR was to improve the performance of the `GenerateLegacyAttributes` method, since the existing implementation could be quite slow when dealing with RGB values. The simple cases are handled much the same as they were before. For an `IsDefault` color, we get the default index from the `Settings::_wFillAttribute` field. For an `IsIndex16` color, the index can just be returned as is. For an `IsRgb` color, the RGB components are compressed down to 8 bits (3 red, 3 green, 2 blue), simply by dropping the least significant bits. This 8-bit value is then used to lookup a representative 16-color value from a hard-coded table. An `IsIndex256` color is also converted with a lookup table, just using the existing 8-bit index. The RGB mapping table was calculated by taking each compressed 8-bit color, and picking a entry from the _Campbell_ palette that best approximated that color. This was done by looking at a range of 24-bit colors that mapped to the 8-bit value, finding the best _Campbell_ match for each of them (using a [CIEDE2000] color difference calculation), and then the most common match became the index that the 8-bit value would map to. The 256-color table was just a simpler version of this process. For each entry in the table, we take the default RGB palette value, and find it's closest match in the _Campbell_ palette. Because these tables are hard-coded, the results won't adjust to changes in the palette. However, they should still produce reasonable results for palettes that follow the standard ANSI color range. And since they're only a very loose approximation of the colors anyway, the exact value really isn't that important. That said, I have tried to make sure that if you take an RGB value for a particular index in a reasonable color scheme, then the legacy color mapped from that value should ideally match the same index. This will never be possible for all color schemes, but I have tweaked a few of the table entries to improve the results for some of the common schemes. One other point worth making regarding the hard-coded tables: even if we wanted to take the active palette into account, that wouldn't actually be possible over a conpty connection, because we can't easily know what color scheme the client application is using. At least this way the results in conhost are guaranteed to be the same as in the Windows Terminal. [CIEDE2000]: https://en.wikipedia.org/wiki/Color_difference#CIEDE2000 ## Validation Steps Performed This code still passes the `TextAttributeTests` that check the basic `GetLegacyAttribute` behaviour and verify the all legacy attributes roundtrip correctly. However, some of the values in the `RgbColorTests` had to be updated, since we're now intentionally returning different values as a result of the changes to the RGB conversion algorithm. I haven't added additional unit tests, but I have done a lot of manual testing to see how well the new algorithm works with a range of colors and a variety of different color schemes. It's not perfect in every situation, but I think it works well enough for the purpose it serves. I've also confirmed that the issues reported in #5940 and #6247 are now fixed by these changes. Closes #5940 Closes #6247
2020-06-08 21:05:06 +02:00
RRRGGGBB
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
rsas
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
rtcore
RTEXT
rtf
RTFTo
Rtl
RTLREADING
RTTI
ru
ruleset
runas
runasradio
RUNDLL
runformat
runft
RUNFULLSCREEN
runsettings
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
runtests
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
runtimeclass
runuia
runut
Auto-format our XAML files and enforce in CI (#9589) This adds [`XamlStyler.Console`] to our solution, and calls it when we format the code, to also format our .xaml files. * `XamlStyler.Console` is a dotnet tool so it needs to be restored with `dotnet tool restore` * I've added a set of rules to approximately follow [@cmaneu's XAML guidelines]. Those guidelines also recommend things based on the code-behind, which this tool can't figure out, but also _don't matter that much_. * There's an extra step to strip BOMs from the output, since Xaml Styler adds a BOM by default. Some had them before and others didn't. BOMs have been nothing but trouble though. [`XamlStyler.Console`]: https://github.com/Xavalon/XamlStyler [@cmaneu's XAML guidelines]: https://github.com/cmaneu/xaml-coding-guidelines
2021-03-30 00:09:38 +02:00
runxamlformat
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
rvalue
RVERTICAL
Spec for Windows Terminal Process Model 2.0 (#7240) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
2021-02-05 13:19:32 +01:00
rxvt
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
RWIN
safearray
SAFECAST
safemath
sba
SBCS
SBCSDBCS
sbi
sbiex
sbold
scancode
scanline
schemename
SCL
scm
scprintf
SCRBUF
SCRBUFSIZE
screenbuffer
SCREENBUFFERINFO
screeninfo
screenshot
scriptload
Scrollable
scrollback
scrollbar
Scrolldown
Scrolldownpage
Scroller
SCROLLFORWARD
SCROLLINFO
scrolllock
scrolloffset
SCROLLSCALE
SCROLLSCREENBUFFER
Scrollup
Scrolluppage
scursor
sddl
sdeleted
sdk
SDKDDK
searchbox
securityappcontainer
segfault
SELCHANGE
SELECTALL
selectany
SELECTEDFONT
SELECTSTRING
Selfhosters
SERVERDLL
SETACTIVE
SETBUDDYINT
SETCOLOR
setcp
SETCURSEL
SETCURSOR
SETCURSORINFO
SETCURSORPOSITION
SETDISPLAYMODE
setfill
SETFOCUS
SETFONT
SETFOREGROUND
SETHARDWARESTATE
SETHOTKEY
SETICON
setintegritylevel
SETITEMDATA
SETITEMHEIGHT
SETKEYSHORTCUTS
setlocal
setlocale
SETMENUCLOSE
setmode
SETNUMBEROFCOMMANDS
SETOS
SETPALETTE
SETPOS
SETRANGE
SETSCREENBUFFERSIZE
SETSEL
SETTEXTATTRIBUTE
SETTINGCHANGE
SETTITLE
setw
Setwindow
SETWINDOWINFO
sfi
SFINAE
SFUI
sgr
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
SHANDLE
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
SHCo
shcore
shellapi
shellex
shellscalingapi
SHFILEINFO
SHGFI
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
SHGFP
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
SHIFTJIS
Shl
shlguid
shlobj
shlwapi
SHORTPATH
SHOWCURSOR
SHOWMAXIMIZED
SHOWMINNOACTIVE
SHOWNOACTIVATE
SHOWNORMAL
SHOWWINDOW
SHRT
sid
sidebyside
SIF
SIGDN
SINGLEFLAG
SINGLETHREADED
siup
Add support for focus mode (#6804) ## Summary of the Pull Request Add support for "focus" mode, which only displays the actual terminal content, no tabs or titlebar. The edges of the window are draggable to resize, but the window can't be moved in borderless mode. The window looks _slightly_ different bewteen different values for `showTabsInTitlebar`, because switching between the `NonClientIslandWindow` and the `IslandWindow` is _hard_. `showTabsInTitlebar` | Preview -- | -- `true` | ![image](https://user-images.githubusercontent.com/18356694/86639069-f5090080-bf9d-11ea-8b29-fb1e479a078d.png) `false` | ![image](https://user-images.githubusercontent.com/18356694/86639094-fafee180-bf9d-11ea-8fc0-6804234a5113.png) ## PR Checklist * [x] Closes #2238 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * **KNOWN ISSUE**: Upon resizing the NCIW, the top frame margin disappears, making that border disappear entirely. 6356aaf has a bunch of WIP work for me trying to fix that, but I couldn't get it quite right. ## Validation Steps Performed * Toggled between focus and fullscreen a _bunch_ in both modes.
2020-07-13 19:40:20 +02:00
SIZEBOX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
sizeof
SIZESCROLL
SKIPFONT
SKIPOWNPROCESS
SKIPOWNTHREAD
sku
sldl
SLGP
SLIST
slmult
sln
slpit
smalllogo
SManifest
SMARTQUOTE
SMTO
SND
SOLIDBOX
Solutiondir
somefile
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
SOURCEBRANCH
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
sourced
ci: update spelling allowlists/dictionaries (#5124) This is just some minor whitelisting/additions to dictionaries to catch up between when the spell checker PR was written and when it was finally merged. This is basically taking the spelling output from 499f24a29e6f321d6c4da8eb22c2ef0d30f13770 and putting it into files. The choice of files is arbitrary. I'm adding a `math.txt` dictionary because it's a reasonable example. The goal here is to get master to a green check mark ## Validation When I pushed this commit to my fork, the spell check action ran and gave me a check mark: https://github.com/jsoref/terminal/runs/534783276
2020-03-25 23:00:56 +01:00
SOURCESDIRECTORY
SPACEBAR
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
spammy
spand
splashscreen
sprintf
sqlproj
srand
src
SRCCODEPAGE
SRCCOPY
SRCINVERT
srcsrv
SRCSRVTRG
srctool
sre
srect
srv
srvinit
srvpipe
ssh
sstream
stackoverflow
standalone
STARTF
STARTUPINFO
STARTUPINFOEX
STARTUPINFOEXW
STARTUPINFOW
STARTWPARMS
STARTWPARMSA
STARTWPARMSW
Statusline
stdafx
STDAPI
stdcall
Use LanguageStandard over explicit compiler flag for C++17 (#8150) Turns out there's an actual way to specify C++17 for MSBuild purposes besides just passing the compile flag. ## References * Future C++20 support (modules) ## PR Checklist * [x] Closes random fact found while exploring VS16.8 preview C++20 modules. * [x] I work here. * [x] It still builds. ## Detailed Description of the Pull Request / Additional comments * We've been setting C++17 with just the flag passed to the compiler `cl.exe`. But it turns out that this particular `LanguageStandard` option will need to be set appropriately one day for us to use C++20 modules (as evidenced by the latest VS16.8 preview that I tried out to explore modules.) The `AdditionalOption` alone isn't enough to ensure that modules can be "seen" by other projects after production, but `LanguageStandard` is (and will set the compiler option as appropriate as well as whatever internal goo that MSBuild needs to hook up other stuff.) ## Validation Steps Performed * Built with it changed.
2020-11-04 00:20:48 +01:00
stdcpp
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
stderr
stdexcept
stdin
stdio
STDMETHODCALLTYPE
STDMETHODIMP
stdout
stgm
stl
stoi
stol
storelogo
stoul
stoutapot
strikethrough
stringstream
STRINGTABLE
strlen
strrev
strsafe
strtok
structs
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
STUVWX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
STX
stylecop
SUA
subcompartment
subkey
SUBLANG
sublicensable
submenu
subresource
subspan
substr
subsystemconsole
subsystemwindows
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
suiteless
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
svg
swapchain
swapchainpanel
swappable
SWMR
SWP
swprintf
sx
sy
SYMED
SYNCPAINT
syscalls
SYSCHAR
SYSCOMMAND
SYSDEADCHAR
Sysinternals
SYSKEYDOWN
SYSKEYUP
SYSLINK
SYSMENU
sysparams
sysparamsext
SYSTEMHAND
SYSTEMMENU
sz
tabview
TAdd
taef
TARG
targetentrypoint
TARGETLIBS
TARGETNAME
targetnametoken
Add High Contrast image assets (#6915) This commit adds image assets for High Contrast mode Tagging this issue so it contains a nice list of all the recent HC fixes: #5360 I made several changes to DHowett's script and added it to the repo: * Add support for generating high contrast icons * Add the ability to easily edit the "intermediate" (previously "zbase") files for manual hinting * Appease the spellchecker I created new SVGs for HC mode. There's one SVG for both Black and White modes -- I just invert the colors. Then I manually hinted the generated bitmaps for the production icons. I didn't bother hinting the Dev/Pre ones, so the text does get unreadable at small sizes. View the original images in #6915. Co-authored-by: Jeffrey Tippet <jtippet@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Closes #6822
2020-07-14 23:45:30 +02:00
targetsize
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
targetver
taskbar
tbar
Introduce JsonUtilsNew as documented in #5875 (#6355) Read the [JsonUtils Spec] for more details. This pull request introduces the next version of JsonUtils. It is in a separate file for ease of review and testing. JsonUtilsNew will be renamed in a subsequent commit that rewrites our JSON deserializers. ### Implementer's Notes I went with telescoping exceptions for the key parsing code, because it's totally possible that you can be five keys deep and encounter a type error. This lets us encode information about all failures in the chain instead of just the topmost one. The original JsonUtilsNew code changed to use `decay` everywhere because the tests wouldn't compile. We want to treat `GetValue<const guid>` _the same as_ `GetValue<guid>`, and this lets us do so. `decay` is awesome. I've been developing this with a shim that redirects `JsonUtils.h` to `JsonUtilsNew.h`. I am not comfortable deleting the original until we've moved off of it, and that _will_ be the subject of a followup PR. ## Validation Steps Performed So many tests. [JsonUtils Spec]: https://github.com/microsoft/terminal/blob/master/doc/cascadia/Json-Utility-API.md Refs #2550
2020-06-18 02:27:42 +02:00
TBase
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
tbc
tbi
Tbl
TBM
tchar
TCHFORMAT
TCI
tcome
tcommandline
tcommands
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
TDelegated
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
TDP
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
TEAMPROJECT
spelling II
2020-06-05 20:58:25 +02:00
tearoff
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Teb
techcommunity
technet
tellp
telnet
telnetd
templated
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
teraflop
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
terminalcore
TERMINALSCROLLING
terminfo
TEs
testapp
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
testbuildplatform
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
testcon
testd
testdlls
testenv
testlab
testlist
testmd
testmddefinition
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
testmode
testname
testnameprefix
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
TESTNULL
testpass
testpasses
testtestabc
testtesttesttesttest
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
testtimeout
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
TEXCOORD
texel
Introduce JsonUtilsNew as documented in #5875 (#6355) Read the [JsonUtils Spec] for more details. This pull request introduces the next version of JsonUtils. It is in a separate file for ease of review and testing. JsonUtilsNew will be renamed in a subsequent commit that rewrites our JSON deserializers. ### Implementer's Notes I went with telescoping exceptions for the key parsing code, because it's totally possible that you can be five keys deep and encounter a type error. This lets us encode information about all failures in the chain instead of just the topmost one. The original JsonUtilsNew code changed to use `decay` everywhere because the tests wouldn't compile. We want to treat `GetValue<const guid>` _the same as_ `GetValue<guid>`, and this lets us do so. `decay` is awesome. I've been developing this with a shim that redirects `JsonUtils.h` to `JsonUtilsNew.h`. I am not comfortable deleting the original until we've moved off of it, and that _will_ be the subject of a followup PR. ## Validation Steps Performed So many tests. [JsonUtils Spec]: https://github.com/microsoft/terminal/blob/master/doc/cascadia/Json-Utility-API.md Refs #2550
2020-06-18 02:27:42 +02:00
TExpected
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
textattribute
TEXTATTRIBUTEID
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
textbox
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
textboxes
textbuffer
TEXTINCLUDE
textinfo
TEXTMETRIC
TEXTMETRICW
textmode
tf
TFCAT
tfoo
TFunction
tga
threadpool
THUMBPOSITION
THUMBTRACK
TIcon
tif
tilunittests
Timeline
titlebar
TITLEISLINKNAME
Introduce JsonUtilsNew as documented in #5875 (#6355) Read the [JsonUtils Spec] for more details. This pull request introduces the next version of JsonUtils. It is in a separate file for ease of review and testing. JsonUtilsNew will be renamed in a subsequent commit that rewrites our JSON deserializers. ### Implementer's Notes I went with telescoping exceptions for the key parsing code, because it's totally possible that you can be five keys deep and encounter a type error. This lets us encode information about all failures in the chain instead of just the topmost one. The original JsonUtilsNew code changed to use `decay` everywhere because the tests wouldn't compile. We want to treat `GetValue<const guid>` _the same as_ `GetValue<guid>`, and this lets us do so. `decay` is awesome. I've been developing this with a shim that redirects `JsonUtils.h` to `JsonUtilsNew.h`. I am not comfortable deleting the original until we've moved off of it, and that _will_ be the subject of a followup PR. ## Validation Steps Performed So many tests. [JsonUtils Spec]: https://github.com/microsoft/terminal/blob/master/doc/cascadia/Json-Utility-API.md Refs #2550
2020-06-18 02:27:42 +02:00
TJson
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
tl
TLEN
Tlg
Tlgdata
TMAE
TMPF
TMult
tmultiple
tmux
todo
tofrom
tokenhelpers
tokenized
tokenizing
toolbars
TOOLINFO
Toolset
tooltip
TOPDOWNDIB
TOPLEFT
tools: add Get-OSSConhostLog (#7250) This script takes a range of commits and generates a commit log with the git2git-excluded file changes filtered out. It also replaces GitHub issue numbers with GH-XXX so as to not confuse Git2Git or Azure DevOps. Community contributions are tagged with CC- so they can be detected later. The output looks like this: ``` Carlos Zamora (2) * Pass mouse button state into HandleMouse instead of asking win32 (GH-6765) Dustin L. Howett (6) * Disable MinimalCoreWin when OpenConsoleUniversalApp is false (GH-7203) James Holderness (1) * Add support for the "doubly underlined" graphic rendition attribute (CC-7223) ``` Yes, the numbers are wrong. No, it doesn't really matter.
2020-08-11 22:08:03 +02:00
toplevel
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
TOPRIGHT
Introduce JsonUtilsNew as documented in #5875 (#6355) Read the [JsonUtils Spec] for more details. This pull request introduces the next version of JsonUtils. It is in a separate file for ease of review and testing. JsonUtilsNew will be renamed in a subsequent commit that rewrites our JSON deserializers. ### Implementer's Notes I went with telescoping exceptions for the key parsing code, because it's totally possible that you can be five keys deep and encounter a type error. This lets us encode information about all failures in the chain instead of just the topmost one. The original JsonUtilsNew code changed to use `decay` everywhere because the tests wouldn't compile. We want to treat `GetValue<const guid>` _the same as_ `GetValue<guid>`, and this lets us do so. `decay` is awesome. I've been developing this with a shim that redirects `JsonUtils.h` to `JsonUtilsNew.h`. I am not comfortable deleting the original until we've moved off of it, and that _will_ be the subject of a followup PR. ## Validation Steps Performed So many tests. [JsonUtils Spec]: https://github.com/microsoft/terminal/blob/master/doc/cascadia/Json-Utility-API.md Refs #2550
2020-06-18 02:27:42 +02:00
TOpt
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
tosign
Manually pass mouse wheel messages to TermControls (#5131) ## Summary of the Pull Request As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads). This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content. Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal. ## References * #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML ## PR Checklist * [x] Closes #979 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point` ## Validation Steps Performed * It works on my HP Spectre 2017 with a synaptics trackpad - I also made sure to test that `tmux` works in panes on this laptop * It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
2020-04-01 18:58:16 +02:00
touchpad
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
towlower
towupper
Tpp
Tpqrst
tprivapi
tracelog
tracelogging
traceloggingprovider
trackbar
TRACKCOMPOSITION
Manually pass mouse wheel messages to TermControls (#5131) ## Summary of the Pull Request As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads). This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content. Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal. ## References * #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML ## PR Checklist * [x] Closes #979 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point` ## Validation Steps Performed * It works on my HP Spectre 2017 with a synaptics trackpad - I also made sure to test that `tmux` works in panes on this laptop * It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
2020-04-01 18:58:16 +02:00
trackpad
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
transcoder
transitioning
Trd
TREX
triaged
triaging
TRIANGLESTRIP
TRIMZEROHEADINGS
truetype
trx
tsattrs
tsf
TStr
TSTRFORMAT
TSub
tt
TTBITMAP
ttf
TTFONT
TTFONTLIST
tthe
tthis
TTM
TTo
TVPP
Txtev
typechecked
typechecking
typedef
Introduce JsonUtilsNew as documented in #5875 (#6355) Read the [JsonUtils Spec] for more details. This pull request introduces the next version of JsonUtils. It is in a separate file for ease of review and testing. JsonUtilsNew will be renamed in a subsequent commit that rewrites our JSON deserializers. ### Implementer's Notes I went with telescoping exceptions for the key parsing code, because it's totally possible that you can be five keys deep and encounter a type error. This lets us encode information about all failures in the chain instead of just the topmost one. The original JsonUtilsNew code changed to use `decay` everywhere because the tests wouldn't compile. We want to treat `GetValue<const guid>` _the same as_ `GetValue<guid>`, and this lets us do so. `decay` is awesome. I've been developing this with a shim that redirects `JsonUtils.h` to `JsonUtilsNew.h`. I am not comfortable deleting the original until we've moved off of it, and that _will_ be the subject of a followup PR. ## Validation Steps Performed So many tests. [JsonUtils Spec]: https://github.com/microsoft/terminal/blob/master/doc/cascadia/Json-Utility-API.md Refs #2550
2020-06-18 02:27:42 +02:00
typeid
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
typeinfo
typelib
typename
typeof
typeparam
TYUI
Spec for Windows Terminal Process Model 2.0 (#7240) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
2021-02-05 13:19:32 +01:00
UAC
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
uap
uapadmin
tools: add a powershell script to generate CPWD from the UCD (#5946) This commit introduces Generate-CodepointWidthsFromUCD, a powershell (7+) script that will parse a UCD XML database in the UAX 42 format from https://www.unicode.org/Public/UCD/latest/ucdxml/ and generate CodepointWidthDetector's giant width array. By default, it will emit one UnicodeRange for every range of non-narrow glyphs with a different Width + Emoji + Emoji Presentation class; however, it can be run in "packing" and "full" mode. * Packing mode: ignore the width/emoji/pres class and combine adjacent runs that CPWD will treat the same. * This is for optimizing the number of individual ranges emitted into code. * Full mode: include narrow codepoints (helpful for visualization) It also supports overrides, provided in an XML document of the same format as the UCD itself. Entries in the overrides files are applied after the entire UCD is read and will replace any impacted ranges. The output (when packing) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD -Pack:True -Full:False // on 05/17/2020 02:47:55 (UTC) from Unicode 13.0.0. // 66182 (0x10286) codepoints covered. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa4, 0xa4, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa7, 0xa8, CodepointWidth::Ambiguous }, . . . UnicodeRange{ 0x1f210, 0x1f23b, CodepointWidth::Wide }, UnicodeRange{ 0x1f37e, 0x1f393, CodepointWidth::Wide }, UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ``` The output (when overriding) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD.ps1 -Pack:True -Full:False -NoOverrides:False // on 5/22/2020 11:17:39 PM (UTC) from Unicode 13.0.0. // 321205 (0x4E6B5) codepoints covered. // 240 (0xF0) codepoints overridden. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, ... UnicodeRange{ 0xfe20, 0xfe2f, CodepointWidth::Narrow }, // narrow combining ligatures (split into left/right halves, which take 2 columns together) ... UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ```
2020-06-03 09:16:14 +02:00
UAX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
ubuntu
spelling I
2020-06-05 20:57:17 +02:00
ucd
spelling II
2020-06-05 20:58:25 +02:00
UCD
tools: add a powershell script to generate CPWD from the UCD (#5946) This commit introduces Generate-CodepointWidthsFromUCD, a powershell (7+) script that will parse a UCD XML database in the UAX 42 format from https://www.unicode.org/Public/UCD/latest/ucdxml/ and generate CodepointWidthDetector's giant width array. By default, it will emit one UnicodeRange for every range of non-narrow glyphs with a different Width + Emoji + Emoji Presentation class; however, it can be run in "packing" and "full" mode. * Packing mode: ignore the width/emoji/pres class and combine adjacent runs that CPWD will treat the same. * This is for optimizing the number of individual ranges emitted into code. * Full mode: include narrow codepoints (helpful for visualization) It also supports overrides, provided in an XML document of the same format as the UCD itself. Entries in the overrides files are applied after the entire UCD is read and will replace any impacted ranges. The output (when packing) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD -Pack:True -Full:False // on 05/17/2020 02:47:55 (UTC) from Unicode 13.0.0. // 66182 (0x10286) codepoints covered. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa4, 0xa4, CodepointWidth::Ambiguous }, UnicodeRange{ 0xa7, 0xa8, CodepointWidth::Ambiguous }, . . . UnicodeRange{ 0x1f210, 0x1f23b, CodepointWidth::Wide }, UnicodeRange{ 0x1f37e, 0x1f393, CodepointWidth::Wide }, UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ``` The output (when overriding) looks like this: ```c++ // Generated by Generate-CodepointWidthsFromUCD.ps1 -Pack:True -Full:False -NoOverrides:False // on 5/22/2020 11:17:39 PM (UTC) from Unicode 13.0.0. // 321205 (0x4E6B5) codepoints covered. // 240 (0xF0) codepoints overridden. static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{ UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous }, ... UnicodeRange{ 0xfe20, 0xfe2f, CodepointWidth::Narrow }, // narrow combining ligatures (split into left/right halves, which take 2 columns together) ... UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous }, }; ```
2020-06-03 09:16:14 +02:00
ucdxml
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
uch
UCHAR
ucs
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
udk
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
UDM
uer
uget
uia
UIACCESS
uiacore
uiautomationcore
Uid
uielem
UIELEMENTENABLEDONLY
uint
uintptr
ul
ulcch
ulong
Unadvise
unattend
uncomment
UNCPRIORITY
undef
Unescape
unexpand
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
Unfocus
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
unhighlighting
spelling I
2020-06-05 20:57:17 +02:00
unhosted
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
unicode
UNICODESTRING
UNICODETEXT
UNICRT
UNINIT
uninitialize
uninstall
Uniscribe
unittest
unittesting
universaltest
Unk
unknwn
unmark
UNORM
unparseable
unpause
Unregister
Unregistering
unte
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
untests
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
untextured
untimes
UPDATEDISPLAY
UPDOWN
UPKEY
Improve support for VT character sets (#4496) This PR improves our VT character set support, enabling the [`SCS`] escape sequences to designate into all four G-sets with both 94- and 96-character sets, and supports invoking those G-sets into both the GL and GR areas of the code table, with [locking shifts] and [single shifts]. It also adds [`DOCS`] sequences to switch between UTF-8 and the ISO-2022 coding system (which is what the VT character sets require), and adds support for a lot more characters sets, up to around the level of a VT510. [`SCS`]: https://vt100.net/docs/vt510-rm/SCS.html [locking shifts]: https://vt100.net/docs/vt510-rm/LS.html [single shifts]: https://vt100.net/docs/vt510-rm/SS.html [`DOCS`]: https://en.wikipedia.org/wiki/ISO/IEC_2022#Interaction_with_other_coding_systems ## Detailed Description of the Pull Request / Additional comments To make it easier for us to declare a bunch of character sets, I've made a little `constexpr` class that can build up a mapping table from a base character set (ASCII or Latin1), along with a collection of mappings for the characters the deviate from the base set. Many of the character sets are simple variations of ASCII, so they're easy to define this way. This class then casts directly to a `wstring_view` which is how the translation tables are represented in most of the code. We have an array of four of these tables representing the four G-sets, two instances for the active left and right tables, and one instance for the single shift table. Initially we had just one `DesignateCharset` method, which could select the active character set. We now have two designate methods (for 94- and 96- character sets), and each takes a G-set number specifying the target of the designation, and a pair of characters identifying the character set that will be designated (at the higher VT levels, character sets are often identified by more than one character). There are then two new `LockingShift` methods to invoke these G-sets into either the GL or GR area of the code table, and a `SingleShift` method which invokes a G-set temporarily (for just the next character that is output). I should mention here that I had to make some changes to the state machine to make these single shift sequences work. The problem is that the input state machine treats `SS3` as the start of a control sequence, while the output state machine needs it to be dispatched immediately (it's literally the _Single Shift 3_ escape sequence). To make that work, I've added a `ParseControlSequenceAfterSs3` callback in the `IStateMachineEngine` interface to decide which behavior is appropriate. When it comes to mapping a character, it's simply an array reference into the appropriate `wstring_view` table. If the single shift table is set, that takes preference. Otherwise the GL table is used for characters in the range 0x20 to 0x7F, and the GR table for characters 0xA0 to 0xFF (technically some character sets will only map up to 0x7E and 0xFE, but that's easily controlled by the length of the `wstring_view`). The `DEL` character is a bit of a special case. By default it's meant to be ignored like the `NUL` character (it's essentially a time-fill character). However, it's possible that it could be remapped to a printable character in a 96-character set, so we need to check for that after the translation. This is handled in the `AdaptDispatch::Print` method, so it doesn't interfere with the primary `PrintString` code path. The biggest problem with this whole process, though, is that the GR mappings only really make sense if you have access to the raw output, but by the time the output gets to us, it would already have been translated to Unicode by the active code page. And in the case of UTF-8, the characters we eventually receive may originally have been composed from two or more code points. The way I've dealt with this was to disable the GR translations by default, and then added support for a pair of ISO-2022 `DOCS` sequences, which can switch the code page between UTF-8 and ISO-8859-1. When the code page is ISO-8859-1, we're essentially receiving the raw output bytes, so it's safe to enable the GR translations. This is not strictly correct ISO-2022 behavior, and there are edge cases where it's not going to work, but it's the best solution I could come up with. ## Validation Steps Performed As a result of the `SS3` changes in the state machine engine, I've had to move the existing `SS3` tests from the `OutputEngineTest` to the `InputEngineTest`, otherwise they would now fail (technically they should never have been output tests). I've added no additional unit tests, but I have done a lot of manual testing, and made sure we passed all the character set tests in Vttest (at least for the character sets we currently support). Note that this required a slightly hacked version of the app, since by default it doesn't expose a lot of the test to low-level terminals, and we currently identify as a VT100. Closes #3377 Closes #3487
2020-06-04 21:40:15 +02:00
UPSS
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
upvote
uri
url
urlencoded
Urxvt
USASCII
usebackq
USECALLBACK
USECOLOR
USECOUNTCHARS
USEDEFAULT
USEDX
USEFILLATTRIBUTE
USEGLYPHCHARS
USEHICON
USEPOSITION
userbase
USERDATA
userdpiapi
username
Userp
userprivapi
userprofile
USERSRV
USESHOWWINDOW
USESIZE
USESTDHANDLES
ushort
USRDLL
utf
utils
utr
uuid
uuidof
uuidv
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
UVWX
UVWXY
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
UWA
uwp
uxtheme
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
vals
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Vanara
vararg
vbproj
vclib
Vcount
vcpkg
vcprintf
vcproj
vcrt
vcvarsall
vcxitems
vcxproj
vec
VERCTRL
versioning
VERTBAR
vf
VFT
vga
vgaoem
viewkind
viewports
Virt
VIRTTERM
Virtualizing
vk
vkey
VKKEYSCAN
VMs
VPA
VPATH
VPR
VPrintf
VProc
VRaw
VREDRAW
vsc
vscprintf
VSCROLL
vsinfo
vsnprintf
vso
vspath
vsprintf
VSTAMP
vstest
VSTS
VSTT
vstudio
vswhere
vtapp
ci: remove "wether" from dictionary, add "VTE" (#5207) _Technically_, "wether" is a word but I'd be shocked if there's a scenario for us to use it properly in this repo, so I'm pulling it from the dictionary. Also, in #5200, we added "VTE", which is totally a valid acronym, to the codebase, but not the whitelist. I'm not sure why the bot let me merge it anyways, but I'm fixing it now.
2020-04-01 21:15:20 +02:00
VTE
Refactor VT control sequence identification (#7304) This PR changes the way VT control sequences are identified and dispatched, to be more efficient and easier to extend. Instead of parsing the intermediate characters into a vector, and then having to identify a sequence using both that vector and the final char, we now use just a single `uint64_t` value as the identifier. The way the identifier is constructed is by taking the private parameter prefix, each of the intermediate characters, and then the final character, and shifting them into a 64-bit integer one byte at a time, in reverse order. For example, the `DECTLTC` control has a private parameter prefix of `?`, one intermediate of `'`, and a final character of `s`. The ASCII values of those characters are `0x3F`, `0x27`, and `0x73` respectively, and reversing them gets you 0x73273F, so that would then be the identifier for the control. The reason for storing them in reverse order, is because sometimes we need to look at the first intermediate to determine the operation, and treat the rest of the sequence as a kind of sub-identifier (the character set designation sequences are one example of this). When in reverse order, this can easily be achieved by masking off the low byte to get the first intermediate, and then shifting the value right by 8 bits to get a new identifier with the rest of the sequence. With 64 bits we have enough space for a private prefix, six intermediates, and the final char, which is way more than we should ever need (the _DEC STD 070_ specification recommends supporting at least three intermediates, but in practice we're unlikely to see more than two). With this new way of identifying controls, it should now be possible for every action code to be unique (for the most part). So I've also used this PR to clean up the action codes a bit, splitting the codes for the escape sequences from the control sequences, and sorting them into alphabetical order (which also does a reasonable job of clustering associated controls). ## Validation Steps Performed I think the existing unit tests should be good enough to confirm that all sequences are still being dispatched correctly. However, I've also manually tested a number of sequences to make sure they were still working as expected, in particular those that used intermediates, since they were the most affected by the dispatch code refactoring. Since these changes also affected the input state machine, I've done some manual testing of the conpty keyboard handling (both with and without the new Win32 input mode enabled) to make sure the keyboard VT sequences were processed correctly. I've also manually tested the various VT mouse modes in Vttest to confirm that they were still working correctly too. Closes #7276
2020-08-18 20:57:52 +02:00
VTID
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
vtio
vtmode
vtpipeterm
vtpt
vtrenderer
VTRGB
VTRGBTo
vtseq
vtterm
vttest
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
VWX
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
waaay
waitable
waivable
WANSUNG
WANTARROWS
WANTTAB
wapproj
wav
wbuilder
wch
wchar
WCIA
WCIW
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
WClass
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
wcout
wcschr
wcscmp
wcscpy
WCSHELPER
wcsicmp
wcslen
wcsnicmp
wcsrchr
wcsrev
wcstod
wcstoul
wddm
wddmcon
wddmconrenderer
WDDMCONSOLECONTEXT
wdm
webpage
website
websocket
wekyb
WEOF
wex
wextest
wextestclass
wfdopen
WFill
wfopen
wfstream
WHelper
whitelisting
WIDTHSCROLL
Widthx
wiki
wikia
wikipedia
wil
WImpl
WINAPI
winbase
winbasep
wincon
winconp
winconpty
winconptydll
winconptylib
wincontypes
WINCORE
windbg
WINDEF
WINDIR
windll
WINDOWALPHA
Windowbuffer
windowdpiapi
WINDOWEDGE
windowext
WINDOWFRAME
windowime
WINDOWINFO
windowio
windowmetrics
WINDOWPLACEMENT
windowpos
WINDOWPOSCHANGED
WINDOWPOSCHANGING
windowproc
windowrect
windowsapp
windowsinternalstring
WINDOWSIZE
windowsx
WINDOWTEXT
windowtheme
WINDOWTITLE
winevent
winfx
wingdi
spelling I
2020-06-05 20:57:17 +02:00
winget
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
WINIDE
winioctl
winmd
winmeta
winmgr
winmm
winnt
Winperf
WInplace
winres
winrt
wintelnet
winternl
winuser
winuserp
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
WINVER
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
wistd
wixproj
wline
wlinestream
wmain
WMSZ
wnd
WNDALLOC
WNDCLASS
WNDCLASSEX
WNDCLASSW
Wndproc
WNegative
WNull
Make sure we don't hide the cursor until the IME starts (#7673) Some IME implementations do not produce composition strings, and their users have come to rely on the cursor that conhost traditionally left on until a composition string showed up. We shouldn't hide the cursor until we get a string (as opposed to hiding it when composition begins) so as to not break those IMEs. Related to #6207. Fixes MSFT:29219348
2020-09-18 21:25:39 +02:00
wnwb
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
workarea
workaround
workflow
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
workitem
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
wostream
WOutside
WOWARM
WOWx
wparam
WPartial
wpf
WPR
WPrep
WPresent
wprintf
wprp
wprpi
wregex
WResult
writeback
writechar
WRITECONSOLE
WRITECONSOLEINPUT
WRITECONSOLEOUTPUT
WRITECONSOLEOUTPUTSTRING
wrl
wrp
WRunoff
WScript
wsl
WSLENV
wsmatch
WSpace
wss
wstr
wstring
wstringstream
wsz
wtd
WTest
WTEXT
WTo
wtof
wtoi
ci: update to Spell check to 0.0.17a (#9014) ### Plurals and paste tenses In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were automatically tolerated. This turned out to be a bad design choice on my part. The basic example is that `potatos` would sometimes be treated as a mistake and sometimes not (depending on the presence of `potato`). You can see in this PR, that this logic resulted in `Applys` being accepted as a word along with `AppContainered` -- there's nothing intrinsically wrong w/ the latter, but unfortunately in order to screen out the former, my shortcut just couldn't stick around. This means that the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as you can see, not really by much. This is also why `thereses` (a user) was accepted as a word in the past (therese is in the base dictionary, so `therese` + `s` was acceptable). ### Pull requests When GitHub initially introduced GitHub Actions, the event for `pull_request` was created without enough permission for a tool like this to work properly. I worked around that by using the `schedule` event. In 2020, they introduced a replacement event `pull_request_target` which has enough permission. This means that I can stop relying on the `schedule` event. ### Miscellaneous * I've folded together some `expect/` files since now is as good a time as any. * I've included a hint about `excludes.txt` (I added a similar one for our primary repo recently, and it came up this week in `microsoft/terminal` -- @zadjii-msft) * I've standardized on a default of `.github/actions/spelling` to make the out of the box experience easier for new adopters, so I'm applying that change here -- if you're attached to the old directory name, specifying it is still supported. -- note the directory rename may cause a merge conflict for people with open PRs and changes to the contents, this shouldn't be a big problem.
2021-02-03 20:17:38 +01:00
WTs
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
wtw
wtypes
Make sure we don't hide the cursor until the IME starts (#7673) Some IME implementations do not produce composition strings, and their users have come to rely on the cursor that conhost traditionally left on until a composition string showed up. We shouldn't hide the cursor until we get a string (as opposed to hiding it when composition begins) so as to not break those IMEs. Related to #6207. Fixes MSFT:29219348
2020-09-18 21:25:39 +02:00
Wubi
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
WUX
WVerify
wwaproj
WWith
wx
wxh
xa
xact
xamarin
xaml
Xamlmeta
xargs
xaz
xbf
xbutton
XBUTTONDBLCLK
XBUTTONDOWN
XBUTTONUP
XCast
XCENTER
XColors
xcopy
XCount
xdy
XEncoding
Add support for more OSC color formats (#7578) * Correct the behaviour of parsing `rgb:R/G/B`. It should be interpreted as `RR/GG/BB` instead of `0R/0G/0B` * Add support for `rgb:RRR/GGG/BBB` and `rgb:RRRR/GGGG/BBBB`. The behaviour of 12 bit variants is to repeat the first digit at the end, e.g. `rgb:123/456/789` becomes `rgb:1231/4564/7897`. * Add support for `#` formats. We are following the rules of [XParseColor] by interpreting `#RGB` as `R000G000B000`. * Add support for XOrg app color names, which are supported by xterm, VTE and many other terminal emulators. * Multi-parameter OSC 4 is now supported. * The chaining of OSC 10-12 is not yet supported. But the parameter validation is relaxed by parsing the parameters as multi-params but only use the first one, which means `\e]10;rgb:R/G/B;` and `\e]10:rgb:R/G/B;invalid` will execute `OSC 10` with the first color correctly. This fixes some of the issues mentioned in #942 but not all of them. [XParseColor]: https://linux.die.net/man/3/xparsecolor Closes #3715
2020-10-15 02:29:10 +02:00
xes
Xes
XES
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
xff
XFile
Add support for double-width/double-height lines in conhost (#8664) This PR adds support for the VT line rendition attributes, which allow for double-width and double-height line renditions. These renditions are enabled with the `DECDWL` (double-width line) and `DECDHL` (double-height line) escape sequences. Both reset to the default rendition with the `DECSWL` (single-width line) escape sequence. For now this functionality is only supported by the GDI renderer in conhost. There are a lot of changes, so this is just a general overview of the main areas affected. Previously it was safe to assume that the screen had a fixed width, at least for a given point in time. But now we need to deal with the possibility of different lines have different widths, so all the functions that are constrained by the right border (text wrapping, cursor movement operations, and sequences like `EL` and `ICH`) now need to lookup the width of the active line in order to behave correctly. Similarly it used to be safe to assume that buffer and screen coordinates were the same thing, but that is no longer true. Lots of places now need to translate back and forth between coordinate systems dependent on the line rendition. This includes clipboard handling, the conhost color selection and search, accessibility location tracking and screen reading, IME editor positioning, "snapping" the viewport, and of course all the rendering calculations. For the rendering itself, I've had to introduce a new `PrepareLineTransform` method that the render engines can use to setup the necessary transform matrix for a given line rendition. This is also now used to handle the horizontal viewport offset, since that could no longer be achieved just by changing the target coordinates (on a double width line, the viewport offset may be halfway through a character). I've also had to change the renderer's existing `InvalidateCursor` method to take a `SMALL_RECT` rather than a `COORD`, to allow for the cursor being a variable width. Technically this was already a problem, because the cursor could occupy two screen cells when over a double-width character, but now it can be anything between one and four screen cells (e.g. a double-width character on the double-width line). In terms of architectural changes, there is now a new `lineRendition` field in the `ROW` class that keeps track of the line rendition for each row, and several new methods in the `ROW` and `TextBuffer` classes for manipulating that state. This includes a few helper methods for handling the various issues discussed above, e.g. position clamping and translating between coordinate systems. ## Validation Steps Performed I've manually confirmed all the double-width and double-height tests in _Vttest_ are now working as expected, and the _VT100 Torture Test_ now renders correctly (at least the line rendition aspects). I've also got my own test scripts that check many of the line rendition boundary cases and have confirmed that those are now passing. I've manually tested as many areas of the conhost UI that I could think of, that might be affected by line rendition, including things like searching, selection, copying, and color highlighting. For accessibility, I've confirmed that the _Magnifier_ and _Narrator_ correctly handle double-width lines. And I've also tested the Japanese IME, which while not perfect, is at least useable. Closes #7865
2021-02-18 06:44:50 +01:00
XFORM
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
XManifest
XMath
XMFLOAT
xml
xmlns
xor
Add support for more OSC color formats (#7578) * Correct the behaviour of parsing `rgb:R/G/B`. It should be interpreted as `RR/GG/BB` instead of `0R/0G/0B` * Add support for `rgb:RRR/GGG/BBB` and `rgb:RRRR/GGGG/BBBB`. The behaviour of 12 bit variants is to repeat the first digit at the end, e.g. `rgb:123/456/789` becomes `rgb:1231/4564/7897`. * Add support for `#` formats. We are following the rules of [XParseColor] by interpreting `#RGB` as `R000G000B000`. * Add support for XOrg app color names, which are supported by xterm, VTE and many other terminal emulators. * Multi-parameter OSC 4 is now supported. * The chaining of OSC 10-12 is not yet supported. But the parameter validation is relaxed by parsing the parameters as multi-params but only use the first one, which means `\e]10;rgb:R/G/B;` and `\e]10:rgb:R/G/B;invalid` will execute `OSC 10` with the first color correctly. This fixes some of the issues mentioned in #942 but not all of them. [XParseColor]: https://linux.die.net/man/3/xparsecolor Closes #3715
2020-10-15 02:29:10 +02:00
xorg
XOrg
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Xpath
XPosition
XResource
xsd
xsi
xsize
Auto-format our XAML files and enforce in CI (#9589) This adds [`XamlStyler.Console`] to our solution, and calls it when we format the code, to also format our .xaml files. * `XamlStyler.Console` is a dotnet tool so it needs to be restored with `dotnet tool restore` * I've added a set of rules to approximately follow [@cmaneu's XAML guidelines]. Those guidelines also recommend things based on the code-behind, which this tool can't figure out, but also _don't matter that much_. * There's an extra step to strip BOMs from the output, since Xaml Styler adds a BOM by default. Some had them before and others didn't. BOMs have been nothing but trouble though. [`XamlStyler.Console`]: https://github.com/Xavalon/XamlStyler [@cmaneu's XAML guidelines]: https://github.com/cmaneu/xaml-coding-guidelines
2021-03-30 00:09:38 +02:00
xstyler
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
XSubstantial
xtended
xterm
XTest
Add support for XTPUSHSGR / XTPOPSGR (#1978) Implement the `XTPUSHSGR` and `XTPOPSGR` control sequences (see #1796). This change adds a new pair of methods to `ITermDispatch`: `PushGraphicsRendition` and `PopGraphicsRendition`, and then plumbs the change through `AdaptDispatch`, `TerminalDispatch`, `ITerminalApi` and `TerminalApi`. The stack logic is encapsulated in the `SgrStack` class, to allow it to be reused between the two APIs (`AdaptDispatch` and `TerminalDispatch`). Like xterm, only ten levels of nesting are supported. The stack is implemented as a "ring stack": if you push when the stack is full, the bottom of the stack will be dropped to make room. Partial pushes (see the description of `XTPUSHSGR` in Issue #1796) are implemented per xterm spec. ## Validation Steps Performed Tests added, plus manual verification of the feature. Closes #1796
2021-02-18 03:31:52 +01:00
XTPUSHSGR
XTPOPSGR
Helix Testing (#6992) Use the Helix testing orchestration framework to run our Terminal LocalTests and Console Host UIA tests. ## References #### Creates the following new issues: - #7281 - re-enable local tests that were disabled to turn on Helix - #7282 - re-enable UIA tests that were disabled to turn on Helix - #7286 - investigate and implement appropriate compromise solution to how Skipped is handled by MUX Helix scripts #### Consumes from: - #7164 - The update to TAEF includes wttlog.dll. The WTT logs are what MUX's Helix scripts use to track the run state, convert to XUnit format, and notify both Helix and AzDO of what's going on. #### Produces for: - #671 - Making Terminal UIA tests is now possible - #6963 - MUX's Helix scripts are already ready to capture PGO data on the Helix machines as certain tests run. Presuming we can author some reasonable scenarios, turning on the Helix environment gets us a good way toward automated PGO. #### Related: - #4490 - We lost the AzDO integration of our test data when I moved from the TAEF/VSTest adapter directly back to TE. Thanks to the WTTLog + Helix conversion scripts to XUnit + new upload phase, we have it back! ## PR Checklist * [x] Closes #3838 * [x] I work here. * [x] Literally adds tests. * [ ] Should I update a testing doc in this repo? * [x] Am core contributor. Hear me roar. * [ ] Correct spell-checking the right way before merge. ## Detailed Description of the Pull Request / Additional comments We have had two classes of tests that don't work in our usual build-machine testing environment: 1. Tests that require interactive UI automation or input injection (a.k.a. require a logged in user) 2. Tests that require the entire Windows Terminal to stand up (because our Xaml Islands dependency requires 1903 or later and the Windows Server instance for the build is based on 1809.) The Helix testing environment solves both of these and is brought to us by our friends over in https://github.com/microsoft/microsoft-ui-xaml. This PR takes a large portion of scripts and pipeline configuration steps from the Microsoft-UI-XAML repository and adjusts them for Terminal needs. You can see the source of most of the files in either https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/Helix or https://github.com/microsoft/microsoft-ui-xaml/tree/master/build/AzurePipelinesTemplates Some of the modifications in the files include (but are not limited to) reasons like: - Our test binaries are named differently than MUX's test binaries - We don't need certain types of testing that MUX does. - We use C++ and C# tests while MUX was using only C# tests (so the naming pattern and some of the parsing of those names is different e.g. :: separators in C++ and . separators in C#) - Our pipeline phases work a bit differently than MUX and/or we need significantly fewer pieces to the testing matrix (like we don't test a wide variety of OS versions). The build now runs in a few stages: 1. The usual build and run of unit tests/feature tests, packaging verification, and whatnot. This phase now also picks up and packs anything required for running tests in Helix into an artifact. (It also unifies the artifact name between the things Helix needs and the existing build outputs into the single `drop` artifact to make life a little easier.) 2. The Helix preparation build runs that picks up those artifacts, generates all the scripts required for Helix to understand the test modules/functions from our existing TAEF tests, packs it all up, and queues it on the Helix pool. 3. Helix generates a VM for our testing environment and runs all the TAEF tests that require it. The orchestrator at helix.dot.net watches over this and tracks the success/fail and progress of each module and function. The scripts from our MUX friends handle installing dependencies, making the system quiet for better reliability, detecting flaky tests and rerunning them, and coordinating all the log uploads (including for the subruns of tests that are re-run.) 4. A final build phase is run to look through the results with the Helix API and clean up the marking of tests that are flaky, link all the screenshots and console output logs into the AzDO tests panel, and other such niceities. We are set to run Helix tests on the Feature test policy of only x64 for now. Additionally, because the set up of the Helix VMs takes so long, we are *NOT* running these in PR trigger right now as I believe we all very much value our 15ish minute PR turnaround (and the VM takes another 15 minutes to just get going for whatever reason.) For now, they will only run as a rolling build on master after PRs are merged. We should still know when there's an issue within about an hour of something merging and multiple PRs merging fast will be done on the rolling build as a batch run (not one per). In addition to setting up the entire Helix testing pipeline for the tests that require it, I've preserved our classic way of running unit and feature tests (that don't require an elaborate environment) directly on the build machines. But with one bonus feature... They now use some of the scripts from MUX to transform their log data and report it to AzDO so it shows up beautifully in the build report. (We used to have this before I removed the MStest/VStest wrapper for performance reasons, but now we can have reporting AND performance!) See https://dev.azure.com/ms/terminal/_build/results?buildId=101654&view=ms.vss-test-web.build-test-results-tab for an example. I explored running all of the tests on Helix but.... the Helix setup time is long and the resources are more expensive. I felt it was better to preserve the "quick signal" by continuing to run these directly on the build machine (and skipping the more expensive/slow Helix setup if they fail.) It also works well with the split between PR builds not running Helix and the rolling build running Helix. PR builds will get a good chunk of tests for a quick turn around and the rolling build will finish the more thorough job a bit more slowly. ## Validation Steps Performed - [x] Ran the updated pipelines with Pull Request configuration ensuring that Helix tests don't run in the usual CI - [x] Ran with simulation of the rolling build to ensure that the tests now running in Helix will pass. All failures marked for follow on in reference issues.
2020-08-18 20:23:24 +02:00
xunit
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
xutr
xvalue
XVIRTUALSCREEN
XWalk
ci: spelling: update to 0.0.14a (#5270)
2020-04-07 23:58:12 +02:00
xy
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
Xzn
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
yact
YAML
YCast
YCENTER
YCount
YDPI
yml
YOffset
YPosition
YSize
YSubstantial
YVIRTUALSCREEN
Yw
YWalk
yx
Add some tests for TextBuffer::Reflow (#8715) This is by no means comprehensive. It will be unmarked as draft when it is more comprehensive. This pull request adds some tests for resizing a TextBuffer and reflowing its contents. Each test takes the form of an initial state and a number of buffers of different sizes. The initial state is used to seed the first TextBuffer, and the subsequent buffers are only used to compare. I manually reimplemented some of the DBCS logic to ensure that the buffers contain _exactly_ what they're supposed to. I know this is non-ideal. After some of the CharRow changes in #8446 land, this will need to be updated. There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource allows us to programmatically return test cases. It's a code-only version of its support for parameterized tests of the form `Data:x = {0, 1, 2}` . The only downsides are... 1. It looks like COM (it is not using COM under the hood, just the COM ABI) 2. Property values must be returned as strings. To best support rich test types, I used IDataSource to produce _a lit of array indices_ and nothing more. The test is run once for array member, and it is the test's responsibility to look up the object to which that index refers. Works great though! Each reflow test is its own unit, and a failure in an earlier reflow test will not tank a later one.
2021-01-18 22:51:29 +01:00
YZ
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
Zc
ZCmd
ZCtrl
zd
zh
ZM
Fix copying wrapped lines by implementing better scrolling (#5181) Now that the Terminal is doing a better job of actually marking which lines were and were not wrapped, we're not always copying lines as "wrapped" when they should be. We're more correctly marking lines as not wrapped, when previously we'd leave them marked wrapped. The real problem is here in the `ScrollFrame` method - we'd manually newline the cursor to make the terminal's viewport shift down to a new line. If we had to scroll the viewport for a _wrapped_ line, this would cause the Terminal to mark that line as broken, because conpty would emit an extra `\n` that didn't actually exist. This more correctly implements `ScrollFrame`. Now, well move where we "thought" the cursor was, so when we get to the next `PaintBufferLine`, if the cursor needs to newline for the next line, it'll newline, but if we're in the middle of a wrapped line, we'll just keep printing the wrapped line. A couple follow up bugs were found to be caused by the same bad logic. See #5039 and #5161 for more details on the investigations there. ## References * #4741 RwR, which probably made this worse * #5122, which I branched off of * #1245, #357 - a pair of other conpty wrapped lines bugs * #5228 - A followup issue for this PR ## PR Checklist * [x] Closes #5113 * [x] Closes #5180 (by fixing DECRST 25) * [x] Closes #5039 * [x] Closes #5161 (by ensuring we only `removeSpaces` on the actual bottom line) * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * Checked the cases from #1245, #357 to validate that they still work * Added more and more tests for these scenarios, and then I added MORE tests * The entire team played with this in selfhost builds
2020-04-09 02:06:25 +02:00
zsh
ci: run spell check in CI, fix remaining issues (#4799) This commit introduces a github action to check our spelling and fixes the following misspelled words so that we come up green. It also renames TfEditSes to TfEditSession, because Ses is not a word. currently, excerpt, fallthrough, identified, occurred, propagate, provided, rendered, resetting, separate, succeeded, successfully, terminal, transferred, adheres, breaks, combining, preceded, architecture, populated, previous, setter, visible, window, within, appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing, prioritized, aforementioned, check in, build, filling, indices, layout, mapping, trying, scroll, terabyte, vetoes, viewport, whose
2020-03-25 19:02:53 +01:00
zu
zxcvbnm
zy
Reference in a new issue Copy permalink