1df3182865
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. |
||
|---|---|---|
| .. | ||
| bcx.cmd | ||
| bcz.cmd | ||
| bx.cmd | ||
| bx.ps1 | ||
| bz.cmd | ||
| ConsoleTypes.natvis | ||
| echokey.cmd | ||
| Generate-CodepointWidthsFromUCD.ps1 | ||
| GenerateAppxFromManifest.ps1 | ||
| GenerateHeaderForJson.ps1 | ||
| Get-OSSConhostLog.ps1 | ||
| openbash.cmd | ||
| opencon.cmd | ||
| OpenConsole.psm1 | ||
| openps.cmd | ||
| openvt.cmd | ||
| packages.config | ||
| razzle.cmd | ||
| README.md | ||
| runformat.cmd | ||
| runft.cmd | ||
| runuia.cmd | ||
| runut.cmd | ||
| testcon.cmd | ||
| tests.xml | ||
| vso_ut.cmd | ||
| WindbgExtension.js | ||
OpenConsole Tools
These are a collection of tools and scripts to make your life building the OpenConsole project easier. Many of them are designed to be functional clones of tools that we used to use when developing inside the Windows build system.
Razzle
This is a script that quickly sets up your environment variables so that these tools can run easily. It's named after another script used by Windows developers to similar effect.
- It adds msbuild to your path.
- It adds the tools directory to your path as well, so all these scripts are easily available.
- It executes
\tools\.razzlerc.cmdto add any other personal configuration to your environment as well, or creates one if it doesn't exist. - It sets up the default build configuration to be 'Debug'. If you'd like to
manually specify a build configuration, pass the parameter
dbgfor Debug, andrelfor Release.
bcz
bcz can quick be used to clean and build the project. By default, it builds
the %DEFAULT_CONFIGURATION% configuration, which is Debug if you use razzle.cmd.
bcz dbgcan be used to manually build the Debug configuration.bcz relcan be used to manually build the Release configuration.
opencon (and openbash, openps)
opencon can be used to launch the last built OpenConsole binary. If given an
argument, it will try and run that program in the launched window. Otherwise it
will default to cmd.exe.
openbash is similar, it immediately launches bash.exe (the Windows Subsystem
for Linux entrypoint) in your ~ directory.
Likewise, openps launches powershell.
runformat
runformat will format the c++ code to match our coding style.
testcon, runut, runft
runut will automatically run all of the unit tests through TAEF. runft will
run the feature tests, and testcon runs all of them. They'll pass any
arguments through to TAEF, so you can more finely control the testing.
A recommended workflow is the following command:
bcz dbg && runut /name:*<name of test>*
Where <name of test> is the name of the test testing the relevant feature area
you're working on. For example, if I was working on the VT Mouse input support,
I would use MouseInputTest as that string, to isolate the mouse input tests.
If you'd like to run all the tests, just ignore the /name param:
bcz dbg && runut
To make sure your code is ready for a pull request, run the build, then launch the built console, then run the tests in it. The built console will inherit all of the razzle environment, so you can immediately start using the macros:
bczopencontestcon(in the new console window)runformat
If they all come out green, then you're ready for a pull request!