Re: Buffer corruption when the terminal is resized.

[Paul Peet]

Well, I seriously have no idea what approach would be the right one to
fix this but I've responded on the other side and this was Egmont
Koblinger (vte developer) response:

----
Yes, indeed, rewrapping the contents on resize breaks this assumption.

Given that in a(n obviously non-representative) poll about 1.5 years
ago at https://opensource.com/life/15/11/top-open-source-terminal-emulators,
terminal emulators that now (not at the time of the poll) rewrap on
resize got around 50-60% of the votes, maybe it's time for
readline/bash to reconsider their assumptions.

You can easily disable rewrapping in the profile preferences. You
will, however, lose one of the coolest features that received by far
the most positive feedback in recent years of vte/gnome-terminal. The
one that made me join the project. The one that resulted in the
biggest productivity boost for me and probably for many other folks.
The one that I'm still the proudest of till this day :-) Your call.

Could VTE rewrap the entire scrollback, just not the last prompt?
Well, that would certainly require tons of future development and
cooperation with bash and other shells, because then we would need to
know where the prompt is, which we currently don't know and don't care
about. It might become handy or even necessary for command completion
notification anyway (a stalled feature request), depending on what
approach we take there, but there we saw an utter lack of interest
from bash devs in cooperating and addressing that request. As such, I
have doubts that they'd be open for a cooperation here. Also I
personally wouldn't care about such cooperation if it aimed to address
this prompt-resize issue only and not the notification one. I'd
personally be happy to cooperate with them (time permitting) if we aim
to address both this issue and the notification story.

Until then, you have a couple of choices. You can disable rewrap on
resize. You can disable and then restore wraparound in your prompt, as
shown above. Or you can live with this issue.

I really don't think it's a serious issue. You need to stress-resize
the window for this to occur, which you probably won't do normally.
And even if you hit the bug, the consequences are not severe at all.
Just a bit of display corruption; you can press ^L to clear/repair the
screen, or ^C to cancel the command and start over, or anything alike.
It's sure a bit annoying, but IMO nothing big deal.

In the mean time I'm wondering... does the workaround of disabling
wraparound while the prompt is printed (that is,
PS1='\[\e[?7l\].....\[\e[?7h\]') have any drawbacks at all?
----
https://bugzilla.gnome.org/show_bug.cgi?id=780995


> Yes, indeed, rewrapping the contents on resize breaks this assumption.
>
> Given that in a(n obviously non-representative) poll about 1.5 years ago at 
> https://opensource.com/life/15/11/top-open-source-terminal-emulators, 
> terminal emulators that now (not at the time of the poll) rewrap on resize 
> got around 50-60% of the votes, maybe it's time for readline/bash to 
> reconsider their assumptions.
>
> You can easily disable rewrapping in the profile preferences. You will, 
> however, lose one of the coolest features that received by far the most 
> positive feedback in recent years of vte/gnome-terminal. The one that made me 
> join the project. The one that resulted in the biggest productivity boost for 
> me and probably for many other folks. The one that I'm still the proudest of 
> till this day :-) Your call.
>
> Could VTE rewrap the entire scrollback, just not the last prompt? Well, that 
> would certainly require tons of future development and cooperation with bash 
> and other shells, because then we would need to know where the prompt is, 
> which we currently don't know and don't care about. It might become handy or 
> even necessary for command completion notification anyway (a stalled feature 
> request), depending on what approach we take there, but there we saw an utter 
> lack of interest from bash devs in cooperating and addressing that request. 
> As such, I have doubts that they'd be open for a cooperation here. Also I 
> personally wouldn't care about such cooperation if it aimed to address this 
> prompt-resize issue only and not the notification one. I'd personally be 
> happy to cooperate with them (time permitting) if we aim to address both this 
> issue and the notification story.
>
> Until then, you have a couple of choices. You can disable rewrap on resize. 
> You can disable and then restore wraparound in your prompt, as shown above. 
> Or you can live with this issue.
>
> I really don't think it's a serious issue. You need to stress-resize the 
> window for this to occur, which you probably won't do normally. And even if 
> you hit the bug, the consequences are not severe at all. Just a bit of 
> display corruption; you can press ^L to clear/repair the screen, or ^C to 
> cancel the command and start over, or anything alike. It's sure a bit 
> annoying, but IMO nothing big deal.
>
> In the mean time I'm wondering... does the workaround of disabling wraparound 
> while the prompt is printed (that is, PS1='\[\e[?7l\].....\[\e[?7h\]') have 
> any drawbacks at all?
> [reply] [−] Comment 15

On Mon, Jun 12, 2017 at 10:45 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 6/12/17 4:24 PM, Chet Ramey wrote:
>> On 6/12/17 4:08 PM, Paul Peet wrote:
>>> Is there a flag in macOS's Terminal? It's because I am also
>>> experiencing this bug on macOS's Terminal :) (with bash).
>>
>> I doubt it. My testing wasn't very scientific. I just opened up a new
>> Terminal, ran bash-4.4, typed a bunch of characters, and constantly resized
>> the terminal while watching the display.  xterm didn't do too badly at
>> this, either.
>>
>> The thing that Terminal does that other terminal emulators (e.g., xterm)
>> don't seem to do is rewrap all the text on the screen as the screen gets
>> resized.  For instance, if I make an xterm very narrow, so that the text on
>> previous lines gets `squeezed' and not displayed, that text isn't restored
>> when I widen it again. xterm also leaves text on the screen below the
>> current line if the screen is narrowed so the current line wraps and
>> consumes all of the vertical area, then widened again. This argues for the
>> conjecture that other terminal emulators expect the foreground process to
>> manage the entire display, not just the current line.
>
> Now, one thing I didn't mention is that this auto-wrapping of all text can
> cause its own problems. Consider the case where the cursor is at the right
> side of the screen, and you narrow the screen one or two columns -- just
> enough to cause the text to require, say, three lines instead of two.  In
> this instance, Terminal wraps the text on its own -- meaning the cursor is
> now on the third `physical' line -- before sending bash a SIGWINCH. At this
> point, readline tries to perform redisplay assuming the cursor is still on
> the second line and that the terminal emulator hasn't done anything, so its
> position calculations are off from the start.  This can easily leave stray
> lines of text on the screen that readline doesn't (and can't) know about.
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/