Could you please confirm that the behavior differs in gnome-terminal with rewrap on resize disabled, versus xterm? If so, could you please attach a screenshot demonstrating the difference between these two? (I'm pretty certain the one you attached has rewrapping enabled.)

Note that the last prompt is supposed to be different from the previous ones. The previous ones are "dead", zsh no longer updates them. The expected behavior in every terminal emulator that does not rewrap is to chop off the right end when the window is made narrower. (Also, the clock shows a past timestamp.) A tiny difference between xterm and gnome-terminal is that if you make the terminal wider again, the previously chopped off contents reappear in gnome-terminal, but are lost for good (replaced with blank) in xterm.

The last prompt is "live", zsh can and does update it upon every resize. (It can theoretically also update the clock every second, I don't know if it does it.) Here the expected behavior in both terminals (with xterm and gnome-terminal without rewrap) is that it always looks okay, since zsh repaints it perfectly.

The only troublesome case should be this last "live" prompt, and gnome-terminal with rewrapping enabled. Here gnome-terminal potentially wraps the prompt into multiple lines, and immediately afterwards zsh repaints it without knowing that gnome-terminal "messed" with it.

I'll also try to get it work to see it myself, as time permits.

The original screenshot was from terminator. I previously tested in gnome-terminal with rewrap on resize both disabled and enabled, and could replicate it in both cases. I've attached a screenshot with rewrap on resize disabled. I've also attached a screenshot with xterm looking normal after copious resizing.

You are right with the comments regarding xterm. I can chop off text by making the window smaller. I then make the window larger, and the text has permanently disappeared.

I can also confirm that the last prompt always looks fine with vte. Similarly, if I sit idle, the time doesn't update normally. However, if I resize, then the time updates.

Thank you for your comments.

Created attachment 345679 [details]
Visual corruption in gnome-terminal (rewrap on resize disabled) after resizing

Created attachment 345680 [details]
No visual corruption in xterm after resizing.

I've tried it out, and indeed I can see a difference between xterm and gnome-terminal.

The "dead" prompts work as expected in both, as described above.

The "live" prompt (the latest one) gets corrupted in gnome-terminal if you make the window narrower relatively quickly with opaque resize mode. This does not happen in xterm.

Notice, however, that no apparent bug occurs in gnome-terminal if you:

- either make the window narrower by 1 column only at a time (that is, drag the window border quite slowly);

- or use a non-opaque resize method that only resizes the window once you release the mouse (e.g. on Ubuntu's default Unity7: install compizconfig-settings-manager, launch ccsm, go to Window Management -> Resize Window -> General -> Default Resize Mode: Outline).

Looking at the escape sequences emitted, there's nothing suspicious that gnome-terminal might potentially mishandle or not support. It's colors/attributes, carriage returns, \e[K and \e[J (clear to the right / to the right and below), \e[<num>C and \e[<num>D (move the cursor to the right / left), and a few absolutely irrelevant ones (app keypad mode, bracketed paste).

All I can think of is a timing issue which happens to be hit more frequently in gnome-terminal, but probably theoretically is still there in xterm.

Drag the window border with a "medium" speed (not too fast for the gnome-terminal issue to occur, but not much slower either). You'll see a noticeable lag in updating the right-hand bits of the prompt in gnome-terminal. xterm doesn't have this noticeable delay.

What I'm pretty sure happens technically is: The width is decreased at least twice shortly after each other. Let's say it goes from 80 to 75 and then 70 columns. Zsh is first notified that the window is 75 columns wide, and it goes ahead and repaints its prompt accordingly. But by the time it actually gets there, the width has become narrower again, so gnome-terminal will display the 75 character wide prompt string (actually 74 since the last column is unused; it's irrelevant here) on a terminal that's already only 70 characters wide. Hence it wraps to the next line.

I cannot think of any way right now that inherently fixes this race condition.

We could, however, investigate why/how xterm is significantly faster here, since indeed it's a huge usability problem. At least we should:

- make sure that the kernel is notified of the terminal size change as early as possible once we receive that event from Gtk (remember that it's the kernel's process switching that matters which can kick in at any time, so even changing the order of stuff within a single function can help a lot) (e.g. VteTerminalPrivate::widget_size_allocate is suspicious, it does quite a bit of Gtk+ stuff before notifying the kernel via set_size()... but maybe we'll hit some Gtk+ internal limitation?);

- make sure to empty the input queue before handling this event (that is, make sure that data already in the queue is still interpreted according to the old size);

- anything else?

(In reply to bugzilla.gnome from comment #2)

We cross-posted, nevermind :)

> I can also confirm that the last prompt always looks fine with vte.

We used a different terminology here. By "last prompt" what I meant was the one displayed after the last run command, the one that is repeated 16 times on your screenshot (and not the last out of these 16). So, from a user's point of view, it's not okay.

I've tried a few emulators.

xterm, konsole, pterm[putty] => could not reproduce the issue by crazily dragging the window border for a few seconds.

urxvt, st[suckless] => can reproduce, but occurs less frequently than in vte.

terminology[enlightenment] => can very easily reproduce. Also: it rewraps its contents, so once the bug occurs, the rest suddenly terribly falls apart, just as in gnome-terminal with rewrapping.

I think this pretty much proves that there's something fundamentally broken here (not just in vte), yet there's room to enhance the behavior and mitigate the problem.

> either make the window narrower by 1 column only at a time (that is, drag the window border quite slowly);

I can confirm this works on my system too.

> or use a non-opaque resize method that only resizes the window once you release the mouse (e.g. on Ubuntu's default Unity7: install compizconfig-settings-manager, launch ccsm, go to Window Management -> Resize Window -> General -> Default Resize Mode: Outline).

I'm using KDE/Arch, so I'm not sure how to set that up. However, Plasma/Kwin has keyboard shortcuts that let you place windows in specific quarters and halves of the screen. I can jump the windows around like this, and confirm that I see no corruption in gnome-terminal. I also tested with rewrap on resize *enabled*. I also see no corruption per se, but it's not perfect either. If I move from a "wide" to a "narrow" window, lines go missing. For example, if I move the window from the top half of the screen to the top right, as so:

OO        .O
..  --->  ..

the top two lines go missing. I can repeat this indefinitely to remove more lines, two at a time. To recover them, I can scroll up, or I can move the window to a "tall" version.

.O       .O
..  ---> .O

I see similar behaviour in terminator, where it's more of an issue, because of the frequent horizontal splitting.

I'm unsure if this is related to your hypothesis about the race condition, which I agree sounds plausible otherwise.

> By "last prompt" what I meant was…

Ah yes okay. Agreed.

> I've tried a few emulators.

Thanks again for your attention to this issue.

(In reply to bugzilla.gnome from comment #8)

> the top two lines go missing.

This is probably another story (and probably again zsh doing something weird).

(In reply to Egmont Koblinger from comment #9)
> (In reply to bugzilla.gnome from comment #8)
> 
> > the top two lines go missing.
> 
> This is probably another story (and probably again zsh doing something
> weird).

I should mention that I only see it with rewrap on resize enabled. With this disabled, there is no problem at all. I also just tested with terminator, and it's the same thing, i.e. only a problem when rewrap on resize is enabled. I'm guessing that this option is unique to vte, so I'm not sure if it's possible to compare other emulators. (e.g. Konsole doesn't have this option.)

I think I found a proper (that is: race condition free) fix for this problem. It should go to zsh though, and not to the terminal emulators.

zsh should temporarily disable "wraparound" mode while printing the prompt (or, up to them, maybe the entire duration of the user editing the command line).

It's DEC[RE]SET 7, that is, "\e[?7l" to disable and then "\e[?7h" to re-enable.

This way, even printing e.g. a 75 character wide prompt on a suddenly only 70 character wide terminal is "harmless", the terminal just swallows the last few characters (more precisely: keeps overwriting the last cell with these characters - this detail is irrelevant now), and the immediately following 70 character wide prompt will completely repair this garbled line. The point is: the terminal does not wrap to the next line which causes the problems.

Not sure if this feature request belongs to zsh itself or to the prompt/theme. A zsh guru, or anyone in touch with the developers and willing to forward this request to them would be highly appreciated!

Thanks for the find! I don't have much knowledge of the details, but since this bug occurs with two different prompts, I'd assume that it's a zsh issue.

I'm certainly no zsh guru, and I'm not in touch with the developers. I might wait for someone else to do it; is that likely? Otherwise I'm happy to forward it off… as long as they don't ask me too many questions! 

As a proof of concept, with the powerlevel9k theme, do this:

Edit the file ~/powerlevel9k/powerlevel9k.zsh-theme. At the end of the powerlevel9k_prepare_prompts() function, just above its closing curly brace (line 1041 for me), add these two lines:

  PROMPT=$'%{\e[?7l%}'"$PROMPT"
  RPROMPT="$RPROMPT"$'%{\e[?7h%}'

It's already a huge improvement, isn't it? As long as the prompt is not at the top, resizing (narrowing) works nicely, except that the concents keep shifting upwards as you've recently mentioned. Then once the prompt reaches the top, it begins to fall apart a bit (well, at least some garbage is added to the scrollback buffer.) I've no clue about it right now, it'll require further investigation.

Oh, I got it, it's so obvious :) It's because of rewrap.

The right prompt (clock) is displayed in a way that the last cell is "unused" (rather than a space character; you can check it by copy-pasting the entire line to a text editor, an "unused" cell is copied as nothing), the previous ones are filled up. If the terminal is narrowed by 1 column, nothing special happens (and the redisplayed prompt will wipe out the contents from the now-last column and make that "unused").

If the terminal is narrowed by 2 or more cells in a single step, rewrapping kicks in. Then the data that is wrapped to the next line is immediately wiped out by the new prompt (the \e[J sequence within).

I guess the best zsh could do here (in addition to the DECSET 7 trick mentioned above) is kinda replicate gnome-terminal's rewrapping, at least to be able to know how its prompt looks like, and act according to that :P

With rewrapping disabled, the situation is really nice. There's still a problem though: If the terminal is narrower than the left prompt, zsh keeps eating up the data upwards. This really sounds like a zsh issue (and occurs in xterm too).

> As a proof of concept

I *think* it's an improvement. However, when I've previously tested, I've always had the prompt hitting the top pretty soon, so it's hard to differentiate between the two scenarios.

Having said that, in some cases I can still get corruption even if the prompt doesn't hit the top. I *think* that it's related to having enough text in the prompt that the terminal tries to rewrap it (we're testing with rewrap on resize on, right?). I'll attach a screenshot.

> Oh, I got it, it's so obvious :) It's because of rewrap.

Ah cool, that makes sense!

> If the terminal is narrower than the left prompt, zsh keeps eating up
the data upwards. This really sounds like a zsh issue (and occurs in xterm
too).

I can confirm that this occurs in xterm too.

Created attachment 345692 [details]
Visual corruption in gnome-terminal (rewrap on resize enabled) after resizing, after applying patch to powerlevel9k

I guess we're on the same page (not a surprise though, we're testing the same thing). To summarize: With the patch, and rewrap disabled, we're seeing a great improvement. As long as the window is not made narrower than the left prompt, everything's perfect. Correct?

<rant>

I was about to file a ZSH feature request so that they wrap the display of the prompt in a DECRESET 7 / DECSET 7 pair. The right prompt ($RPROMPT) is a feature of zsh itself, you don't need any fancy powerwhatever theme, just RPROMPT=foo and tadaa it's there.

I swear I would have created an account to their bugtracker and filed this request. Guess what. They don't have a bugtracker, they have a mailing list instead. Like, seriously? In 2017? A mailing list for tracking issues???

No, I'm not going to subscribe to a mailing list just to get tons of irrelevant spam, or bother setting up mail filtering rules that send anything except the bug I'm interested in to /dev/null. All this in order to file a bugreport for a product that I don't even use. It's just ridiculous.

Not to mention the usual crazy nested thread index on the web UI, a new thread appearing if someone modify the subject (perhaps accidentally) and all this crazyness. Hands up who has ever seen a thread index work reliably.

It should really be done by someone who cares enough about ZSH.

I'm happy to chime in if needed, provide support, file/comment in bugzilla/trac/sourceforge-github/gitlab/whatnot; but mailing list, hell no.

</rant>

(In reply to Egmont Koblinger from comment #17)
> I guess we're on the same page (not a surprise though, we're testing the
> same thing). To summarize: With the patch, and rewrap disabled, we're seeing
> a great improvement. As long as the window is not made narrower than the
> left prompt, everything's perfect. Correct?

Sorry, it's getting a bit confusing. So with the patch, and rewrap disabled, it *might* be a little better, but I wouldn't say it's a "great" improvement. I still get issues as per comment 15 and the attachment in comment 16.

I absolutely agree with your rant about the zsh (lack of) bug tracker. It's totally ridiculous, and definitely an obstruction to filing bugs. Having said that, I think you can just email the list without being on it, and they will cc you. I think. e.g. http://www.zsh.org/mla/workers/1995/msg00341.html

Still, I agree that this is sub-optimal, to say the least.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2374.