thanks for the reply.
this is indeed a bug. it breaks for ANY script that outputs more than
one line {replace echo with printf and it will still break}.
the bug is simply this: if you resize the terminal before the script
fills the screen, lines are erased instead of reflowed to allow
scrolling. how could this possibly not be a bug?
this bug is not in xterm, gnome-terminal, konsole. its critical because
it erases data unrecoverably.
the bug goes away if you change line 308 in screen.C to make it reflow
on all screen resets. it also goes away if you use screen.
my best guess for the technical reason for the bug is that the resize
makes scrollback necessary, but the screen reset is called before the
terminal has a chance to set top_line appropriately.
so my guess at a real solution would be to do a check on all scr_resets:
if(no_scroll_back) { ensure_lines_fit_on_screen(); }
On 12/21/2014 08:04 AM, Marc Lehmann wrote:
On Sat, Dec 20, 2014 at 03:08:42PM -0500, Elliot Wolk <[email protected]>
wrote:
command output is erased on resize in certain circumstances {afaict,
the circumstances are: scrollback must not exist yet, and the screen
reset must hide at least 2 lines}
From the description, and a superficial look at your references, the
behaviour is correct and expected for urxvt - urxvt only reflows if there
is scrollback, so there isn't a bug.
echo "line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9"
It helps (in the future) if your test script would work in a normal posix
shell environment, i.e. use printf, which supports c-style escapes such as
\n.
4) lines are eaten every time
e.g.:
line 1
line 2
line 3
line 4
15ne 5
16
17
This looks more as if one line (15) is overlayed over an exiting
line. Since your script keeps outputting text after the resize, this is
likely due to the script overwriting existing output though.
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
