On Tue, 30 May 2017 19:59:10 +0200 Marc Lehmann <[email protected]> wrote:
> On Mon, May 29, 2017 at 01:37:36PM +0100, Rastislav Barlik > <[email protected]> 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 _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
