- Adds a way to view help on alternate screen buffer for full help and uses a Pager from `Microsoft.PowerShell.Pager`.
- Implements dynamic help for parameters by showing it below the current command line like `MenuComplete`.
There are likely issues introduced by this PR,
but I'm merging for a new Beta so this code gets more testing.
* Introduce PSKeyInfo type alias
* Explicit conversions b/w ConsoleKeyInfo and PSKeyInfo
* Change tests to use actual ConsoleKeyInfo data
* Add fr-FR keyboard layout tests
* Add KeyInfo-ru-RU-windows.json (#839)
All impossible without Shift shortcuts labeled as "Investigate: true"
Alt+Spacebar tracked by windows itself
* Add KeyInfo for Polish (Programmers) layout on Windows and Linux (#870)
On Windows *Alt+Spacebar* is hijacked by Windows
On Linux any *Alt+F1-12* combination was not detected
This fixes some weird issues in WSL and some Linux terminals.
This also works around a Windows 1809 Console bug for the Ctrl+l binding
to clear the screen by using the same escape sequence that bash uses.
Fix#724
A recent PR disabled the display of tooltips, and there were
some problems with the menu display when the command line
was at the bottom of the buffer and scrolling was necessary.
Fix#763 and probably #765
The output encoding is set for CJK characters, so if that fails, it
would be nice to know, but it comes up often (redirected input,
legacy conhost) so we just ignore the exception.
Introduced a very minimal terminal emulator, enough to support the
colors used by default (ConsoleColor).
There could be some more error checking or just somehow ignoring unknown
escapes, but we'll see if this is sufficient for now.
Fix#596
Character ranges are probably sufficient for detecting which characters
need to be rendered in cells, so I removed the Win32 specific code that
used information about the font.
We also probably don't need to detect the code page - instead assume if
a wide character is to be rendered, that the correct font is in use,
otherwise the command line looks like garbage anyway, so if we're wrong,
there is a low likelihood of it mattering.
When stdin or stdout is redirected, PSReadLine fails with an error message that isn't very helpful.
As long as redirected stdin/out is not supported, we'll just throw an exception and let PowerShell
fall back on calling Console.ReadLine or whatever it normally does when PSConsoleHostReadline throws.
The mock of the console api is complete enough so unit tests run.
It's still a hack, not exactly factored nicely to support other hosts,
but at least some of the real interface is in one place, not scattered
about.
To get the unit tests passing in VS2015, and to help w/ possible future hosts,
I've moved most of the console api usage to a class, which is then mocked
in the unit tests.
The host check in the .psd1 only allows you to specify one host. To allow
other hosts to use PSReadline, but still try to give a helpful error to
people trying to use PSReadline in other, non-console hosts (like the ISE),
we instead do a runtime check using IModuleAssemblyInitializer, wherein we
check to see if the current process has a non-hidden console window, and
emit an error if not.
Dongbo Wang