On Sat, Jun 22, 2019 at 11:16 AM Mick <michaelkintz...@gmail.com> wrote: >
> > Just to make sure there is no misunderstanding: the apparent bug only > > manifests itself the first time I do the shrinking/restoring stuff, > > after launching a urxvt window. Following tries will show the desired > > behaviour. Can you confirm it doesn't happen in your installation? > > Correct, I do not observe the bug you mention in my installation. I also > tried in fluxbox and the redrawing happens in the same way right from the > start, except fluxbox does not use a compositor, so (re)wrapping is a bit > jerky and shows up half a second after I stopped resizing the window. > > I need to explain I have added urxvtd in my start up: > > if [ -x /usr/bin/urxvtd ]; then > /usr/bin/urxvtd --opendisplay --fork --quiet > fi > > > so additional terminals launched with '/usr/bin/urxvtc -pe tabbed' reuse the > same single process of the daemon, making them faster and more economical in > resource usage. I assume they inherit some of what's already in memory and > this may be a reason why I don't observe your reported bug - although I can't > recall if I have this running in fluxbox. > OK, so I tested with urxvtd --opendisplay --fork --quiet, and, sure enough, the bug doesn't manifest. Even after killing urxvtd, a new instance of urxvt in a new window is bug-free. However, I tried launching another openbox session on a different VT (while keeping the current session), and the bug reappears! In the original session, a new urxvt remains bug-free. Curious. (I don't use urxvt, I stopped using it some time ago for reasons I can't remember...) Regards, Jorge
