It's simpler to just rely on what Appveyor already provides in its system
images. Appveyor doesn't provide a 32-bit msys2 build, but AFAIK, anyone
needing that can compile it themselves.
Avoid listing gcc-g++ in the Cygwin setup commands because it apparently
breaks the Cygwin toolchain (i.e. missing stddef.h error):
https://ci.appveyor.com/project/rprichard/winpty/builds/19875792
For unmodified Home/End, winpty instead sends WM_KEYDOWN / WM_KEYUP
messages to the console window so that the console can decide what escape
to use based on the VT terminal "alternate mode".
Fixes https://github.com/rprichard/winpty/issues/114
The console must decide whether characters are half-vs-full width, and it
seems to make poorer decisions with fonts that are atypically small. The
console properties dialog doesn't allow fonts smaller than 5px.
For example, (U+2026 HORIZONTAL ELLIPSIS) is half-width in Lucida Console
and Consolas, but with Lucida Console, 2px or 4px height, the console
thinks it's full-width.
Disallowing smaller fonts will force winpty to use larger windows, which
makes it more likely to hit the maximum window size constraint.
See https://github.com/Microsoft/vscode/issues/19665.
Also, for efficieny in direct mode, only output the lines that have
changed, rather than reprinting all of the lines after the first changed
line.
Fixes https://github.com/rprichard/winpty/issues/112
* Respect the result of VkKeyScan when it returns multiple modifiers. I
*think* the old if-else behavior was a typo?
* Refactor the code to restrict the scope of the Alt-implies-NUL behavior.
On my US keyboard, if I press either Alt-P or Alt-Ctrl-P, the console
reports a VirtualKey of 'P', and a NUL codepoint for KeyUp. For KeyDown,
though, Alt-P reports a 'P' codepoint, but Alt-Ctrl-P reports a NUL
codepoint. winpty previously implemented this logic in appendKeyPress, but
now it's factored out.
If the terminal sends us U+20AC (EURO SIGN), VkKeyScan decides that it must
have been typed using both Ctrl and Alt. (Pressing Ctrl-LeftAlt-E on my US
keyboard produces a Euro, as does RightAlt-E; AltGr/RightAlt seems to imply
Ctrl.) If the Alt keypress only comes from VkKeyScan, then continue using
the proper codepoint.
* Avoid changing the VT/reencoding behavior. In appendUtf8Char, pass the
unadjusted codepoint and Alt-escape to appendKeyPress, which will pass it
to reencodeEscapedKeyPress if the console is using VT input.
Fixes https://github.com/rprichard/winpty/issues/109
(MinGW-w64 works already -- only the old MinGW toolchain had trouble.)
* We need to build the test case with -std=g++11 to provide vsnprintf,
even though vsnprintf is in C99 and is provided by both MSVC and
MinGW-w64.
* The old MinGW provides a non-conforming swprintf.
* Remove the "version suffix" and BUILD_INFO.txt mechanisms, which I
believe no one uses except winpty itself. Instead, a suffix can be
added in the VERSION.txt file.
* Instead of passing the version and commit info as a preprocessor macro
when building every C++ file, write the info into a GenVersion.h
header that is only included by WinptyVersion.cc.
* Instead of writing a BUILD_INFO.txt in ship.py, pass COMMIT_HASH=<hash>
to make.
These changes accomplish two things:
* People who build a tag from source won't see a "<ver>-dev" suffix
anymore.
* Changing the version or the commit will correctly rebuild the version
object files (and only those object files). It will also relink every
binary.
Fixes https://github.com/rprichard/winpty/issues/72
These flags are used with WSL (Bash on Windows) and are commonly used.
(e.g. a pager status bar, man pages, etc.)
The most difficult part of this commit is figuring out when Windows
respects the flags versus ignores them. Apparently it deliberately
ignores them for backwards-compatibility with some programs.
If the terminal is placed in an alternate mode using DECCKM, then we
need to generate different input escape sequences for WSL (and other
programs using ENABLE_VIRTUAL_TERMINAL_INPUT). AFAIK, there is no way
for winpty to detect whether an alternate mode is enabled, but it only
seems to affect a small number of keys, so send those keys as window
messages.
We don't send *all* keys as window messages, because the console may try
to interpret some of them. It doesn't interpret the arrow keys and
Home/End, AFAICT, and those seem to be the only keys affected by DECCKM.
(The console's line-input mode *does* care about these navigation keys,
but in that case, WriteConsoleInput and window messages work equally well.)
DECCKM only seems to affect the keys when there is no modifier key.
I believe that by using SendMessage, winpty-agent will block until the
keys are appended to the console input buffer. I'm not sure how to verify
it. If this *weren't* the case, there could be a danger of key input
being transposed. It seems unlikely to be an issue.
Fixes https://github.com/rprichard/winpty/issues/90
