Cycling between maximize and minimize reprints the prompt on Windows

[naiyerasif]

Describe the bug

I updated nu to v0.60.0 on two Windows machines today. One of them runs Windows 11 Pro and other runs Windows 10 Enterprise. nu reprints the prompt when I maximize and minimize window.

On Windows 11 Pro, the reprint of prompt happens when I maximize and minimize using title bar controls. On Windows 10 Enterprise, this happens both when I use the title bar controls and when I click on taskbar icon to switch between the window of another program and nu.

Configuration check 1

On both the machines, Windows Terminal was set as the default terminal application and nu was configured to open with the Windows Terminal. To verify that the same thing happens on Windows Console Host, I set Windows Console Host as the default terminal application and launched nu.exe. I observed the same issue in this case too.

Configuration check 2

I also tried to check if this was something specifically related to the prompt configuration. I switched from default to starship and the same thing kept happening even with starship.

How to reproduce

On Windows 10 and 11:

1. Launch nu.exe and minimize and maximize it a couple of times.
2. You should be able to see prompt getting reprinted on each maximize minimize cycle.

On Windows 10:

1. Try switching between previously opened window of another program and nu.exe by clicking on nu.exe icon on taskbar.
2. You should again be able to see prompt getting reprinted on each maximize minimize cycle.

Expected behavior

The prompt should not get reprinted in this case.

Screenshots

No response

Configuration

key	value
version	0.60.0
short_commit	74af31a4
commit_hash	74af31a42ff4feb8d5d9897c0d99c7434678a315
commit_date	2022-03-22 19:07:11 +00:00
build_os	windows-x86_64
rust_version	rustc 1.59.0 (9d1b2106e 2022-02-23)
rust_channel	stable-x86_64-pc-windows-msvc
cargo_version	cargo 1.59.0 (49d8809dc 2022-02-10)
pkg_version	0.60.0
build_time	2022-03-22 19:26:49 +00:00
build_rust_channel	release
features	dataframe, default, trash, which, zip
installed_plugins

Additional context

No response

[fdncred]

almost the same behavior for me but it's not minimize and maximize. for me, it's restore (the middle button between minimize and maximize) and maximize. It's most noticeable if your prompt is the top line and you start off in a non-maximized window.

[sholderbach]

Reprint as in flickering and updating information or reprint on a different line or corrupting the content?

[naiyerasif]

It reprints the entire prompt again on a different line.

[benthillerkus]

For me resizing the window in any way is enough. I can also see this behaviour in alacritty / tmux + alacritty on Linux

[scientiac]

Yeah on resizing the prompt reprints to another line, on alacritty, kitty as well as when I enable and disable keyboard on termux on android.

[VarLad]

Same issue here on all terminals I've tried (Linux)

[Zoybean]

I was also able to reproduce this on linux (Mint).

I did some experimentation and identified 2 cases that I can reproduce consistently, and 2 cases that consistently do nothing. In each case, resize the screen and then type a key. The cases depend on whether you are increasing or decreasing the size, and how many blank lines were added or nonblank lines were removed by the resize.

The following cases exhibit the bug:

1. resizing the window to be taller, leaving empty space below the cursor position
   • In this case, when resizing the window adds B new blank lines, then the new prompt will be redrawn exactly B lines lower than the old prompt
2. resizing the window to be shorter, causing some number of lines to move off-screen by the resize (e.g. when the cursor was already at the bottom of the screen)
   • in this case, when resizing the window pushes the previous contents (and therefore the previous prompt) up by N lines, the new prompt will be drawn min(N, H-2) lines lower than the old prompt, where H is the height of the prompt. I'm curious where that 2 comes from, but it effectively means that 2-line prompts are unaffected by the redraw in this case, and single-line prompts (e.g. a simple > ) shift gradually up, rather than down. I suspect that any tests for this case may have used a 2-line prompt (e.g. {path}\n>

The following cases do not exhibit the bug:

1. resizing the window to be smaller, but leaving empty space below the cursor (i.e. reducing the amount of empty space after the cursor line, but not pushing any nonblank lines of output off-screen). The inverse of case 1 above.
2. resizing the window to be taller, but not creating any empty space below the cursor (i.e. only pulling new lines of history on-screen). The inverse of case 2 above.

The table and screenshot below are from repeating case 2 above (shrinking the terminal by various amounts), using a novel prompt to make it easier to see what is happening.

Noting that the prompt is 8 lines high, here's the table of resizes done and the results. This is consistent with the formula given above for case 2.

lines hidden by resize	lines of old prompt left visible
1	1
3	3
5	5
6	6
7	6
9	6

Note that the table was accurate to the lines displayed while I was testing, but after maximising again to take the screenshot I noticed that the first few prompts and some of the earlier command output had been overwritten while they were off-screen.

Update: Confirmed that this behaviour is the same on windows (WSL). In native windows CMD, the behaviour is a little different

[sholderbach]

Need to check which pathologies of this issue persist on the reedline side.

[Zoybean]

Tested today in nushell, after grabbing the latest master with the fixes for nushell/nushell#9166. Here's a summary of my findings. In both cases below, I'm using P to represent the number of lines in the prompt.

• if you increase terminal size by N lines (and then press a key), then N-1 new blank lines are added at the bottom of the screen, and then the prompt lines are added under those, overall pushing the content up by P-1 lines.
• if you reduce the terminal size by R lines (and then press a key), then the prompt will be reprinted below the previous prompt. If we let B be the number of blank lines below the cursor line, then the prompt will be max(0, min(R-B,P-1)) lines below the last prompt, pushing the content up by the same amount.
  • This means that with a single-line prompt, this symptom isn't observed at all.

[sholderbach]

Thanks for the testing @Zoybean, so it seems we still have a problem where previous program output gets overwritten by prompt/buffer components.

[Zoybean]

Thanks for the testing @Zoybean, so it seems we still have a problem where previous program output gets overwritten by prompt/buffer components.

I should clarify that since the aforementioned update, previous program output is never being overwritten. In each case in my summary above, program output is pushed up, but it is all still visible in scrollback. The only text that is overwritten now, is part of the prompt itself, in the second case above.

as an example, before resize:

ok at 21:02:19 [823ms]

~
> ls
╭───┬─────────────────┬─────────┬────────┬──────────────╮
│ # │      name       │  type   │  size  │   modified   │
├───┼─────────────────┼─────────┼────────┼──────────────┤
│ 0 │ My_User_Account │ symlink │   17 B │ 2 years ago  │
│ 1 │ downloads       │ dir     │ 4.1 KB │ 2 years ago  │
│ 2 │ repos           │ dir     │ 4.1 KB │ 4 months ago │
│ 3 │ test            │ dir     │ 4.1 KB │ a week ago   │
╰───┴─────────────────┴─────────┴────────┴──────────────╯
ok at 21:02:21 [17ms]

~
>

after shrinking terminal:

ok at 21:02:19 [823ms]

~
> ls
╭───┬─────────────────┬─────────┬────────┬──────────────╮
│ # │      name       │  type   │  size  │   modified   │
├───┼─────────────────┼─────────┼────────┼──────────────┤
│ 0 │ My_User_Account │ symlink │   17 B │ 2 years ago  │
│ 1 │ downloads       │ dir     │ 4.1 KB │ 2 years ago  │
│ 2 │ repos           │ dir     │ 4.1 KB │ 4 months ago │
│ 3 │ test            │ dir     │ 4.1 KB │ a week ago   │
╰───┴─────────────────┴─────────┴────────┴──────────────╯
ok at 21:02:21 [17ms]

~
ok at 21:02:21 [17ms]

~
>