Long Prompt Lines Cause Terminal History Loss on Window Resize

Long Prompt Lines Cause Terminal History Loss on Window Resize

[Aaron U'Ren]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Does anyone know why long prompt lines and window resizing causes lines of
terminal history to be removed?

I first noticed this while using tmux, but I can reproduce this issue
consistently both inside tmux and outside tmux (xfce4-terminal) with my
regular zsh dotfiles and with no zsh dotfiles at all on zsh 5.2. I also
tried with terminator terminal as well, but on resize it resets the
terminal history and the prompt appears at the top.

Steps to reproduce (without tmux):

   1. Make a super long prompt line (export PROMPT="this is a super long
   prompt line to test how zsh handles resizing of the window size when the
   prompt is crazy long like this one is going to be: ")
   2. Fill up the visible terminal window history with any text you want
   3. Make the terminal window as small as possible (both height and width)
   4. Make the terminal window as big as possible
   5. Rinse and repeat

Each time the terminal window goes big, the prompt moves up one line into
the terminal history and I lose that line. To reproduce in tmux it is
basically the same procedure. In a window with many panes laid out in a
tiled formation, zoom and un-zoom a single pane with a long prompt line a
couple of times.

-Aaron

Re: Long Prompt Lines Cause Terminal History Loss on Window Resize

[Bart Schaefer]

On Oct 31,  1:45pm, Aaron U'Ren wrote:
}
} Does anyone know why long prompt lines and window resizing causes lines of
} terminal history to be removed?

This is terminal-specific behavior; older xterm reformats the scrollback
itself to fit into the narrow window and then never widens it again.  In
Gnome terminal the last line of the previous prompt gets overwritten but
the scrollback above the first line of the first long prompt is left alone
(although it extends the window with blank lines below the prompt as the
window is enlarged again, so you have to scroll up to see the previous
screen; but it's not lost.)

Questions about why terminals act oddly/differently when text is printed
to the lower right corner have just about risen to the level of needing a
FAQ entry ...

Re: Long Prompt Lines Cause Terminal History Loss on Window Resize

[Aaron U'Ren]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

Interesting. So is there no way to mitigate this issue in zsh? Because bash
doesn't produce the same results in either tmux or xfce terminal.

Also, if this is purely a terminal implementation problem, can you give me
any direction about where the problem lies so that I can file a more
accurate bug report with the project? And what terminals do you recommend
that exhibit correct behavior on resize? Is tmux affected because it is
also flawed or because the terminal that contains it is flawed?

On Nov 1, 2016 10:44 PM, "Bart Schaefer" <schaefer@brasslantern.com> wrote:

> On Oct 31,  1:45pm, Aaron U'Ren wrote:
> }
> } Does anyone know why long prompt lines and window resizing causes lines
> of
> } terminal history to be removed?
>
> This is terminal-specific behavior; older xterm reformats the scrollback
> itself to fit into the narrow window and then never widens it again.  In
> Gnome terminal the last line of the previous prompt gets overwritten but
> the scrollback above the first line of the first long prompt is left alone
> (although it extends the window with blank lines below the prompt as the
> window is enlarged again, so you have to scroll up to see the previous
> screen; but it's not lost.)
>
> Questions about why terminals act oddly/differently when text is printed
> to the lower right corner have just about risen to the level of needing a
> FAQ entry ...
>

Re: Long Prompt Lines Cause Terminal History Loss on Window Resize

[Bart Schaefer]

On Nov 1, 10:53pm, Aaron U'Ren wrote:
}
} Interesting. So is there no way to mitigate this issue in zsh? Because bash
} doesn't produce the same results in either tmux or xfce terminal.

That's because bash doesn't redraw the prompt when the terminal size
changes.  Zsh handles the WINCH signal and updates the prompt to keep
the right-side prompt in the right place, etc.  This was a widely
requested behavior a few years ago when window managers with features
like live drag and transparent terminals became popular.

The terminal-specific behavior is what happens when the last line is
both redrawn and is long enough to wrap, in those circumstances, not
how the scrollback is handled when nothing changes.  There's also some
other stuff going on -- e.g., depending on how the prompt is defined,
zsh may try to keep track of how many lines the prompt occupies and
to reposition the cursor appropriately before beginning to print it.

You can also get different behavior with different window/session
managers; those with the "live drag" feature send a continuous flood
of WINCH signals in hopes that the terminal can refresh in real time
as the size changes, whereas others wait for the drag operation to
end and then send a single WINCH.  So a terminal that works as you
expect on one desktop may "fail" on another.

} Also, if this is purely a terminal implementation problem, can you
} give me any direction about where the problem lies so that I can file
} a more accurate bug report with the project?

The difficulty is that it's not just one project / one bug, it's the
interaction of three or more applications each of which has different
presentation goals.

} And what terminals do you recommend
} that exhibit correct behavior on resize?

Not something I keep track of, sorry.  If I had to guess, I would say
there probably isn't one that everyone would agree is always "correct".

} Is tmux affected because it is
} also flawed or because the terminal that contains it is flawed?

More likely the latter, but possibly both.  I don't use tmux.

One thing you could try is to prefix your prompt with "%-2<<".  This
means to always leave 2 or more spaces before the right edge of the
screen, truncating the prompt on the left if it doesn't fit on one
line.  (This only works on the last line of a prompt that has any
embedded newlines.)  Thus the prompt will disappear when the terminal
gets very small, which might keep everything else where you want it.