GNU bug report logs -
#61667
29.0.60; Failure to redisplay
Previous Next
Full log
View this message in rfc822 format
On 26/02/2023 14:31, Eli Zaretskii wrote:
>> Date: Sun, 26 Feb 2023 14:23:49 +0200
>> Cc:luangruo <at> yahoo.com,61667 <at> debbugs.gnu.org,gregory <at> heytings.org
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> On 26/02/2023 14:13, Eli Zaretskii wrote:
>>> Thanks, but I still need to insist on more clarity, if possible.
>>>
>>> You say "disappears", in quotes, presumably to say that it's still
>>> present but hard to notice? And before that, you say the delay is
>>> always physically present?
>> The delay is distance in time. It can't really be zero -- that's just
>> physics: the OS has to process the keypress, Emacs has to read the file,
>> run the major mode function, etc.
>>
>> The problem is when that delay becomes high enough to notice with a
>> naked eye.
> And that happens even if the frame title is not changed?
No.
Here are all the ways we have found that make the problem go away:
--eval "(modify-frame-parameters nil '((inhibit-double-buffering . t)))"
--eval "(setq frame-title-format \"foo bar foo\")"
--eval "(modify-frame-parameters nil '((undecorated . t)))"
When any of these arguments is passed to Emacs, the problem does not
reproduce anymore.
> IOW, is time interval between pressing RET at the end of the command
> which starts Emacs and the time the text area of the window shows the
> file's text -- is this time interval the same whether the frames title
> changes or not?
The command doesn't trigger Emacs to visit a file, though.
So I mean the delay between me either
- Pressing 'a' in one scenario (the 'emacs -Q ...' one)
- Or pressing 'C-x b xas RET' (using Ido completion with my config)
and the buffer's text being displayed.
This bug report was last modified 1 year and 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.