Open naiyerasif opened 2 years ago
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.
Reprint as in flickering and updating information or reprint on a different line or corrupting the content?
It reprints the entire prompt again on a different line.
For me resizing the window in any way is enough. I can also see this behaviour in alacritty / tmux + alacritty on Linux
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.
Same issue here on all terminals I've tried (Linux)
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:
B
new blank lines, then the new prompt will be redrawn exactly B
lines lower than the old promptN
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:
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
Need to check which pathologies of this issue persist on the reedline side.
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.
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.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.
Thanks for the testing @Zoybean, so it seems we still have a problem where previous program output gets overwritten by prompt/buffer components.
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]
~
>
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:
On Windows 10:
Expected behavior
The prompt should not get reprinted in this case.
Screenshots
No response
Configuration
Additional context
No response