GNU bug report logs -
#61667
29.0.60; Failure to redisplay
Previous Next
Full log
Message #29 received at 61667 <at> debbugs.gnu.org (full text, mbox):
On 21/02/2023 14:23, Eli Zaretskii wrote:
>> Date: Tue, 21 Feb 2023 04:53:58 +0200
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> This has been happening from time to time recently:
>
> Any idea how recent is "recently"?
A month-ish? I also hadn't realized right away that it was the problem
with redisplay. Some of the delays might have been a little shorter
previously. They are sometimes shorter than 1-2 seconds now as well.
>> I visit a file (either through recents or through
>> project-find-file), and the buffer stays blank for a while, giving
>> an appearance that it's "loading".
>
> You visit a file that is not already visited in some buffer in the
> current Emacs session?
Usually, yes. I don't remember an exception to this.
> Does it happen only immediately after visiting a file, i.e. upon what
> should have been the initial display of the file you visited?
Yes.
> Or does
> it happen in other situations as well? If this happens only upon
> visiting an unvisited file, does it happen every time you visit such a
> file?
Only sometimes. Randomly.
> Do you have some features enabled that affect the initial display of a
> visited file? Like save-place or something else that invokes a hook
> upon visiting? Or some display-related feature that could be
> relevant? If you do, what are those features/hooks?
I did have save-place set to t, but I can reproduce it without that.
Other hooks upon visiting? diff-hl-mode adds to find-file-hook to check
VCS status. But the file I'm currently reproducing it with is in non-VCS
controlled directory, so no visualization is added.
>> This happens with my personal configuration, and rather randomly. How
>> should I go about debugging it?
>
> Does it help to disable double buffering?
Looks like it does:
emacs --eval "(modify-frame-parameters nil
'((inhibit-double-buffering . t)))"
That "fixes" the scenario. :-(
I also tried rebuilding Emacs with '--with-xdbe=no', to eliminate
additional factors such as Lisp evaluation and frame parameter
modification, but it fails with
xterm.c: In function ‘x_end_cr_clip’:
xterm.c:5833:7: warning: implicit declaration of function
‘FRAME_X_DOUBLE_BUFFERED_P’ [-Wimplicit-function-declaration]
5833 | if (FRAME_X_DOUBLE_BUFFERED_P (f))
| ^~~~~~~~~~~~~~~~~~~~~~~~~
xterm.c:5833:7: warning: nested extern declaration of
‘FRAME_X_DOUBLE_BUFFERED_P’ [-Wnested-externs]
xterm.c: In function ‘handle_one_xevent’:
xterm.c:20904:17: warning: implicit declaration of function
‘x_drop_xrender_surfaces’; did you mean ‘font_drop_xrender_surfaces’?
[-Wimplicit-function-declaration]
20904 | x_drop_xrender_surfaces (f);
| ^~~~~~~~~~~~~~~~~~~~~~~
| font_drop_xrender_surfaces
xterm.c:20904:17: warning: nested extern declaration of
‘x_drop_xrender_surfaces’ [-Wnested-externs]
...
...
CCLD temacs
/usr/bin/ld: xterm.o: in function `x_update_end':
/home/dgutov/vc/emacs/src/xterm.c:7361: undefined reference to
`FRAME_X_DOUBLE_BUFFERED_P'
/usr/bin/ld: xterm.o: in function `x_end_cr_clip':
/home/dgutov/vc/emacs/src/xterm.c:5833: undefined reference to
`FRAME_X_DOUBLE_BUFFERED_P'
/usr/bin/ld: /home/dgutov/vc/emacs/src/xterm.c:5833: undefined reference
to `FRAME_X_DOUBLE_BUFFERED_P'
/usr/bin/ld: /home/dgutov/vc/emacs/src/xterm.c:5833: undefined reference
to `FRAME_X_DOUBLE_BUFFERED_P'
/usr/bin/ld: /home/dgutov/vc/emacs/src/xterm.c:5833: undefined reference
to `FRAME_X_DOUBLE_BUFFERED_P'
/usr/bin/ld: xterm.o:/home/dgutov/vc/emacs/src/xterm.c:5833: more
undefined references to `FRAME_X_DOUBLE_BUFFERED_P' follow
even after 'make extraclean'.
Revision e83c78b8c7784254.
> Do you see anything interesting in *Messages* after such an incident?
Nope.
This bug report was last modified 1 year and 62 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.