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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
