On Tue, 30 May 2017 20:55:16 +0100 Rastislav Barlik <[email protected]> wrote:
> 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? Not to add further confusion, by saying screen, I've actually meant terminal window. XTerm however resizes up to your X11 screen size (the size you get when running xrandr command). _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
