-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Right prompt issues with reflowing terminal #7491
Comments
Oh gosh, this is awkward 😅 This might not be a fish issue upon closer inspection. There is the very similar upstream issue where if you have a multi-line left prompt and a right prompt, then window resizing does this. Can demonstrate with: function fish_prompt
echo foo
echo bar
end
function fish_right_prompt
echo blah
end But this bug doesn't appear if the right prompt isn't displaying anything, so it doesn't apply to your issue. I'd love to get a fish maintainer's comments on this though, as I couldnt find the bug I described above in the open issues. I'll reopen the Tide issue and poke around on this. Sorry if I was mistaken in kicking this upstream 😅 |
Ok, yeah, this was a Tide issue (though caused by the upstream bug in my defense 😛). I was setting the right prompt display to a space when I wanted it to not display anything. Space counts as a character obviously, thus producing the bug. set -g _tide_fish_right_prompt_display ' ' Instead I'll set it to truly empty. set -g _tide_fish_right_prompt_display You'll still have this issue if anything is actually displaying in the right prompt, but if not it'll be fine. Feel free to close this issue. |
Thank you for the detailed explanation, it fixed this issue I'll keep it opened, but I'll change the title. As you said, it's an upstream bug so I'd prefer it to be fixed so it doesn't happen to others when they set up Tide or other right prompts. |
Does this help? #7404 It's in the latest master, so you could try that. |
@mqudsi I just compiled it from source, and the issue persists: ❯ fish --version
fish, version 3.1.2-1651-g9b3f4faa5 |
Yeah, this is the terminal reflowing, and because we have actual spaces between the left and right prompt it'll do weird things. The solution would be to make those spaces empty instead, but I'm not sure how that works. For the moment: Don't use a multiline prompt plus a right prompt in a terminal that will reflow (mostly iTerm and VTE). |
Okay, some news: 1. this also happens with bash, and with zsh, especially have a right prompt enabled. The VTE developers propose two things we could do:
Given how awful detecting terminals is (especially since VTE claims to be xterm), I'm going to go with the first and disable the winch handler inside of these. Better to do less than do more. I'm just going to start with iTerm and VTE, since I know they do this and how to detect them. I know konsole, alacritty, xterm and kitty don't. |
I think this disabling reflow is strictly worse in iTerm2, as the prompt doesn't get redrawn. Compare reflow (before this change): http://ridiculousfish.com/temp/reflow_crop.mp4 and with this change: http://ridiculousfish.com/temp/noreflow_crop.mp4 There's more chaos during the resize but it ends up better. Should we disable this for VTE only? |
Oh, iTerm apparently doesn't reflow? I could have sworn it does. Can you check if you've disabled it via an option? Edit: Disabled it in iTerm in the meantime. |
Apparently iTerm doesn't reflow? See #7491
iTerm2 does reflow. I also tried in gnome-terminal (VTE) and see the same issue: without a repaint the cursor can end up floating in space after the resize is done. But I also see the garbage printed above it too; it depends a lot on how fast you resize and what else is on the terminal. The main problem is the race between redrawing and resizing. I think the right fix is to add some hysteresis, so that fish waits to redraw until (say) 500 msec after the last SIGWINCH. So in most cases it will do nothing until after the resize is done. But that's not trivial to implement. |
For the record, this looks much better for me without resizing in gnome-terminal, because with resizing it ends up losing the cursor position and prints additional lines (see screenshot above). I much prefer having the right prompt sometimes floating in the middle. Also once you start typing it snaps back into place, apparently? What happens in your video in iTerm looks acceptable with resizing, so let's leave the winch handler in place there. |
It also reflows. We might want to think about doing something more extensible here, as konsole is also about to add reflow, but for now the main problem children here are VTE and alacritty. Extends #7491.
Also disabled for alacritty (with the supported "alacritty" $TERM) in 8a585bb, and we might want to look into adding a more flexible mechanism (overriding event handlers is annoying). Tbh I'm not averse to simply having a variable that we default, like term24bit or the vi cursor. (Ideally this would simply be autonegotiated, but that would require terminals to be good, and we can't have that). |
fish, version 3.1.2
I am only using Tide for customization. The maintainer told me it was an upstream issue with right prompts.
uname -a
:Linux TheMainDesktop 5.9.8-200.fc33.x86_64 #1 SMP Tue Nov 10 21:58:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
echo $TERM
:xterm-256color
Issue
Resizing the window of a terminal when using a right prompt will make the terminal look super ugly. The prompt will show up everywhere every time it gets resized.
Related issue: IlanCosman/tide#48
The text was updated successfully, but these errors were encountered: