I'm using the Windows Terminal (Preview) on the Insider 19013 build, but that shouldn't have much effect on Powershell or PSReadLine I wouldn't think since Powershell is updated separately from the OS for the most part. This is 100% reproducible by running Set-PSReadLineOption -EditMode Emacs but doesn't appear to occur if I change the mode to vi. I noticed that in vi mode it uses the default Powershell completion of selecting the first Get- result which is Get-Acl, but in Emacs mode it offers to show all options (y/n) and selecting y fails.
This is full screen. It reports -59 as the overflow/underflow which I'm guessing is due to PSReadLine trying to mangle output to fit into the current buffers and paginate rather than letting Powershell handle that?
This is a non-maximized window, and reports -181 as the overflow/underflow of the buffer size/cursor position.
Steps to reproduce or exception report
-----------------------------------------------------------------------
Last 87 Keys:
g e t - s e r v i c e Space * s s h * Enter
l s Enter
g e t Tab Tab y - Tab Tab y Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace UpArrow UpArrow Tab DownArrow DownArrow DownArrow DownArrow Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace Backspace g e t - Tab Tab n Tab Tab y
Exception:
System.ArgumentOutOfRangeException: The value must be greater than or equal to zero and less than the console's buffer size in that dimension.
Parameter name: top
Actual value was -59.
at System.Console.SetCursorPosition(Int32 left, Int32 top)
at Microsoft.PowerShell.PSConsoleReadLine.Menu.EnsureMenuAndInputIsVisible(IConsole console, Int32 tooltipLineCount)
at Microsoft.PowerShell.PSConsoleReadLine.Menu.DrawMenu(Menu previousMenu)
at Microsoft.PowerShell.PSConsoleReadLine.PossibleCompletionsImpl(CommandCompletion completions, Boolean menuSelect)
at Microsoft.PowerShell.PSConsoleReadLine.CompleteImpl(Boolean menuSelect)
at Microsoft.PowerShell.PSConsoleReadLine.ProcessOneKey(ConsoleKeyInfo key, Dictionary`2 dispatchTable, Boolean ignoreIfNoAction, Object arg)
at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()
at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics)
-----------------------------------------------------------------------
I'm using the Windows Terminal (Preview) on the Insider 19013 build, but that shouldn't have much effect on Powershell or PSReadLine I wouldn't think since Powershell is updated separately from the OS for the most part. This is 100% reproducible by running
Set-PSReadLineOption -EditMode Emacs
but doesn't appear to occur if I change the mode tovi
. I noticed that invi
mode it uses the default Powershell completion of selecting the firstGet-
result which isGet-Acl
, but in Emacs mode it offers to show all options (y/n) and selectingy
fails.Environment data
PS version: 5.1.19018.1 PSReadline version: 2.0.0-beta2 os: 10.0.19018.1 (WinBuild.160101.0800) PS file version: 10.0.19018.1 (WinBuild.160101.0800) HostName: ConsoleHost (Windows Terminal) BufferWidth: 209 BufferHeight: 47
This is full screen. It reports -59 as the overflow/underflow which I'm guessing is due to PSReadLine trying to mangle output to fit into the current buffers and paginate rather than letting Powershell handle that?
PS version: 5.1.19018.1 PSReadline version: 2.0.0-beta2 os: 10.0.19018.1 (WinBuild.160101.0800) PS file version: 10.0.19018.1 (WinBuild.160101.0800) HostName: ConsoleHost (Windows Terminal) BufferWidth: 120 BufferHeight: 28
This is a non-maximized window, and reports -181 as the overflow/underflow of the buffer size/cursor position.
Steps to reproduce or exception report