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
* The compiler doesn't like implicit conversions to bool.
(it emits a "performance warning")
* It also doesn't like an unused argument in an exception catch block.
GCC 5.1 added a -Wsuggest-override option that reports missing `override`
keywords, which I used to prepare this commit. I'm not turning the option
on yet, though, because my Cygwin environment is still using GCC 4.9.
Initially, some of this code omitted a space between a closing
double-quotes and a macro, which broke with C++11:
m_output.write(CSI"0m"CSI"1;1H"CSI"2J");
To make it work with C++11, it changed to:
m_output.write(CSI"0m" CSI"1;1H" CSI"2J");
Now I'm fully separating them:
m_output.write(CSI "0m" CSI "1;1H" CSI "2J");
I don't expect C++ to change again, breaking my code, but it seems prudent
to avoid that possibility.
I searched the codebase for matches using this Sublime/Perl regex:
^([^"'\n]*("([^\\"\n]|\\.)*"|'([^\\'\n]|\\.)*'))*[^"'\n]*(?<!^)(?<!\bL)(?<=[A-Za-z0-9_])("([^\\"\n]|\\.)*"|'([^\\'\n]|\\.)*')
It determines:
- whether the program has a console
- whether that console has a window
- whether that window is on the current window station
It's motivated by the IntelliJ clipboard/winpty bug.
