Display problem after Windows Terminal window scrolls with [console]::BufferHeight set larger than [console]::WindowHeight

[mrenton999]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues, especially the pinned issues.

Exception report

N/A

Screenshot

Screenshot showing problem

Environment data

PS Version: 7.5.2
PS HostName: ConsoleHost
PSReadLine Version: 2.3.6
PSReadLine EditMode: Windows
OS: 10.0.26100.1 (WinBuild.160101.0800)
BufferWidth: 180
BufferHeight: 9001

Steps to reproduce

Repeatedly expanding a function and running it...
Paste the function 'alb' into PS. 'alb' commands to run it.
Paste the edited function into PS again. Up-Arrow, Up-Arrow, Enter to run the latest line which runs the function,
(I know, I need to re-write the function to use 'switch', but that wouldn't affect this problem.)

Expected behavior

The first Up-Arrow to display the function. The second should display the previous command, but doesn't. Hit Enter and there are blank lines in the window which shouldn't be there.

Actual behavior

The above behavior is seen.

[daxian-dbw]

In the "Step to reproduce" section, can you please provide the scripts and the steps for me to run them to reproduce the issue?

[mrenton999]

It is the 'alb' function as seen in the screenshot...

function alb($x) {
  $f="C:\NEW\Albums.txt";
  if($x -eq '?') { 'alb = for unbought; alb c for unbought count; alb u for unsure; alb e to edit; alb w for who; alb ? for help; alb m to more; alb <CR> to type'; return }
  if($x -in ('*','=')) { sls -case '[A-Z]{4}|\=' $f|Select -expand Line; return }
  if($x -eq 'c') { alb =|sls '='|select -expand line|count; return }
  if($x -eq 'w') { sls -case '[A-Z]{4}' $f|Select -expand Line; return }
  if($x -eq 'u') { sls -case '[A-Z]{4}|[\d]{4}\?' $f|Select -expand Line; return }
  if($x -eq 'm') { more $f; return }
  if($x) { np $f } else { cat $f }
}

I see now that the first Up-Arrow displays the pasted function, and the second Up-Arrow actually does display the command scrolled to, on the "}" line ('alb u' in the screenshot above). Then hitting Enter shows about as many blank lines as it took to display the function before the output of the function. It seems to do this whether I use (R)click or ^V to paste, but only if the window has scrolled (it looks fine if the window hasn't scrolled up).

This unexpected behavior is also only seen if the Windows Terminal window has been scrolled. Looks fine in an unscrolled window, but has the blank lines problem in a scrolled window.

[daxian-dbw]

Paste the function 'alb' into PS. 'alb' commands to run it.
Paste the edited function into PS again. Up-Arrow, Up-Arrow, Enter to run the latest line which runs the function,

It's still unclear to me what the exact repro steps are. I don't have your Albums.txt file, so running alb will fail. I don't know if that will affect the repro. Can you provide a step-by-step repro instruction and maybe share a GIF to show it?

Below is the GIF from me trying to reproduce the issue based on what you said:

[mrenton999]

I tried it again with just any command which produces output (you don't have to run the pasted function)... and a different function.
Stand on Enter so window scrolls
Get-NetIPInterface
Paste the function (maybe you need to include the CR/LF at the end of last line).
Up-Arrow and it displays the function again
Up-Arrow and it displays the Get-NetIPInterface command over the last "}" of the function with blank lines and the cursor at the end of the blank lines but spaced over about 'Get-NetIPInterface'.length
Enter
And the output from Get-NetIPInterface is shown

[daxian-dbw]

Paste the function (maybe you need to include the CR/LF at the end of last line).

I think this is related to the other issue #4874 from you. Can you check your Windows Terminal settings in Settings -> Actions to see if Windows Terminal already has the Ctrl+v bound to its Paste action? If so, that maybe the cause. The Windows Terminal's paste action works the same as right click -- sending text to the shell character by character.

PowerShell (PSReadLine) has its own Ctrl+v key binding, which handles the pasting correctly. But if WT already has Ctrl+v bound, then PSReadLine can never handle that key pressing. You may want to delete the ctrl+v binding from WT and let PSReadLine handles it.

When PowerShell (PSReadLine) handles Ctrl+v, the ending CR/LF are not treated as Enter, but rather part of the copied text. I tried exactly the same and still cannot reproduce the issue. See the GIF below.