The pipeline thread was returning before the `ReadKeyProcThread` had finished processing the dummy input.
This was occurring somewhat frequently when `ReadLine` was invoked multiple times in a row creating a race condition.
With these changes, the pipeline thread will wait for dummy input to be received, dequeue the key, and continue with normal cancellation logic.
Because .NET's . `Console.ReadKey()` is uncancellable, when a hosting
application cancels PSReadLine, it also has to send a key press to get
`ReadKey` to return. In this case, we want to ignore the key press (and
a user certainly would not be expecting it, as `ReadLine` has already
been canceled).
1. Preserve the saved current line and the history index while in a series of history commands.
So when switching between different history command, such as from `F8`/`Shift+F8` (`HistorySearchBackward` and `HistorySearchForward`) to `UpArrow`/`DownArrow` (recall history) or from `Ctrl+r`/`Ctrl+s` to `UpArrow`/`DownArrow`, the history command can continue to work as expected.
2. Clear the saved current line when we are out of a series of history commands.
So the saved line will not leak to another unrelated history search.
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
The method Keys.ShouldInsert was a misguided attempt to avoid inserting
keys where there is no binding but the key really doesn't make sense as
input.
Unfortunately it is just causing more pain and probably wasn't
addressing a serious problem, so I'm removing it.
Fix#798
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
conhost (Windows only) could change the font unexpectedly if the current font is a raster font and the code page changes to UTF8.
PSReadLine was switching to UTF8 output encoding to address some display issues with CJK,
This change skips the UTF8 output encoding change if it would cause conhost to change the font.
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.
I missed `Console.TreatControlCAsInput` when refactoring the port from
PowerShell/PowerShell - this isn't needed on Windows because it was
handled more directly via SetConsoleMode.
Fix#610
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
I was terribly inconsistent.
This is a breaking change, though unlikely to cause troubles.
The apis are mostly used in PowerShell scripts which is not
case sensitive.
The cmdlet name change is also mostly safe.
At any rate, this is version 2.0 and breaking changes should be OK.
A fix for vi mode broke placing the cursor after recalling commands from
history.
There was also a small inconcistency in placing the cursor in vi mode
when in command mode.
Fix#592
The reported bug doesn't repro because the call to GetPrompt in
Initialize is gone, but the issue could still pop up, e.g. during
completion, so I added a try/catch.
Fix#583
spaette