Subject: bug#78120: 31.0.50; Calendar is not reliable with its marking

From: Manuel Giraud <[email-masked]>
Date: Thu, 08 May 2025 16:03:56 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Michael Heerdegen <[email-masked]>
>> Cc: Manuel Giraud <[email-masked]>,  [email-masked]
>> Date: Thu, 08 May 2025 07:00:18 +0200
>> 
>> But one step back, please listen: I rediscovered the (completely
>> undocumented, AFAICT) solution diary-lib itself already provides to
>> avoid this problem.  Read around line number 74:
>> 
>> ;; Face markup of calendar and diary displays: Any entry line that
>> ;; ends with [foo:value] where foo is a face attribute (except :box
>> ;; :stipple) or with [face:blah] tags, will have these values applied
>> ;; to the calendar and fancy diary displays.  These attributes "stack"
>> ;; on calendar displays.  File-wide attributes can be defined as
>> ;; follows: the first line matching "^# [tag:value]" defines the value
>> ;; for that particular tag.
>> 
>> So this is obviously the user level mechanism the diary-lib author(s)
>> intended to be used for more advanced stylistic tuning.
>> 
>> Of course we can still bring the standard faces in some well defined
>> order, but if the described mechanism works well, it deserves to be made
>> more discover able I think.  It is more or less what Manuel was asking
>> for.
>
> The original report was that the results were not deterministic.

Yes.  I think we somewhat diverge a bit from the original issue which
was the non deterministic behaviour (but thanks Michael for digging out
these informations!)  Just to be sure, here's an updated recipe that
shows this:

    1) emacs -Q

    2) Open the file "/tmp/diary", fill it with the following
       contents and save:

%%(diary-block 5 4 2025 5 10 2025 '(:background "lightgrey")) Success
May 7 2025 Good day

    3) M-: (use-package diary-lib :custom (diary-file "/tmp/diary")) 

    4) M-x calendar

    5) Hit 'm' (diary-mark-entries) a few times.  Observe that the
       seventh of May has not always the same foreground color.

BTW, I wonder it this can be related to redisplay since when hitting 'm'
repeatedly, I see a flicker that was not present on my example with
overlays (above in this thread).

> I think we can make them deterministic by specifying certain
> priorities for each overlay.  If it turns out that the priorities we
> specify don't produce the effect that some user wants, they could then
> use the other face attributes, as you explain above (but maybe we
> should document this facility in the user manual?).
>
> Still, I think the faces produced from sexp entities should take
> precedent (via overlay priorities) over the other faces, as the
> default.

I don't understand why you think so: a sexp entity could be of a lesser
importance than a non-sexp one. For example:

%%(diary-block 5 4 2025 5 10 2025) School break
May 8 2025 Important work meeting

That is why, regardless of the non-deterministic issue, I think that the
user should have a way to express what is more important than something
else.
-- 
Manuel Giraud