|
From: | Dmitry Gutov |
Subject: | bug#61667: 29.0.60; Failure to redisplay |
Date: | Wed, 1 Mar 2023 16:33:11 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
Dmitry Gutov<dgutov@yandex.ru> writes:Nope, it's for the "no problem" case. Hence the name.Huh, that's really weird. If blink-cursor-mode is not the source of the inconsistencies, then the only explanation is that GNOME somehow behaves badly if: - the back buffer is displayed prior to the title being set. - the WM name is changed. - another buffer swap happens 400 ms later.
This delay happens because of the human factor: I need to hit 'a' after the frame has fully rendered, to run the command (which inserts !, redisplays, then calls find-file).
I will try to see if I can reproduce this.I am sure, but just to verify, I redid the experiment again. See attached files, the naming scheme is the same: two problem cases and one "okay" case.Was blink-cursor-mode turned off, BTW? If it is on, then potentially superfluous buffer swaps will end up in the logs once per blink-cursor-interval and screw them up.
But blink-cursor-mode was on, of course. It's -Q: everything's on what was not turned off.
And it turns out to be the reason for the difference between this and my personal config. With blink-cursor-mode off, the delay can reach multiple seconds like I previously reported.
Attaching new recordings with b-c-m off, same naming scheme.
errrr.log
Description: Text Data
errrr2.log
Description: Text Data
errrr-okay.log
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |