Right prompt issues with reflowing terminal

[TheEvilSkeleton]

Please tell us which fish version you are using by executing the following:

fish --version
echo $version

fish, version 3.1.2

Please tell us if you tried fish without third-party customizations by executing this command and whether it affected the behavior you are reporting:

sh -c 'env HOME=$(mktemp -d) fish'

Welcome to fish, the friendly interactive shell
Type `help` for instructions on how to use fish

I am only using Tide for customization. The maintainer told me it was an upstream issue with right prompts.

Please tell us which operating system and terminal you are using. The output of uname -a and echo $TERM may be helpful in this regard although other commands might be relevant in your specific situation.

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

[IlanCosman]

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 😅

[IlanCosman]

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.

[TheEvilSkeleton]

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.

[mqudsi]

Does this help? #7404

It's in the latest master, so you could try that.

[TheEvilSkeleton]

@mqudsi I just compiled it from source, and the issue persists:

❯ fish --version 
fish, version 3.1.2-1651-g9b3f4faa5

[faho]

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

[faho]

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:

• not redraw in terminals that reflow
• wrap the terminal in sequences that disable wraparound (https://bugzilla.gnome.org/show_bug.cgi?id=778547#c11) ("DEC[RE]SET 7, that is, "\e[?7l" to disable and then "\e[?7h" to re-enable")

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.

[faho]

Here's a screenshot:

The upper fish has the resize handler enabled, the lower has it disabled, I resized the terminal for both.

[ridiculousfish]

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?

[faho]

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.

[ridiculousfish]

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.

[faho]

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.

[faho]

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

See alacritty/alacritty#4419.