URxvt bug: broken terminal after setting terminal size too large

Rastislav Barlik barlik-arch at gmx.com
Tue May 30 21:55:16 CEST 2017


On Tue, 30 May 2017 19:59:10 +0200
Marc Lehmann <schmorp at schmorp.de> wrote:

> 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.
> 

Sorry, I haven't made myself clear enough. What I meant by saying that
XTerm "works" is that it doesn't break the screen, and it only resizes
up to your maximum screen size. I'm on Arch Linux using XTerm 327 (the
latest built).

URxvt on the other hand resizes the screen, but makes it unusable by
introducing various graphic artefacts (characters randomly
disappearing, fonts and colors completely broken). Resizing the screen
back doesn't fix the glitches. That's how I've noticed the problem in
the first place.

I'm not trying to actually use such a big terminal, it's an issue I've
come across by running vim's tests. One of them is setting the screen
size to 2000 columns and then putting it back, breaking my terminal
window by doing so.

If we can't guarantee that the terminal will still be usable after
setting the screen size too large, wouldn't it make more sense to do
the same as what XTerm is doing and prevent setting the size larger
than the actual screen size?

Best regards,
Rastislav




More information about the rxvt-unicode mailing list