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
Added an input/output argument like IsHandleRedirected. There are four cases for console APIs:
Input is not redirected; input APIs are usable.
Output is not redirected; output APIs are usable.
At least one of input or output is not redirected; things like SetConsoleTitle are usable.
Both streams are redirected; we can't use any console APIs.
It's only used for the first scenario right now, but for completeness, the other cases are also handled.
Rewrote the custom key binding code to be more portable.
Some runtime checks are necessary because of impossible to reconcile
differences.
Some Win32 P/Invoke calls are still needed due to lack of information in
the ConsoleKeyInfo.
Some keys are currently not available on Linux due to a CLR bug, others
aren't available ever because terminals don't unique character sequences
for a given key press that might differ in just the Shift or Ctrl state.
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.
GetCurrentConsoleFontEx will fail when called inside Windows Server
containers, since container consoles do not have fonts -- they always
output VT100 streams. Ignore failures from this call so that PSReadLine
does not crash immediately when loaded inside a container.
Signed-off-by: John Starks <jostarks@microsoft.com>
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.
Menu completion would crash PowerShell when invoked from the end of the buffer.
The display also got messed up when the selected completion caused the line
length to exceed the buffer width and hence required wrapping.
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.
The strings shown for commands like Get-PSReadlineKeyHandler or
shown from functions WhatIsKey and ShowKeyBindings should now
match what you can use with Set-PSReadlineKeyHandler.
These strings will also omit +Shift in most cases because it
is usually clear from the character, e.g. the following are
equivalent but the former is preferred.
Ctrl+?
Ctrl+Shift+/
WhatIsKey prompts for a key and then shows what it is bound to.
ShowKeyBindings is like running Get-PSReadlineKeyBindings, but
does so without needing to run a command and preserves the current
input line.
Dan Thompson