GNU bug report logs -
#78861
[PATCH] Avoid calendar flicker
Previous Next
Full log
Message #35 received at 78861 <at> debbugs.gnu.org (full text, mbox):
On Sun, 22 Jun 2025 17:38:12 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>, 78861 <at> debbugs.gnu.org
>> Date: Sun, 22 Jun 2025 15:55:26 +0200
>>
>> I don't see any flickering or redrawing with that recipe, but in my
>> calendar and diary configuration I do see what looks like delayed
>> fontification of certain date marking. I've narrowed the issue down to
>> a combination of marking lunar phases and having a sufficiently large
>> number of diary entries (in my case due to including several todo-mode
>> files). Here is a recipe:
>>
>> 0. Make ~/.emacs.d/diary consist of the following lines:
>> -------------------------------
>> %%(diary-lunar-phases 'warning)
>> Jun 22, 2025 test
>> -------------------------------
>> and then repeat the second line a large number of times (5000 shows the
>> issue clearly on my machine, 1000 shows it too, but not as clearly).
>> 1. emacs -Q
>> 2. M-x calendar
>> 3. Hit 'm' and then alternatively '>' and '<'.
>>
>> On typing 'm' there is a noticeable delay before the dates are marked,
>> on the first scroll command also a noticeable delay but not as long, on
>> subsequent scroll commands much less delay but enough to see the dates
>> first with default face, then change to warning face. With Manuel's
>> patch let-binding 'inhibit-redisplay', there are still delays when
>> scrolling but the lunar phase dates are shown in warning face as soon as
>> the scroll happens.
>
> Is this an interesting case? Do people frequently have thousands of
> such lines in their ~/diary files?
The 5000 lines was just to clearly show the effect; the todo-mode files
I include contain almost 3000 items in total, but only 100 diary items,
and the effect I see there is much less than with my exaggerated recipe,
though noticeable.
> Anyway, what triggers the fontifications that are evidently done after
> the initial display? Are there any timers involved, perhaps? IOW,
> why isn't the buffer fontified immediately?
I haven't examined the code yet; however, I did try my exaggerated
recipe after commenting out the sit-for calls in
calendar-generate-window, and while there is still an noticeable delay
with the initial marking of entries, and a smaller delay on scrolling, I
do see the correctly fontified entries as soon as the scroll happens,
and haven't noticed any other problems in the Calendar display without
the sit-for calls. So removing these calls seems like a good idea.
Steve Berman
This bug report was last modified 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.