GNU bug report logs - #78120
31.0.50; Calendar is not reliable with its marking

Previous Next

Full log

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: manuel <at> ledu-giraud.fr, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Sat, 10 May 2025 08:59:23 +0200

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

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

> How many places that create overlays are there in calendar and
> diary-lib?  My suggestion is to assign a priority to each one of these
> overlays, based on some reasonable estimation of their importance.  If
> that is impossible, I'd need to see the detailed explanation why not.

Allow me to add another important aspect first: Isn't it quite as
likely, or even more likely, that the user has conflicting overlays
specifying different faces but coming from the _same_ "source" - e.g.,
multiple diary sexp entries matching the same date?  What would be a
reasonable estimation of importance in this case?  I am using more or
less only diary sexps myself - although I don't use calendar marking
much (I use the org agenda instead).


BTW, I tested the [foreground:red] specs for the overlays a bit and had
a look at the implementation.  It uses exactly the same mechanism as
when face names are specified, and the "merging" of the properties is
done by the display engine, not explicitly in the Elisp code.  The code
defines temporary helper faces for that purpose, and uses these for the
overlays.  These faces get the according properties.

There is one issue we should fix, however: this merging doesn't work for
foreground and background.  You get the same behavior as with
conflicting faces.  This happens because the temporary faces the code
uses initialize the face using the `default' face.  And that face
doesn't have an empty foreground nor an empty background.  I think we
should initialize those properties void instead.  Here is the test case:

[diary (application/octet-stream, inline)]

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

Michael.

Previous Next

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