bck-i-search (Ctrl-R) quits accepting input when it finds a very long command

[Narvey]

When I press Ctrl-R, I keep having this gigantic line I once pasted in pop up in the history and clobber the bck-i-search. All the keyboard input then goes at the end of the giant command and so I can't finish typing into bck-i-search the rest of what I wanted to search for. Worse still, Ctrl-C does not get me out, and Ctrl-D just puts ^D on the end of the command. Up arrow does get me out, but causes the below exception.

Environment data

PS version: 5.1.18362.145
PSReadline version: 2.0.0-beta2
os: 10.0.18362.1 (WinBuild.160101.0800)
PS file version: 10.0.18362.1 (WinBuild.160101.0800)
BufferWidth: 120
BufferHeight: 3000

Steps to reproduce or exception report

Last 4 Keys:
Ctrl+r b a UpArrow

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 -4965.
at System.Console.SetCursorPosition(Int32 left, Int32 top)
at Microsoft.PowerShell.PSConsoleReadLine.ReallyRender(RenderData renderData, String defaultColor)
at Microsoft.PowerShell.PSConsoleReadLine.ForceRender()
at Microsoft.PowerShell.PSConsoleReadLine.HistoryRecall(Int32 direction)
at Microsoft.PowerShell.PSConsoleReadLine.PreviousHistory(Nullable1 key, Object arg) at Microsoft.PowerShell.PSConsoleReadLine.ProcessOneKey(ConsoleKeyInfo key, Dictionary2 dispatchTable, Boolean ignoreIfNoAction, Object arg)
at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()
at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics)

---

[msftrncs]

@Narvey, you should give PSReadline 2.0.0-beta5 a try, from PowerShellGallery. I cannot say that it will help or entirely eliminate the issue, but a better error report may be possible, knowing how the latest version handles.

[daxian-dbw]

The ArgumentOutOfRangeException exception should be fixed in 2.0.0-beta5, but I'm curious about the clobber the bck-i-search part. Like @msftrncs suggested, can you please try 2.0.0-beta5 and if that doesn't work too, please provide a repro.

[daxian-dbw]

@Narvey I will close this issue. If you run into the same issue with 2.0.0-beta5, please re-open the issue and provide a repro. Thanks.

[msftrncs]

@daxian-dbw, I just had this issue occur on me, when using the CTRL-R search in a 7.0.0-preview5 session in VS Code's terminal, when the resulting found history item was longer than the terminal buffer (which is only a few lines (19). Then things became really goofy, because the search prompt remained on the screen, but keypresses edited the command that was pulled up, even after pressing escape I could not close the search using escape. instead I had to press CTRL-R or CTRL-S to get the input going back to the right place, without any exceptions occurring, and then press escape.

Edit: It was a PowerShell Integrated Console, incase that becomes important.

[daxian-dbw]

Thanks @msftrncs. Re-open this issue.

[msftrncs]

To produce a good reproduction of this issue

PS version: 7.0.0-preview.5
PSReadline version: 2.0.0-beta5
os: 10.0.19008.1 (WinBuild.160101.0800)
PS file version: 7.0.0.0
HostName: Visual Studio Code Host
BufferWidth: 174
BufferHeight: 10

Reference code (you will probably not be able to paste this in to VS Code's terminal)

(
$ZQZV # because its unique
# 2
# 3
# 4
# 5
# 6
# 7
# 8
# 9
# 10
)

After entering the above as a command and posting it to history, press CTRL-R and type ZQ, the searched for text will scroll off the top of the buffer and an exception will occur.

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 'top')
Actual value was -2.
   at System.Console.SetCursorPosition(Int32 left, Int32 top)
   at Microsoft.PowerShell.Internal.VirtualTerminal.SetCursorPosition(Int32 left, Int32 top)
   at Microsoft.PowerShell.PSConsoleReadLine.ReallyRender(RenderData renderData, String defaultColor)
   at Microsoft.PowerShell.PSConsoleReadLine.ForceRender()
   at Microsoft.PowerShell.PSConsoleReadLine.Render()
   at Microsoft.PowerShell.PSConsoleReadLine.UpdateFromHistory(HistoryMoveCursor moveCursor)
   at Microsoft.PowerShell.PSConsoleReadLine.UpdateHistoryDuringInteractiveSearch(String toMatch, Int32 direction, Int32& searchFromPoint)
   at Microsoft.PowerShell.PSConsoleReadLine.InteractiveHistorySearchLoop(Int32 direction)
   at Microsoft.PowerShell.PSConsoleReadLine.InteractiveHistorySearch(Int32 direction)
   at Microsoft.PowerShell.PSConsoleReadLine.ReverseSearchHistory(Nullable`1 key, Object arg)
   at Microsoft.PowerShell.PSConsoleReadLine.ProcessOneKey(PSKeyInfo key, Dictionary`2 dispatchTable, Boolean ignoreIfNoAction, Object arg)
   at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()
   at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken)

Any less than the # 10 line wouldn't do it... the text that gets selected has to be more than one line off the screen, probably because the exception occurs when the bck-i-search: z_ appears. However, with a 1 line shorter version, the an exception happens when you try to move off this particular item, probably because the selection, which was on the screen initially when it was highlighted, is no longer when it goes to clear it.

[msftrncs]

Its purposely trying to put the cursor where the text was found, but that location has scrolled off the screen.

[msftrncs]

The exception when the search is cleared (when it hadn't first asserted an exception) is different:

Exception

System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at System.Text.StringBuilder.get_Chars(Int32 index)
   at Microsoft.PowerShell.PSConsoleReadLine.ConvertOffsetToPoint(Int32 offset)
   at Microsoft.PowerShell.PSConsoleReadLine.RecomputeInitialCoords()
   at Microsoft.PowerShell.PSConsoleReadLine.ReallyRender(RenderData renderData, String defaultColor)
   at Microsoft.PowerShell.PSConsoleReadLine.ForceRender()
   at Microsoft.PowerShell.PSConsoleReadLine.Render()
   at Microsoft.PowerShell.PSConsoleReadLine.ClearStatusMessage(Boolean render)
   at Microsoft.PowerShell.PSConsoleReadLine.InteractiveHistorySearch(Int32 direction)
   at Microsoft.PowerShell.PSConsoleReadLine.ReverseSearchHistory(Nullable`1 key, Object arg)
   at Microsoft.PowerShell.PSConsoleReadLine.ProcessOneKey(PSKeyInfo key, Dictionary`2 dispatchTable, Boolean ignoreIfNoAction, Object arg)
   at Microsoft.PowerShell.PSConsoleReadLine.InputLoop()
   at Microsoft.PowerShell.PSConsoleReadLine.ReadLine(Runspace runspace, EngineIntrinsics engineIntrinsics, CancellationToken cancellationToken)

[msftrncs]

In the case of this second exception, the point.Y value is -1, and its under neither of the two cases in the comment at

PSReadLine/PSReadLine/Render.cs

Lines 796 to 810 in 664b168

	// This could only happen in two cases:
	//
	// 1. when you are adding characters to the first line in the buffer (top = 0) to make the logical line
	// wrap to one extra physical line. This would cause the buffer to scroll up and push the line being
	// edited up-off the buffer.
	// 2. when you are deleting characters backwards from the first line in the buffer without changing the
	// number of physical lines (either editing the same logical line or causing the current logical line
	// to merge in the previous but still span to the current physical line). The cursor is supposed to
	// appear in the previous line (which is off the buffer).
	//
	// In these case, we move the cursor to the upper-left-most position of the window, where it's closest to
	// the previous editing position, and update '_current' appropriately.
	_current += (bufferWidth - point.X);
	point.X = point.Y = 0;

So the _current value gets set to some ridiculous point way past the end of the command buffer. In this case, the entire command is shorter than the bufferWidth.

[msftrncs]

Experimenting with a solution for this, seems the code causing the exception when right-click pasting in Windows Terminal might be closely related.

[adityapatwardhan]

I am also reproing this on RC1