The current cursor is off after window resizing

[RoadToDream]

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

N/A

Environment data

PS Version: 7.3.3
PS HostName: ConsoleHost
PSReadLine Version: 2.2.6
PSReadLine EditMode: Windows
OS: 10.0.22621.1 (WinBuild.160101.0800)
BufferWidth: 120
BufferHeight: 9001

Steps to reproduce

Steps to reproduce

1. Open PowerShell from any folder such that primary prompt is longer than one line.
2. Enter any command and click enter.
3. Maximize PowerShell window so primary prompt is arranged within one line.
4. Cursor will be off-position and overwrite my primary prompt.
5. This issue will not appear when PSReadLine is disabled

Video attached below:
With PSReadLine enabled:

Recording.2023-03-27.095155.mp4

Without PSReadLine enabled:

Recording.2023-03-27.095536.mp4

Similar issue has also been reported in #1269

Expected behavior

PS C:\Program Files\Windows Defender Advanced Threat Protection\Classification> ls

Actual behavior

PS C:\Program FilelsWindows Defender Advanced Threat Protection\Classification>

Please note the input 'ls' replaces my primary prompt.

[StevenBucher98]

This is a known issue, its tricky because PSReadLine does not get constant updates on Window Change events in a cross platform way. Marking as bug and will explore possible solutions

[RoadToDream]

This is a known issue, its tricky because PSReadLine does not get constant updates on Window Change events in a cross platform way. Marking as bug and will explore possible solutions

Hi Steven Bucher (@StevenBucher98) , thank you for confirming the issue. Looking forward a fix in the future.

[lulu-loopp]

I dug into this while working on a terminal, and I think the mechanism is worth writing down, because part of it has a small fix and part of it does not.

Where the column comes from. After a buffer width change, RecomputeInitialCoords recovers the column of the edit anchor with one statement, in both of its branches (Render.cs#L1261, Render.cs#L1297):

// Recompute X from the buffer width:
_initialX %= _console.BufferWidth;

_initialX is the anchor's column at the width in effect before the resize, so it already is the prompt's cell width reduced modulo that width. Reducing it again keeps the remainder and throws away the quotient, and the quotient is the only record of how many physical lines the prompt spans. Once it is gone, widening cannot put the anchor back.

The numbers in this report fit that exactly. The prompt

PS C:\Program Files\Windows Defender Advanced Threat Protection\Classification>

is 79 cells including the trailing space, and the reported corruption is

PS C:\Program FilelsWindows Defender Advanced Threat Protection\Classification>

which puts ls at column 18. 79 % 61 == 18, i.e. the window was about 61 columns wide before it was maximized, the prompt occupied two physical lines there, and after maximizing PSReadLine still believed the anchor was at column 18.

Minimal repro (measured on Windows PowerShell 5.1 with the inbox 2.0.0, and on pwsh 7.6.4 with 2.4.5; both through a ConPTY pseudoconsole, which is the path conhost and Windows Terminal use):

# 36 cells wide
function prompt { 'PSRL-ANCHOR-PROBE-0123456789012345> ' }

1. Size the window to 100 columns, press Enter for a fresh prompt, type some text, and do not press Enter.
2. Narrow the window to 35 columns -- narrower than the prompt -- and type one character. This still renders correctly.
3. Widen the window back to 100 columns and type one more character. The input is now redrawn from column 1, on top of the prompt, and the text drawn at the narrow width is left on screen.

Reading back the CUP sequences, the anchor is at column 1 after step 3 where it should be at column 36; the same is true for 100 -> 20 -> 100, 100 -> 10 -> 100, and 100 -> 35 -> 60 -> 25 -> 100. 2.0.0 and 2.4.5 behave identically, which is expected: the statement dates to 2017 (b2979d1) and #3074 carried it forward unchanged.

PR #5191 keeps the prompt's cell width -- a quantity that does not depend on the buffer width -- and derives _initialX from it on every width change. That fixes every case above: narrowing is unchanged and widening restores the anchor, including across several successive resizes.

What it does not fix, and why. The steps in this issue start with the prompt already wrapped, before ReadLine is entered. In that situation the only thing PSReadLine can observe is CursorLeft, which is already the reduced value (18 in the example above), so the prompt's true width of 79 is not recoverable without re-invoking the user's prompt function or reading the screen buffer back. So this issue's exact repro will still misbehave after that PR; what changes is that resizing during an edit -- the far more frequent way people hit this -- no longer corrupts the line. I did not want to fold a prompt re-invocation into a small fix without maintainer input, but I am happy to follow up on that half if there is a preferred approach.