fix: prompt glitch when resizing with cursor in a multiline command #898
Conversation
blindFS
force-pushed
the
prompt_start_row
branch
from
3c92c73 to
cee245d
Compare
|
Thanks |
# Description This updates to the latest reedline 405299b to include nushell/reedline#898 for dogfooding. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
| self.prompt_height = lines.prompt_lines_with_wrap(screen_width) + 1; | ||
| let lines_before_cursor = lines.required_lines(screen_width, true, None); | ||
|
|
||
| // Handle resize for multi line prompt | ||
| // Calibrate prompt start position for multi-line prompt/content before cursor. Check issue #841/#848/#930 | ||
| if self.just_resized { | ||
| self.prompt_start_row = self.prompt_start_row.saturating_sub( | ||
| (lines.prompt_str_left.matches('\n').count() | ||
| + lines.prompt_indicator.matches('\n').count()) as u16, | ||
| ); | ||
| self.prompt_start_row = self | ||
| .prompt_start_row | ||
| .saturating_sub(lines_before_cursor - 1); | ||
| self.just_resized = false; | ||
| } | ||
|
|
||
| // Lines and distance parameters | ||
| let remaining_lines = self.remaining_lines(); | ||
| let required_lines = lines.required_lines(screen_width, menu); | ||
| let required_lines = lines.required_lines(screen_width, false, menu); |
There was a problem hiding this comment.
Line 217, 218, and 230 share quite a few common computations that hold potential for improving responsiveness.
|
I'm not sure whether it is with this PR or not, but I've seen the resizing Windows Terminal to the right works but resizing to the left eats up one line per resize. Here's a quick gif. |
|
@fdncred Seems different terminal apps behave slightly differently on wrapping texts, I can't reproduce it on my machine. I'd like to know some details:
|
I'm not surprised. I haven't tested this on Linux or MacOS yet.
Yes, and sometimes more than one line at a time. I just had it jump half the width of the screen while expanding from the right side more to the right. Dragging the right boundary towards the left just makes text wrap and doesn't have the same effect.
It could. My render_right_prompt_on_last_line is set to false. I use the oh-my.nu script in nu_scripts. This is my prompt configuration in config.nu. # prompt
use modules\prompt\oh-my.nu git_prompt
$env.PROMPT_COMMAND = {|| (git_prompt).left_prompt }
$env.PROMPT_COMMAND_RIGHT = {|| (git_prompt).right_prompt }
$env.PROMPT_INDICATOR = {|| if ($env.LAST_EXIT_CODE == 0) { $"(ansi green_bold)\n❯ (ansi reset)" } else { $"(ansi red_bold)\n❯ (ansi reset)" } }
$env.TRANSIENT_PROMPT_COMMAND = ""
$env.TRANSIENT_PROMPT_COMMAND_RIGHT = {|| (git_prompt).right_prompt }
$env.TRANSIENT_PROMPT_INDICATOR = {|| if ($env.LAST_EXIT_CODE == 0) { $"(ansi light_yellow_bold)❯ (ansi reset)" } else { $"(ansi light_red_bold)❯ (ansi reset)" } }
$env.PROMPT_MULTILINE_INDICATOR = {|| $"(ansi -e {fg: '#CB4B16'})(char -u '276f')(ansi -e {fg: '#CACA02'})(char -u '276f')(ansi -e {fg: '#4E9A06'})(char -u '276f')(ansi reset)(char space)" } |
|
According to my knowledge, It's more buggy when If the bug requires a non-empty right prompt text, it probably has nothing to do with this PR, not so sure. I mean theoretically, this is a follow-up fix for some edge cases if we persist how we handle prompt positioning while resizing:
This PR fixes some imprecise calculations of step 2. |
Fixes a bug overlooked in #841 (forgot that the
before_cursorstring could have newlines in it too).Before:
Screen.Recording.2025-03-26.at.8.46.50.PM.mov
After: stays in the same row.