Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 78861@debbugs.gnu.org >> Date: Sun, 22 Jun 2025 18:22:15 +0200 >> >> Eli Zaretskii writes: >> >> >> From: Manuel Giraud >> >> Cc: 78861@debbugs.gnu.org >> >> Date: Sun, 22 Jun 2025 16:08:37 +0200 >> >> >> >> Eli Zaretskii 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.