GNU bug report logs - #78861
[PATCH] Avoid calendar flicker

Previous Next

To reply to this bug, email your comments to 78861 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 09:00:02 +0200

[Message part 1 (text/plain, inline)]

Tags: patch

Hi,

When you have diary marks activated in the calendar (with 'm',
diary-mark-entries) and when moving around (for example with '<' and
'>') you will see some flicker on dates where you have marks.  This
patch fixes this.



In GNU Emacs 31.0.50 (build 7, x86_64-unknown-openbsd7.7) of 2025-06-21
 built on computer
Repository revision: c916f816e0f12f876868f9ffa1be4b070933bb6f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: OpenBSD computer 7.7 GENERIC.MP#23 amd64

Configured using:
 'configure CC=egcc CPPFLAGS=-I/usr/local/include
 LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs
 --bindir=/home/manuel/bin --with-x-toolkit=no
 --with-toolkit-scroll-bars=no --without-cairo --without-dbus
 --without-gconf --without-gsettings --without-compress-install'

[0001-Avoid-calendar-flicker.patch (text/patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Manuel Giraud

Message #8 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 10:25:17 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Date: Sun, 22 Jun 2025 09:00:02 +0200
> 
> When you have diary marks activated in the calendar (with 'm',
> diary-mark-entries) and when moving around (for example with '<' and
> '>') you will see some flicker on dates where you have marks.

Please elaborate: which part(s) of the display flicker?  I tried a
simple recipe to reproduce the problem, and saw no flickering on my
system.

Did you see the flickering in "emacs -Q"?  And what is the state of
double-buffering in the session where you saw it?

> This patch fixes this.

Sorry, the inhibit-redisplay flag is not meant to be used for these
purposes, so this patch is not TRT, from where I stand.  We need
instead to understand why the display flickers and fix that to avoid
the flickering.  So let's please take a step back and try to come up
with a reproducible recipe that exhibits this flickering, and then see
why it happens.

Thanks.

Message #11 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 13:46:28 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Date: Sun, 22 Jun 2025 09:00:02 +0200
>> 
>> When you have diary marks activated in the calendar (with 'm',
>> diary-mark-entries) and when moving around (for example with '<' and
>> '>') you will see some flicker on dates where you have marks.
>
> Please elaborate: which part(s) of the display flicker?  I tried a
> simple recipe to reproduce the problem, and saw no flickering on my
> system.

I see the date digits flicker when moving: the digits glimpse in black
before turning to red (with default theme).

> Did you see the flickering in "emacs -Q"?

Here is a recipe:
     - emacs -Q
     - Open "/tmp/diary" and insert the following content:
--8<---------------cut here---------------start------------->8---
%%(diary-block 6 22 2025 8 30 2025) Looong break
--8<---------------cut here---------------end--------------->8---
     - M-: (setq diary-file "/tmp/diary") <RET>
     - M-x calendar <RET>
     - Hit 'm' and then alternatively '>' and '<' to see the flicker

> And what is the state of double-buffering in the session where you saw
> it?

I'm not sure but I think I'm good.  Here's an excerpt of xdpyinfo:

number of extensions:    28
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    DRI2
    DRI3
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    Present
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XFree86-DGA
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

>> This patch fixes this.
>
> Sorry, the inhibit-redisplay flag is not meant to be used for these
> purposes, so this patch is not TRT, from where I stand.  We need
> instead to understand why the display flickers and fix that to avoid
> the flickering.  So let's please take a step back and try to come up
> with a reproducible recipe that exhibits this flickering, and then see
> why it happens.

Ok.
-- 
Manuel Giraud

Message #14 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 16:05:50 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: 78861 <at> debbugs.gnu.org
> Date: Sun, 22 Jun 2025 13:46:28 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> >> Date: Sun, 22 Jun 2025 09:00:02 +0200
> >> 
> >> When you have diary marks activated in the calendar (with 'm',
> >> diary-mark-entries) and when moving around (for example with '<' and
> >> '>') you will see some flicker on dates where you have marks.
> >
> > Please elaborate: which part(s) of the display flicker?  I tried a
> > simple recipe to reproduce the problem, and saw no flickering on my
> > system.
> 
> I see the date digits flicker when moving: the digits glimpse in black
> before turning to red (with default theme).

I don't see anything like that here.

> Here is a recipe:
>      - emacs -Q
>      - Open "/tmp/diary" and insert the following content:
> --8<---------------cut here---------------start------------->8---
> %%(diary-block 6 22 2025 8 30 2025) Looong break
> --8<---------------cut here---------------end--------------->8---
>      - M-: (setq diary-file "/tmp/diary") <RET>
>      - M-x calendar <RET>
>      - Hit 'm' and then alternatively '>' and '<' to see the flicker

I see the entire window being redrawn, so it's hard to see a flicker.
Seeing flickering requires that everything stays the same and in the
same position in the window, otherwise it's impossible to say that
there's flickering when everything moves and changes.

If the above is the best scenario you can offer, then please point me
to the code in calendar that first draws the numbers in black and then
redraws them in red, and I will take a look.

> > And what is the state of double-buffering in the session where you saw
> > it?
> 
> I'm not sure but I think I'm good.  Here's an excerpt of xdpyinfo:

No, I meant whether your build is with double-buffering?

Message #17 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>, 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 15:55:26 +0200

On Sun, 22 Jun 2025 16:05:50 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: 78861 <at> debbugs.gnu.org
>> Date: Sun, 22 Jun 2025 13:46:28 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> >> Date: Sun, 22 Jun 2025 09:00:02 +0200
>> >> 
>> >> When you have diary marks activated in the calendar (with 'm',
>> >> diary-mark-entries) and when moving around (for example with '<' and
>> >> '>') you will see some flicker on dates where you have marks.
>> >
>> > Please elaborate: which part(s) of the display flicker?  I tried a
>> > simple recipe to reproduce the problem, and saw no flickering on my
>> > system.
>> 
>> I see the date digits flicker when moving: the digits glimpse in black
>> before turning to red (with default theme).
>
> I don't see anything like that here.
>
>> Here is a recipe:
>>      - emacs -Q
>>      - Open "/tmp/diary" and insert the following content:
>> --8<---------------cut here---------------start------------->8---
>> %%(diary-block 6 22 2025 8 30 2025) Looong break
>> --8<---------------cut here---------------end--------------->8---
>>      - M-: (setq diary-file "/tmp/diary") <RET>
>>      - M-x calendar <RET>
>>      - Hit 'm' and then alternatively '>' and '<' to see the flicker
>
> I see the entire window being redrawn, so it's hard to see a flicker.
> Seeing flickering requires that everything stays the same and in the
> same position in the window, otherwise it's impossible to say that
> there's flickering when everything moves and changes.
>
> If the above is the best scenario you can offer, then please point me
> to the code in calendar that first draws the numbers in black and then
> redraws them in red, and I will take a look.

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.

>> > And what is the state of double-buffering in the session where you saw
>> > it?
>> 
>> I'm not sure but I think I'm good.  Here's an excerpt of xdpyinfo:
>
> No, I meant whether your build is with double-buffering?

Here (GNU/Linux) `M-: (x-double-buffered-p)' returns t.

Steve Berman

Message #20 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 16:08:37 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: 78861 <at> debbugs.gnu.org
>> Date: Sun, 22 Jun 2025 13:46:28 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> >> Date: Sun, 22 Jun 2025 09:00:02 +0200
>> >> 
>> >> When you have diary marks activated in the calendar (with 'm',
>> >> diary-mark-entries) and when moving around (for example with '<' and
>> >> '>') you will see some flicker on dates where you have marks.
>> >
>> > Please elaborate: which part(s) of the display flicker?  I tried a
>> > simple recipe to reproduce the problem, and saw no flickering on my
>> > system.
>> 
>> I see the date digits flicker when moving: the digits glimpse in black
>> before turning to red (with default theme).
>
> I don't see anything like that here.
>
>> Here is a recipe:
>>      - emacs -Q
>>      - Open "/tmp/diary" and insert the following content:
>> --8<---------------cut here---------------start------------->8---
>> %%(diary-block 6 22 2025 8 30 2025) Looong break
>> --8<---------------cut here---------------end--------------->8---
>>      - M-: (setq diary-file "/tmp/diary") <RET>
>>      - M-x calendar <RET>
>>      - Hit 'm' and then alternatively '>' and '<' to see the flicker
>
> I see the entire window being redrawn, so it's hard to see a flicker.
> Seeing flickering requires that everything stays the same and in the
> same position in the window, otherwise it's impossible to say that
> there's flickering when everything moves and changes.

Fair enough.  Here is (maybe) another way to see this flickering I'm
seeing: same first four points of the recipe and then you could hit 'm'
repeatedly.  Nothing should move but I still see a flicker.

> If the above is the best scenario you can offer, then please point me
> to the code in calendar that first draws the numbers in black and then
> redraws them in red, and I will take a look.

Thanks Eli.  I think most takes place in `diary-mark-entries' at
diary-lib.el:1377.

>> > And what is the state of double-buffering in the session where you saw
>> > it?
>> 
>> I'm not sure but I think I'm good.  Here's an excerpt of xdpyinfo:
>
> No, I meant whether your build is with double-buffering?

I think so. I don't think I use any build option that could inhibit this.
-- 
Manuel Giraud

Message #23 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: manuel <at> ledu-giraud.fr, 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 17:38:12 +0300

> 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?

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?

Message #26 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 17:43:36 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: 78861 <at> debbugs.gnu.org
> Date: Sun, 22 Jun 2025 16:08:37 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If the above is the best scenario you can offer, then please point me
> > to the code in calendar that first draws the numbers in black and then
> > redraws them in red, and I will take a look.
> 
> Thanks Eli.  I think most takes place in `diary-mark-entries' at
> diary-lib.el:1377.

Thanks.  Then I guess the problem is the calls to sit-for, which
performs redisplay, in calendar-generate-window before it calls
diary-mark-entries.  Any idea why we are calling sit-for there?  If
you remove those calls or add the optional second argument non-nil to
them, does the problem go away?

Message #29 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 18:22:15 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: 78861 <at> debbugs.gnu.org
>> Date: Sun, 22 Jun 2025 16:08:37 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > If the above is the best scenario you can offer, then please point me
>> > to the code in calendar that first draws the numbers in black and then
>> > redraws them in red, and I will take a look.
>> 
>> Thanks Eli.  I think most takes place in `diary-mark-entries' at
>> diary-lib.el:1377.
>
> Thanks.  Then I guess the problem is the calls to sit-for, which
> performs redisplay, in calendar-generate-window before it calls
> diary-mark-entries.  Any idea why we are calling sit-for there?  If
> you remove those calls or add the optional second argument non-nil to
> them, does the problem go away?

Thanks.  I have commented both sit-for and the issue completely goes
away.  I dig into history and those sit-for are here from ecaa0527104b
(the initial revision in 1992!)
-- 
Manuel Giraud

Message #32 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 21:13:23 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: 78861 <at> debbugs.gnu.org
> Date: Sun, 22 Jun 2025 18:22:15 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> >> Cc: 78861 <at> debbugs.gnu.org
> >> Date: Sun, 22 Jun 2025 16:08:37 +0200
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > If the above is the best scenario you can offer, then please point me
> >> > to the code in calendar that first draws the numbers in black and then
> >> > redraws them in red, and I will take a look.
> >> 
> >> Thanks Eli.  I think most takes place in `diary-mark-entries' at
> >> diary-lib.el:1377.
> >
> > Thanks.  Then I guess the problem is the calls to sit-for, which
> > performs redisplay, in calendar-generate-window before it calls
> > diary-mark-entries.  Any idea why we are calling sit-for there?  If
> > you remove those calls or add the optional second argument non-nil to
> > them, does the problem go away?
> 
> Thanks.  I have commented both sit-for and the issue completely goes
> away.  I dig into history and those sit-for are here from ecaa0527104b
> (the initial revision in 1992!)

Can you (or anyone else) think of any reasons to have these sit-for
calls there?  For example, when there's no need to call
diary-mark-entries at all?

If we can think of no valid reason, I think TRT is simply to remove
these calls.  It's possible that this was there for when Emacs had a
completely different way of fontifying buffers than what we have now.

Message #35 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: manuel <at> ledu-giraud.fr, 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Sun, 22 Jun 2025 23:55:41 +0200

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

Message #38 received at 78861 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78861 <at> debbugs.gnu.org
Subject: Re: bug#78861: [PATCH] Avoid calendar flicker
Date: Mon, 23 Jun 2025 09:50:23 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: 78861 <at> debbugs.gnu.org
>> Date: Sun, 22 Jun 2025 18:22:15 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> >> Cc: 78861 <at> debbugs.gnu.org
>> >> Date: Sun, 22 Jun 2025 16:08:37 +0200
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> > If the above is the best scenario you can offer, then please point me
>> >> > to the code in calendar that first draws the numbers in black and then
>> >> > redraws them in red, and I will take a look.
>> >> 
>> >> Thanks Eli.  I think most takes place in `diary-mark-entries' at
>> >> diary-lib.el:1377.
>> >
>> > Thanks.  Then I guess the problem is the calls to sit-for, which
>> > performs redisplay, in calendar-generate-window before it calls
>> > diary-mark-entries.  Any idea why we are calling sit-for there?  If
>> > you remove those calls or add the optional second argument non-nil to
>> > them, does the problem go away?
>> 
>> Thanks.  I have commented both sit-for and the issue completely goes
>> away.  I dig into history and those sit-for are here from ecaa0527104b
>> (the initial revision in 1992!)
>
> Can you (or anyone else) think of any reasons to have these sit-for
> calls there?  For example, when there's no need to call
> diary-mark-entries at all?

Both sit-for are guarded behind a `in-calendar-window' meaning that the
window-buffer is the calendar buffer.  So maybe the explanation for
those sit-for was to have some interactive visual feed back when
activating marks of diary entries.  But now that we could end up calling
`dairy-mark-entries' when we scroll this just creates too much flicker,
IMO.

> If we can think of no valid reason, I think TRT is simply to remove
> these calls.  It's possible that this was there for when Emacs had a
> completely different way of fontifying buffers than what we have now.

Here is an updated patch that removes those sit-for.

[0001-Avoid-flicker-when-marking-diary-entries-bug-78861.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Manuel Giraud

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.