URxvt bug: broken terminal after setting terminal size too large

Marc Lehmann schmorp at schmorp.de
Tue May 30 19:59:10 CEST 2017

On Mon, May 29, 2017 at 01:37:36PM +0100, Rastislav Barlik <barlik-arch at gmx.com> wrote:
>   printf '\e[8;9999;9999t'
> This command is quite slow (compared to xterm) and subsequently breaks
> the terminal screen and leaves it in a broken state.

I can't quite reproduce any problems, but you are likely running into
fundamental limits in X11, specifically the 32k coordinate limit.

There is little that can be done about it, except, say, trying to port it
to another window system than X11.

It is then also likely harmless, as coordinates will just wrap around,
causing graphical glitches until it's resized to a working size.

You can check by requesting, for instance, a pixelsize=1 font and see
if that causes malfunctions (with dejavu, this results in a 20009x20002
window here, which is within supported limits for X11). That, apart from
the unreadable font, should work just fine and would indicate that it's
not an issue in urxvt.

As for the speed, even without any scrollback, urxvt needs to
rewrap/redraw 800MB of data, depending on how your copy was compiled,
which can take some time.

> I've tested the behaviour in other terminals (xterm, termit, st) and
> it works without problems there.

Well, on my debian stretch installation, xterm completely fails to
resize. In any case, your statement must be wrong, as xterm can't break
the fundamental X11 limit either, so it's quite impossible that it can
work, due to no fault in xterm, but simply because it is impossible to
have such a window in X11.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

More information about the rxvt-unicode mailing list