nushell / reedline

A feature-rich line editor - powering Nushell
https://docs.rs/reedline/
MIT License
547 stars 152 forks source link

Cycling between maximize and minimize reprints the prompt on Windows #620

Open naiyerasif opened 2 years ago

naiyerasif commented 2 years ago

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 commented 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.

sholderbach commented 2 years ago

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

naiyerasif commented 2 years ago

It reprints the entire prompt again on a different line.

benthillerkus commented 2 years ago

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

scientiac commented 2 years ago

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 commented 2 years ago

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

Zoybean commented 1 year ago

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

image

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 commented 1 year ago

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

Zoybean commented 1 year ago

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.

sholderbach commented 1 year ago

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

Zoybean commented 1 year ago

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]

~
>