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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
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 10:52:35 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: manuel <at> ledu-giraud.fr,  78120 <at> debbugs.gnu.org
> Date: Sat, 10 May 2025 08:59:23 +0200
> 
> 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?

I don't know the answer.  someone who knows better what calendar and
diary does with overlays should answer that.  But up front, I find
this unlikely, because if it did happen frequently enough, we'd have
bug reports about that already.

> What would be a reasonable estimation of importance in this case?

First, as we already decided, which overlay has higher priority is not
very important, since the intent is to produce deterministic results.

And second, I think we should only ask this question if the situation
you envision really happens.

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

A face that wants to specify only the foreground or background color
should specify only that.  I don't understand why the face is
initialized from default, perhaps some technical convenience (when no
face attributes are specified)?  But that should be easily solvable,
since faces implicitly inherit from default anyway.

Previous Next

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