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

Previous Next

To reply to this bug, email your comments to 78120 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: 31.0.50; Calendar is not reliable with its marking
Date: Mon, 28 Apr 2025 16:47:31 +0200

Hi,

It seems that the calendar is not reliable with its marking of diary
events.  Here is a recipe:

    1) emacs -Q

    2) Open the file "/tmp/diary", fill it with the following
       contents and save:
--8<---------------cut here---------------start------------->8---
%%(diary-block 5 4 2025 5 4 2025 'success) Success
May 4 2025 Good day
--8<---------------cut here---------------end--------------->8---

    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
       fourth of May has not always the same color.

Maybe this is a limitation of overlays but when I tried to test
(lightly) with overlapping overlays the visual results were always the
same.


In GNU Emacs 31.0.50 (build 11, x86_64-unknown-openbsd7.7, X toolkit) of
 2025-04-28 built on computer
Repository revision: c801856820c17247416846ac565b81268b4aca16
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: OpenBSD computer 7.7 GENERIC.MP#626 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=lucid
 --with-toolkit-scroll-bars=no --without-cairo
 --without-compress-install'

Configured features:
DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF
LIBXML2 M17N_FLT MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS
TIFF TREE_SITTER WEBP X11 XAW3D XDBE XFT XIM XINERAMA XINPUT2 XPM XRANDR
LUCID ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Elisp/l

Minor modes in effect:
  debbugs-browse-mode: t
  bug-reference-prog-mode: t
  display-time-mode: t
  display-battery-mode: t
  desktop-save-mode: t
  exwm-randr-mode: t
  server-mode: t
  electric-pair-mode: t
  override-global-mode: t
  repeat-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/manuel/prog/elisp/exwm/exwm hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm
/home/manuel/prog/elisp/exwm/exwm-xsettings hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-xsettings
/home/manuel/prog/elisp/exwm/exwm-xim hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-xim
/home/manuel/prog/elisp/exwm/exwm-workspace hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-workspace
/home/manuel/prog/elisp/exwm/exwm-randr hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-randr
/home/manuel/prog/elisp/exwm/exwm-manage hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-manage
/home/manuel/prog/elisp/exwm/exwm-layout hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-layout
/home/manuel/prog/elisp/exwm/exwm-input hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-input
/home/manuel/prog/elisp/exwm/exwm-floating hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-floating
/home/manuel/prog/elisp/exwm/exwm-systemtray hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-systemtray
/home/manuel/prog/elisp/exwm/exwm-core hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-core
/home/manuel/prog/elisp/exwm/exwm-background hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-background
/home/manuel/.emacs.d/elpa/ef-themes-1.9.0/theme-loaddefs hides /home/manuel/emacs/share/emacs/31.0.50/lisp/theme-loaddefs
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlwave hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlwave
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-toolbar hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-toolbar
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-shell hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-shell
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-help hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-help
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-complete-structtag hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-complete-structtag

Features:
(shadow sort mail-extr ispell emacsbug lisp-mnt org-agenda hi-lock
tex-mode slime-asdf grep slime-tramp tramp trampver tramp-integration
tramp-message tramp-compat shell tramp-loaddefs slime-fancy
slime-indentation slime-cl-indent cl-indent slime-trace-dialog
slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree advice slime-scratch slime-presentations
slime-macrostep slime-mdot-fu slime-enclosing-context slime-fuzzy
slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse slime
apropos etags fileloop xref arc-mode archive-mode hyperspec
semantic/wisent/grammar semantic/bovine semantic/grammar help-fns
radix-tree semantic/idle semantic/analyze semantic/sort semantic/scope
semantic/analyze/fcn semantic/db semantic/grammar-wy semantic/format
semantic/tag-ls semantic/find semantic/ctxt semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet on-screen
make-mode flymake compile view python project macrostep-c cmacexp
macrostep org-indent oc-basic org-element org-persist org-id
org-element-ast inline avl-tree generator ol-eww eww vtable mule-util
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
ol-docview ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi cus-start
gnus-icalendar org-capture org-refile org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src sh-script smie treesit executable
ob-comint org-pcomplete pcomplete comint ansi-osc ansi-color org-list
org-footnote org-faces org-entities org-version ob-emacs-lisp ob-core
ob-eval org-cycle org-table ol rx org-fold org-fold-core org-keys oc
org-loaddefs org-compat org-macs format-spec doc-view filenotify
jka-compr image-mode exif emacs-news-mode noutline outline texinfo
texinfo-loaddefs gnus-dired vc-dir ewoc vc-hg vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs log-view log-edit add-log pcvs-util vc-git
diff-mode track-changes files-x vc vc-dispatcher debbugs-browse
bug-reference time battery desktop frameset exwm-randr xcb-randr exwm
exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor
xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb
xcb-xproto xcb-types xcb-debug server ef-themes
modus-operandi-tinted-theme modus-themes zone speed-type dash thingatpt
url-http url-auth url-gw nsm compat ytdious ring mpdired transmission
color calc-bin calc-ext calc calc-loaddefs rect calc-macs supercite regi
ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int gnus-range
gnus-win ebdb-message message yank-media puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 gmm-utils mailheader ebdb-mua ebdb-com crm ebdb-format ebdb
mailabbrev eieio-opt speedbar ezimage dframe find-func eieio-base
timezone icalendar gnus nnheader gnus-util text-property-search
time-date range sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils erlang-start idlwave idlwave-menus idlw-menus
idlwave-bindings idlw-bindings idlwave-routine idlw-routine idlwave-scan
idlw-scan idlwave-help idlw-help idlwave-complete idlw-complete
idlwave-variables idlw-variables skeleton cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs elec-pair
appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs pcase
dired-x dired-aux dired dired-loaddefs edmacro kmacro
use-package-bind-key bind-key use-package-core repeat easy-mmode
cus-edit pp cus-load wid-edit debbugs-autoloads ebdb-autoloads cl-extra
help-mode ef-themes-autoloads elpher-autoloads exwm-autoloads
gnuplot-autoloads hyperbole-autoloads kotl-autoloads hact set hhist
idlwave-autoloads notmuch-autoloads on-screen-autoloads osm-autoloads
pdf-tools-autoloads rust-mode-autoloads slime-autoloads warnings
macrostep-autoloads speed-type-autoloads info dash-autoloads
sudo-edit-autoloads svg-clock-autoloads tablist-autoloads
transmission-autoloads xelb-autoloads ytdious-autoloads package
browse-url xdg url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind kqueue lcms2
dynamic-setting system-font-setting font-render-setting x-toolkit
xinput2 x multi-tty move-toolbar make-network-process tty-child-frames
emacs)

Memory information:
((conses 16 871923 625139) (symbols 48 58118 33)
 (strings 32 264513 42046) (string-bytes 1 6710222)
 (vectors 16 158873) (vector-slots 8 2162459 45731) (floats 8 605 217)
 (intervals 56 18132 128) (buffers 992 122))

-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Sat, 03 May 2025 12:08:02 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Date: Mon, 28 Apr 2025 16:47:31 +0200
> 
> 
> It seems that the calendar is not reliable with its marking of diary
> events.  Here is a recipe:
> 
>     1) emacs -Q
> 
>     2) Open the file "/tmp/diary", fill it with the following
>        contents and save:
> --8<---------------cut here---------------start------------->8---
> %%(diary-block 5 4 2025 5 4 2025 'success) Success
> May 4 2025 Good day
> --8<---------------cut here---------------end--------------->8---
> 
>     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
>        fourth of May has not always the same color.
> 
> Maybe this is a limitation of overlays but when I tried to test
> (lightly) with overlapping overlays the visual results were always the
> same.

Thanks, but could you please describe the issue in more detail?  We
don't have an active maintainer of diary-lib, but you seem to imply
that there's some more basic issue with overlays here?  can you
elaborate on that, and perhaps show some Lisp that is not specific to
diary-lib?

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Sat, 03 May 2025 13:41:22 +0200

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

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Date: Mon, 28 Apr 2025 16:47:31 +0200
>> 
>> 
>> It seems that the calendar is not reliable with its marking of diary
>> events.  Here is a recipe:
>> 
>>     1) emacs -Q
>> 
>>     2) Open the file "/tmp/diary", fill it with the following
>>        contents and save:
>> --8<---------------cut here---------------start------------->8---
>> %%(diary-block 5 4 2025 5 4 2025 'success) Success
>> May 4 2025 Good day
>> --8<---------------cut here---------------end--------------->8---
>> 
>>     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
>>        fourth of May has not always the same color.
>> 
>> Maybe this is a limitation of overlays but when I tried to test
>> (lightly) with overlapping overlays the visual results were always the
>> same.
>
> Thanks, but could you please describe the issue in more detail?  We
> don't have an active maintainer of diary-lib, but you seem to imply
> that there's some more basic issue with overlays here?  can you
> elaborate on that, and perhaps show some Lisp that is not specific to
> diary-lib?

No I think that overlays are correct and that the calendar marking is
doing something wrong™.  I think I have a better example.  Consider the
recipe above but this time with following contents in /tmp/diary:

--8<---------------cut here---------------start------------->8---
%%(diary-block 5 4 2025 5 4 2025 '(:background "lightgrey")) Success
May 4 2025 Good day
--8<---------------cut here---------------end--------------->8---

When you repeatedly hit 'm' in the calendar, you'll see that sometimes
the foreground of the '4' is highlighted and sometimes it is not.

Now consider the following code:
--8<---------------cut here---------------start------------->8---
(defun foo ()
  (interactive)
  (remove-overlays)
  (let* ((start 1)
	 (fore (make-overlay start (+ start 4)))
	 (back (make-overlay start (+ start 4))))
    (overlay-put fore 'face 'error)
    (overlay-put back 'face '(:background "lightgrey"))))

(local-set-key (kbd "m") 'foo)
--8<---------------cut here---------------end--------------->8---

If you evaluate those two forms in a test buffer and hit 'm' repeatedly,
the overlays are always correct: an error face on light grey background.
-- 
Manuel Giraud

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

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

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> >>     1) emacs -Q
> >> 
> >>     2) Open the file "/tmp/diary", fill it with the following
> >>        contents and save:
> >> --8<---------------cut here---------------start------------->8---
> >> %%(diary-block 5 4 2025 5 4 2025 'success) Success
> >> May 4 2025 Good day
> >> --8<---------------cut here---------------end--------------->8---
> >> 
> >>     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
> >>        fourth of May has not always the same color.

I tried your recipe but were not able to reproduce what you describe.
C-u C-x = always reports exactly one overlay at a marked date, no
matter how often I hit m.  I don't know why you see this in emacs -Q.

Michael.

Message #17 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: Sun, 04 May 2025 08:28:42 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78120 <at> debbugs.gnu.org
> Date: Sun, 04 May 2025 04:03:41 +0200
> 
> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
> 
> > >>     1) emacs -Q
> > >> 
> > >>     2) Open the file "/tmp/diary", fill it with the following
> > >>        contents and save:
> > >> --8<---------------cut here---------------start------------->8---
> > >> %%(diary-block 5 4 2025 5 4 2025 'success) Success
> > >> May 4 2025 Good day
> > >> --8<---------------cut here---------------end--------------->8---
> > >> 
> > >>     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
> > >>        fourth of May has not always the same color.
> 
> I tried your recipe but were not able to reproduce what you describe.
> C-u C-x = always reports exactly one overlay at a marked date, no
> matter how often I hit m.  I don't know why you see this in emacs -Q.

I can reproduce this.  I think the reason is simple: the above
scenario places 2 overlays on that date, each one of them specifying a
different face.  Type "M-x describe-text-properties" on that date, and
you will see it: one face is 'diary', the other 'success'.  One of
these overlays comes from diary-mark-sexp-entries, the other from
calendar-mark-visible-date.  Both overlays have the same (unspecified)
priority, so which one of them "wins" depends on many factors,
including the exact memory layout of the Emacs session.  The latter
changes each time you press 'm', so you sometimes see one or the other
face.

The solution is to decide which overlay should "win" in this case, and
give one of them higher or lower priority, as appropriate.

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Sun, 04 May 2025 12:22:41 +0200

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

>> From: Michael Heerdegen <michael_heerdegen <at> web.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78120 <at> debbugs.gnu.org
>> Date: Sun, 04 May 2025 04:03:41 +0200
>> 
>> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>> 
>> > >>     1) emacs -Q
>> > >> 
>> > >>     2) Open the file "/tmp/diary", fill it with the following
>> > >>        contents and save:
>> > >> --8<---------------cut here---------------start------------->8---
>> > >> %%(diary-block 5 4 2025 5 4 2025 'success) Success
>> > >> May 4 2025 Good day
>> > >> --8<---------------cut here---------------end--------------->8---
>> > >> 
>> > >>     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
>> > >>        fourth of May has not always the same color.
>> 
>> I tried your recipe but were not able to reproduce what you describe.
>> C-u C-x = always reports exactly one overlay at a marked date, no
>> matter how often I hit m.  I don't know why you see this in emacs -Q.
>
> I can reproduce this.  I think the reason is simple: the above
> scenario places 2 overlays on that date, each one of them specifying a
> different face.  Type "M-x describe-text-properties" on that date, and
> you will see it: one face is 'diary', the other 'success'.  One of
> these overlays comes from diary-mark-sexp-entries, the other from
> calendar-mark-visible-date.  Both overlays have the same (unspecified)
> priority, so which one of them "wins" depends on many factors,
> including the exact memory layout of the Emacs session.  The latter
> changes each time you press 'm', so you sometimes see one or the other
> face.

Ok, thanks for this explanation.

> The solution is to decide which overlay should "win" in this case, and
> give one of them higher or lower priority, as appropriate.

So I think we should have a way, with diary date, to set this priority.
-- 
Manuel Giraud

Message #23 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: Mon, 05 May 2025 02:45:37 +0200

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

> I can reproduce this.

Yes, I can...I can too, of course.  Yesterday was the date used in the
recipe so I thought it would be a good idea to change it but... anyway.

> I think the reason is simple: the above scenario places 2 overlays on
> that date, each one of them specifying a different face.  Type "M-x
> describe-text-properties" on that date, and you will see it: one face
> is 'diary', the other 'success'.  One of these overlays comes from
> diary-mark-sexp-entries, the other from calendar-mark-visible-date.

(`diary-mark-sexp-entries' calls `calendar-mark-visible-date'.  I think
the latter is used more or less everywhere in diary-lib to place the
overlays.)

> Both overlays have the same (unspecified) priority, so which one of
> them "wins" depends on many factors, including the exact memory layout
> of the Emacs session.  The latter changes each time you press 'm', so
> you sometimes see one or the other face.

Plausible. (Would it be thinkable to make the behavior deterministic?)

> The solution is to decide which overlay should "win" in this case, and
> give one of them higher or lower priority, as appropriate.

This might not be easy, though (I mean the "appropriate" part), since
there are multiple different places in diary-lib that mark dates.  And
of course there is also the problem of multiple matches of one source,
for example, multiple sexps matching the date that want to draw
different faces.


Michael.

Message #26 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: Mon, 05 May 2025 14:28:18 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: manuel <at> ledu-giraud.fr,  78120 <at> debbugs.gnu.org
> Date: Mon, 05 May 2025 02:45:37 +0200
> 
> > Both overlays have the same (unspecified) priority, so which one of
> > them "wins" depends on many factors, including the exact memory layout
> > of the Emacs session.  The latter changes each time you press 'm', so
> > you sometimes see one or the other face.
> 
> Plausible. (Would it be thinkable to make the behavior deterministic?)

It's deterministic.  But the factors affecting determinism are
sometimes not deterministic enough ;-)

> > The solution is to decide which overlay should "win" in this case, and
> > give one of them higher or lower priority, as appropriate.
> 
> This might not be easy, though (I mean the "appropriate" part), since
> there are multiple different places in diary-lib that mark dates.  And
> of course there is also the problem of multiple matches of one source,
> for example, multiple sexps matching the date that want to draw
> different faces.

So Someone™ should take a look at the faces and decide which one of
them is more important, or at least post the list here so we could
discuss based on that list.

Alternatively, we could change the default definition of one or more
faces, so that they don't conflict.  For example, instead of defining
only the foreground color, we could define the background or
underline, or weight or the box attributes.

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

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

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

>> From: Michael Heerdegen <michael_heerdegen <at> web.de>
>> Cc: manuel <at> ledu-giraud.fr,  78120 <at> debbugs.gnu.org
>> Date: Mon, 05 May 2025 02:45:37 +0200
>> 
>> > Both overlays have the same (unspecified) priority, so which one of
>> > them "wins" depends on many factors, including the exact memory layout
>> > of the Emacs session.  The latter changes each time you press 'm', so
>> > you sometimes see one or the other face.
>> 
>> Plausible. (Would it be thinkable to make the behavior deterministic?)
>
> It's deterministic.  But the factors affecting determinism are
> sometimes not deterministic enough ;-)

:-)

What seems strange to me is that I find overlays to be pretty
deterministic while the face features are different:
foreground/background/italic... (See my second recipe in this thread)

But in calendar, this seems less deterministic 🤷

[...]

> So Someone™ should take a look at the faces and decide which one of
> them is more important, or at least post the list here so we could
> discuss based on that list.

I think a better way would be to use the overlay priority and be able to
select from the diary date.
-- 
Manuel Giraud

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Tue, 06 May 2025 02:28:40 +0200

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> I think a better way would be to use the overlay priority and be able to
> select from the diary date.

What do you mean by "select from the diary date"?


Michael.

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

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>
>> I think a better way would be to use the overlay priority and be able to
>> select from the diary date.
>
> What do you mean by "select from the diary date"?

Sorry, I wasn't clear.  At least for diary dates entered in sexp forms,
one can add an optional face (or a mark string) like this:

%%(diary-anniversary 11 5 1955 'error) Marty arrives

So maybe, we could have another optional parameter to add an overlay
priority value.
-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: michael_heerdegen <at> web.de, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Tue, 06 May 2025 14:25:34 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78120 <at> debbugs.gnu.org
> Date: Tue, 06 May 2025 08:23:58 +0200
> 
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> 
> > Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
> >
> >> I think a better way would be to use the overlay priority and be able to
> >> select from the diary date.
> >
> > What do you mean by "select from the diary date"?
> 
> Sorry, I wasn't clear.  At least for diary dates entered in sexp forms,
> one can add an optional face (or a mark string) like this:
> 
> %%(diary-anniversary 11 5 1955 'error) Marty arrives
> 
> So maybe, we could have another optional parameter to add an overlay
> priority value.

IMO, it makes little sense to bother users with overlay priorities.
That's a highly technical issue, and defining a good value requires to
have intimate knowledge about the relevant features and functions.

Why cannot the priority come from the code itself?  If you are saying
that it is impossible to decide which face should haver precedence,
something that I find very surprising, then some kind of user option
that allows to set the priority of one overlay higher or lower than
the other (without actually asking users to provide the priority
itself) would make more sense.  But up front, I'd be very surprised to
hear that we are unable to make the correct decision without burdening
the users with these decisions.  If that is what you think, please try
to explain in detail why such a decision is impossible.  Surely, out
of the two faces one conveys information that is more important than
the other?

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Tue, 06 May 2025 19:50:00 +0200

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

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  78120 <at> debbugs.gnu.org
>> Date: Tue, 06 May 2025 08:23:58 +0200
>> 
>> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>> 
>> > Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>> >
>> >> I think a better way would be to use the overlay priority and be able to
>> >> select from the diary date.
>> >
>> > What do you mean by "select from the diary date"?
>> 
>> Sorry, I wasn't clear.  At least for diary dates entered in sexp forms,
>> one can add an optional face (or a mark string) like this:
>> 
>> %%(diary-anniversary 11 5 1955 'error) Marty arrives
>> 
>> So maybe, we could have another optional parameter to add an overlay
>> priority value.
>
> IMO, it makes little sense to bother users with overlay priorities.
> That's a highly technical issue, and defining a good value requires to
> have intimate knowledge about the relevant features and functions.
>
> Why cannot the priority come from the code itself?  If you are saying
> that it is impossible to decide which face should haver precedence,
> something that I find very surprising, then some kind of user option
> that allows to set the priority of one overlay higher or lower than
> the other (without actually asking users to provide the priority
> itself) would make more sense.  But up front, I'd be very surprised to
> hear that we are unable to make the correct decision without burdening
> the users with these decisions.  If that is what you think, please try
> to explain in detail why such a decision is impossible.  Surely, out
> of the two faces one conveys information that is more important than
> the other?

I don't really understand when you say that we could decide which face
will have precedence over another.  If you have a face that says
"foreground is red" and another one that says "foreground is blue" how
could we decide which one speaks the truth?

Or maybe you are talking about having a precedence defined on faces'
names?  But even then, for the diary, AFAIK we have 3 faces: diary,
diary-anniversary and holiday.  What should be their order of
importance?  I don't know.
-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: michael_heerdegen <at> web.de, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Tue, 06 May 2025 21:26:40 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: michael_heerdegen <at> web.de,  78120 <at> debbugs.gnu.org
> Date: Tue, 06 May 2025 19:50:00 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Why cannot the priority come from the code itself?  If you are saying
> > that it is impossible to decide which face should haver precedence,
> > something that I find very surprising, then some kind of user option
> > that allows to set the priority of one overlay higher or lower than
> > the other (without actually asking users to provide the priority
> > itself) would make more sense.  But up front, I'd be very surprised to
> > hear that we are unable to make the correct decision without burdening
> > the users with these decisions.  If that is what you think, please try
> > to explain in detail why such a decision is impossible.  Surely, out
> > of the two faces one conveys information that is more important than
> > the other?
> 
> I don't really understand when you say that we could decide which face
> will have precedence over another.  If you have a face that says
> "foreground is red" and another one that says "foreground is blue" how
> could we decide which one speaks the truth?

Each face has a meaning, I presume?  If one face marks a date because
John Doe was born at that day, and another face marks the same date
because I have an important meeting, then the latter should "win",
right?

> Or maybe you are talking about having a precedence defined on faces'
> names?

Not names, meanings.  The names here don't explain themselves: 'diary'
and 'success'.  If you know what those faces mean, please tell, and I
will try to suggest which one should win in this case.

> But even then, for the diary, AFAIK we have 3 faces: diary,
> diary-anniversary and holiday.  What should be their order of
> importance?  I don't know.

That's not our case.  Maybe there are more cases where we need to
decide, but let's first fix our case.  Then we could discuss other
cases.

(Up front, I'd say that 'diary' should override the others, but I'm
open to counter-arguments.)

Message #47 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 Giraud <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: Wed, 07 May 2025 00:44:33 +0200

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

> Each face has a meaning, I presume?  If one face marks a date because
> John Doe was born at that day, and another face marks the same date
> because I have an important meeting, then the latter should "win",
> right?

It depends?  If John doe is your husband, maybe he is much more
important and should "win".  Maybe you will have a free day at his
birthday anyway.

Or: if it's three weeks before that day, John's birthday is more
relevant, because I might need to buy presents.  But one day before that
date I have the presents and have been informed about the birthday, but
I want to be reminded about the meeting now.

So this is a good example of how difficult this is.  It totally depends
on your life and your circumstances.  Also, Emacs doesn't know what an
"important meeting" is, and who John Doe is.

And the same is true for other sources of highlighting.  Are holidays
important?  Depends on how religious you are etc.


> Not names, meanings.  The names here don't explain themselves: 'diary'
> and 'success'.  If you know what those faces mean, please tell, and I
> will try to suggest which one should win in this case.

Note: the success face had been specified in the diary file (see the
recipe).  The user can specify any face name in the file.  Emacs doesn't
know what these "mean".  The only thing Emacs can know is: was the entry
that caused the mark a normal diary entry, a sexp entry, or does the
mark come from some function or via a hook - with other words, a rough
category that doesn't tell much on it's own.

> (Up front, I'd say that 'diary' should override the others, but I'm
> open to counter-arguments.)

May suggestion: first, when Emacs tries to mark a date, and there is
already a mark, we use the existing overlay instead of placing multiple.

Then, a function, value of a new defcustom, is used to decide what face
to place in a conflict.  And I would introduce a new face that means
"multiple marks on this date" that it can use.

But more importantly, it would be good if the mouse over text would list
the entries for that day.  Much more useful than programming face
fights.  Just give me a hint that there are multiple things "on" that
date.  This feature (listing diary entries for the clicked date) is
already available by explicit request via the mouse-3 menu btw.


Michael.

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

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Each face has a meaning, I presume?  If one face marks a date because
>> John Doe was born at that day, and another face marks the same date
>> because I have an important meeting, then the latter should "win",
>> right?
>
> It depends?  If John doe is your husband, maybe he is much more
> important and should "win".  Maybe you will have a free day at his
> birthday anyway.
>
> Or: if it's three weeks before that day, John's birthday is more
> relevant, because I might need to buy presents.  But one day before that
> date I have the presents and have been informed about the birthday, but
> I want to be reminded about the meeting now.
>
> So this is a good example of how difficult this is.  It totally depends
> on your life and your circumstances.  Also, Emacs doesn't know what an
> "important meeting" is, and who John Doe is.
>
> And the same is true for other sources of highlighting.  Are holidays
> important?  Depends on how religious you are etc.

Thanks Michael for this detailed explanation.  That was exactly the kind
of complications I also imaged and this is why I suggest having a way
for the user to set this "priority/importance".

>> Not names, meanings.  The names here don't explain themselves: 'diary'
>> and 'success'.  If you know what those faces mean, please tell, and I
>> will try to suggest which one should win in this case.
>
> Note: the success face had been specified in the diary file (see the
> recipe).  The user can specify any face name in the file.  Emacs doesn't
> know what these "mean".  The only thing Emacs can know is: was the entry
> that caused the mark a normal diary entry, a sexp entry, or does the
> mark come from some function or via a hook - with other words, a rough
> category that doesn't tell much on it's own.
>
>> (Up front, I'd say that 'diary' should override the others, but I'm
>> open to counter-arguments.)
>
> May suggestion: first, when Emacs tries to mark a date, and there is
> already a mark, we use the existing overlay instead of placing
> multiple.

This may be a good idea but overlapping overlays can handle some cases
very well: for example, it combines correctly a face that sets a certain
foreground color and 'italic.  So in such case, we could have two pieces
of information.

> Then, a function, value of a new defcustom, is used to decide what face
> to place in a conflict.  And I would introduce a new face that means
> "multiple marks on this date" that it can use.

Ok, but then it is up to the user to write such a function.  It is, of
course, a more flexible interface but also a harder one: the user need
to write lisp instead choosing some "priority" values.  And also, it
does not prevent us from having a default function for this custom:
we're back to square one ;-)

> But more importantly, it would be good if the mouse over text would list
> the entries for that day.  Much more useful than programming face
> fights.  Just give me a hint that there are multiple things "on" that
> date.  This feature (listing diary entries for the clicked date) is
> already available by explicit request via the mouse-3 menu btw.

Yes, this feature is already available (via 'diary-view-entries').  It
is just not a hover.
-- 
Manuel Giraud

Message #53 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: Wed, 07 May 2025 14:44:06 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>,  78120 <at> debbugs.gnu.org
> Date: Wed, 07 May 2025 00:44:33 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Each face has a meaning, I presume?  If one face marks a date because
> > John Doe was born at that day, and another face marks the same date
> > because I have an important meeting, then the latter should "win",
> > right?
> 
> It depends?  If John doe is your husband, maybe he is much more
> important and should "win".  Maybe you will have a free day at his
> birthday anyway.

While these situations are possible, I think they are quite rare in
practice.  So while today we have this problem in all the cases, with
the change I propose we will have it only rarely: a clear "win", IMO.

I also made another suggestion: to change the default definition of
some of the faces so that they don't all use the same face attribute.
Then we could fix this problem even cleaner, IMO.  But no one
responded to that suggestion, and I wonder why.

> So this is a good example of how difficult this is.  It totally depends
> on your life and your circumstances.  Also, Emacs doesn't know what an
> "important meeting" is, and who John Doe is.

We usually solve this for the most probable situation, and leave the
rest to user customizations of the faces.  It isn't the first time we
bump into this problem.

Moreover, to reason about this in a useful way, we need a list of
faces that could conflict and their semantics.  AFAICT, no one posted
such a list.  So for now we are having an almost purely academic
discussion, without even knowing how many faces could conflict in this
way.

So I think you reject this kind of solution too early.

> And the same is true for other sources of highlighting.  Are holidays
> important?  Depends on how religious you are etc.

If indeed you are right, and the importance is frequently inverted
(and I'm not yet sure you are right), then we could provide user
options for resolving the conflicts.  But such user options should not
be overlay priorities, but something like "face importance", from
which the code should derive the priorities.  Asking users to provide
priorities themselves is not user-friendly, for the reasons I
explained up-thread.

> > Not names, meanings.  The names here don't explain themselves: 'diary'
> > and 'success'.  If you know what those faces mean, please tell, and I
> > will try to suggest which one should win in this case.
> 
> Note: the success face had been specified in the diary file (see the
> recipe).  The user can specify any face name in the file.  Emacs doesn't
> know what these "mean".  The only thing Emacs can know is: was the entry
> that caused the mark a normal diary entry, a sexp entry, or does the
> mark come from some function or via a hook - with other words, a rough
> category that doesn't tell much on it's own.

I think the other face has a more clear semantics, and the face
specified by the user also has semantics, albeit a more vague one.  So
this kind of solutions could still be possible.

> > (Up front, I'd say that 'diary' should override the others, but I'm
> > open to counter-arguments.)
> 
> May suggestion: first, when Emacs tries to mark a date, and there is
> already a mark, we use the existing overlay instead of placing multiple.
> 
> Then, a function, value of a new defcustom, is used to decide what face
> to place in a conflict.  And I would introduce a new face that means
> "multiple marks on this date" that it can use.

That's possible, yes.  We could also use this special case with two
overlays, but in case where we decide to use this special case we
could also make its overlay priority higher.  The result will be the
same.

The solution you propose might cause complications, because removing
the overlay will effectively remove both marks.  I don't know
diary-lib enough to tell whether this is a real problem.

> But more importantly, it would be good if the mouse over text would list
> the entries for that day.  Much more useful than programming face
> fights.  Just give me a hint that there are multiple things "on" that
> date.  This feature (listing diary entries for the clicked date) is
> already available by explicit request via the mouse-3 menu btw.

We could, of course, add this, and it would be useful on its own
right, but don't forget that Emacs can work without a mouse.  In any
case, I think this is almost orthogonal to the issue at hand.

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Wed, 07 May 2025 16:39:00 +0200

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

>> From: Michael Heerdegen <michael_heerdegen <at> web.de>
>> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>,  78120 <at> debbugs.gnu.org
>> Date: Wed, 07 May 2025 00:44:33 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Each face has a meaning, I presume?  If one face marks a date because
>> > John Doe was born at that day, and another face marks the same date
>> > because I have an important meeting, then the latter should "win",
>> > right?
>> 
>> It depends?  If John doe is your husband, maybe he is much more
>> important and should "win".  Maybe you will have a free day at his
>> birthday anyway.
>
> While these situations are possible, I think they are quite rare in
> practice.  So while today we have this problem in all the cases, with
> the change I propose we will have it only rarely: a clear "win", IMO.
>
> I also made another suggestion: to change the default definition of
> some of the faces so that they don't all use the same face attribute.
> Then we could fix this problem even cleaner, IMO.  But no one
> responded to that suggestion, and I wonder why.
>
>> So this is a good example of how difficult this is.  It totally depends
>> on your life and your circumstances.  Also, Emacs doesn't know what an
>> "important meeting" is, and who John Doe is.
>
> We usually solve this for the most probable situation, and leave the
> rest to user customizations of the faces.  It isn't the first time we
> bump into this problem.
>
> Moreover, to reason about this in a useful way, we need a list of
> faces that could conflict and their semantics.  AFAICT, no one posted
> such a list.  So for now we are having an almost purely academic
> discussion, without even knowing how many faces could conflict in this
> way.

AFAICT, for calendar, we have diary, calendar-today, holiday and
diary-anniversary with the following default definitions:

--8<---------------cut here---------------start------------->8---
(defface calendar-today
  '((t (:underline t)))
  "Face for indicating today's date in the calendar.
See the variable `calendar-today-marker'."
  :group 'calendar-faces)

(defface diary
  '((((min-colors 88) (class color) (background light))
     :foreground "red1")
    (((class color) (background light))
     :foreground "red")
    (((min-colors 88) (class color) (background dark))
     :foreground "yellow1")
    (((class color) (background dark))
     :foreground "yellow")
    (t
     :weight bold))
  "Face for highlighting diary entries.
Used to mark diary entries in the calendar (see `diary-entry-marker'),
and to highlight the date header in the fancy diary."
  :group 'calendar-faces)

(defface holiday
  '((((class color) (background light))
     :background "pink")
    (((class color) (background dark))
     :background "chocolate4")
    (t
     :inverse-video t))
  "Face for indicating in the calendar dates that have holidays.
See `calendar-holiday-marker'."
  :group 'calendar-faces)

(defface diary-anniversary '((t :inherit font-lock-keyword-face))
  "Face used for anniversaries in the fancy diary display."
  :version "22.1"
  :group 'calendar-faces)
--8<---------------cut here---------------end--------------->8---

From this list, I think that only diary and diary-anniversary would
conflict as they both set the foreground… but as all those faces could
be customized by a theme, we could have conflicts at a later time.  For
example: modus themes also use the foreground for holiday so it adds a
new conflict with diary and diary-anniversary.

> So I think you reject this kind of solution too early.
>
>> And the same is true for other sources of highlighting.  Are holidays
>> important?  Depends on how religious you are etc.
>
> If indeed you are right, and the importance is frequently inverted
> (and I'm not yet sure you are right), then we could provide user
> options for resolving the conflicts.  But such user options should not
> be overlay priorities, but something like "face importance", from
> which the code should derive the priorities.  Asking users to provide
> priorities themselves is not user-friendly, for the reasons I
> explained up-thread.

Yes, we could have a set of diary faces like the set of
gnus-group-mail-* faces, for example.
-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: michael_heerdegen <at> web.de, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Wed, 07 May 2025 19:06:43 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  78120 <at> debbugs.gnu.org
> Date: Wed, 07 May 2025 16:39:00 +0200
> 
> > Moreover, to reason about this in a useful way, we need a list of
> > faces that could conflict and their semantics.  AFAICT, no one posted
> > such a list.  So for now we are having an almost purely academic
> > discussion, without even knowing how many faces could conflict in this
> > way.
> 
> AFAICT, for calendar, we have diary, calendar-today, holiday and
> diary-anniversary with the following default definitions:

Thanks.  But I don't see here that 'success' face which caused the
original trouble.  Or am I missing something.

> >From this list, I think that only diary and diary-anniversary would
> conflict as they both set the foreground…

Then I think the problem is easy: 'diary' should take precedence over
'diary-anniversary', because in most cases the latter is more
"routine" than the former.

We could also modify one of those to not use the foreground color, but
instead to use 'bold' or 'italic'.

> but as all those faces could
> be customized by a theme, we could have conflicts at a later time.  For
> example: modus themes also use the foreground for holiday so it adds a
> new conflict with diary and diary-anniversary.

This is a problem for theme authors to solve, they should be aware of
the issue and choose the faces accordingly.

Message #62 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 Giraud <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: Thu, 08 May 2025 07:00:18 +0200

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

> Thanks.  But I don't see here that 'success' face which caused the
> original trouble.  Or am I missing something.

You miss what I already answered: that you can specify arbitrary faces
in the diary itself.  See the original recipe.

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.


Michael.

Message #65 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: Thu, 08 May 2025 09:54:15 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>,  78120 <at> debbugs.gnu.org
> 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.  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.

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

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

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

>> From: Michael Heerdegen <michael_heerdegen <at> web.de>
>> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>,  78120 <at> debbugs.gnu.org
>> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: michael_heerdegen <at> web.de, 78120 <at> debbugs.gnu.org
Subject: Re: bug#78120: 31.0.50; Calendar is not reliable with its marking
Date: Thu, 08 May 2025 18:37:36 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  78120 <at> debbugs.gnu.org
> Date: Thu, 08 May 2025 16:03:56 +0200
> 
> 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).

Overlays are a display-time feature, so of course it's related to
redisplay.  It's redisplay that decides which of the overlays to show
when several of them "compete".

And if some Lisp sets up a hook that moves overlays, then you'll have
an immediate additional redisplay cycle, which might be what you see.

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

I'm not talking about what _could_ be, I'm talking about what happens
in the majority of cases.

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

What I said doesn't contradict the user's ability to affect the faces.
I'm just expressing an opinion about which overlay should by default
have the higher priority.  Surely, we need to make a decision like
that if we want the results to be completely deterministic?

Message #74 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: Fri, 09 May 2025 06:05:36 +0200

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

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

Absolutely - after somebody has tested it a bit.  Could maybe Manuel do
that?

> Still, I think the faces produced from sexp entities should take
> precedent (via overlay priorities) over the other faces, as the
> default.

Not better than any other random choice, IMO.  An entry being a sexp
entry only means that the date is complicated to describe, not that the
entry is more important.


Michael.

Message #77 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: Fri, 09 May 2025 09:38:08 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: manuel <at> ledu-giraud.fr,  78120 <at> debbugs.gnu.org
> Date: Fri, 09 May 2025 06:05:36 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Still, I think the faces produced from sexp entities should take
> > precedent (via overlay priorities) over the other faces, as the
> > default.
> 
> Not better than any other random choice, IMO.  An entry being a sexp
> entry only means that the date is complicated to describe, not that the
> entry is more important.

Maybe so, but since we do have to make a (possibly arbitrary) decision
about the priorities, to make the results deterministic, we could as
well use what I suggested (or any other, really).

Message #80 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 Giraud <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: Fri, 09 May 2025 08:57:58 +0200

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

> Surely, we need to make a decision like that if we want the results to
> be completely deterministic?

I wonder how that could be done.  There are a lot of possible sources of
marks besides diary entries (look for functions calling
`calendar-mark-visible-date', for example).  Marks can also come from
user functions.  Most of these can use arbitrary faces (the diary face
is only a fallback) - and at least some of them are allowed to specify
only attributes that should stack.  If you really intend to invent some
kind of hierarchy to solve this, this will be a very complicated thing.


Michael.

Message #83 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: Fri, 09 May 2025 09:01:28 +0200

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

> Maybe so, but since we do have to make a (possibly arbitrary) decision
> about the priorities, to make the results deterministic, we could as
> well use what I suggested (or any other, really).

Ok.  So we could also just keep the first, or the last, and throw away
the rest?

And I really would like to understand how the [foo:value] spec is
implemented, hope I get the time tomorrow.  We should not mess that up
while fixing this problem.


Michael.

Message #86 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: Fri, 09 May 2025 10:47:57 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Manuel Giraud <manuel <at> ledu-giraud.fr>,  78120 <at> debbugs.gnu.org
> Date: Fri, 09 May 2025 08:57:58 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Surely, we need to make a decision like that if we want the results to
> > be completely deterministic?
> 
> I wonder how that could be done.  There are a lot of possible sources of
> marks besides diary entries (look for functions calling
> `calendar-mark-visible-date', for example).  Marks can also come from
> user functions.  Most of these can use arbitrary faces (the diary face
> is only a fallback) - and at least some of them are allowed to specify
> only attributes that should stack.  If you really intend to invent some
> kind of hierarchy to solve this, this will be a very complicated thing.

The priorities are per overlay, not per face.

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.

Message #89 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: Fri, 09 May 2025 10:49:07 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: manuel <at> ledu-giraud.fr,  78120 <at> debbugs.gnu.org
> Date: Fri, 09 May 2025 09:01:28 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Maybe so, but since we do have to make a (possibly arbitrary) decision
> > about the priorities, to make the results deterministic, we could as
> > well use what I suggested (or any other, really).
> 
> Ok.  So we could also just keep the first, or the last, and throw away
> the rest?

Sorry, you lost me: "first" and "last" what?

Message #92 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: Fri, 09 May 2025 10:23:46 +0200

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

> Sorry, you lost me: "first" and "last" what?

Of the overlays.  We could just place one overlay, and do nothing if
there already is one.  Or replace existing overlays with a new one.  So
that there is always a maximum of one overlay.  That should be enough
for a deterministic display.

Dunno yet what I would prefer.


Michael.

Message #95 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: Fri, 09 May 2025 13:39:22 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: manuel <at> ledu-giraud.fr,  78120 <at> debbugs.gnu.org
> Date: Fri, 09 May 2025 10:23:46 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Sorry, you lost me: "first" and "last" what?
> 
> Of the overlays.  We could just place one overlay, and do nothing if
> there already is one.  Or replace existing overlays with a new one.  So
> that there is always a maximum of one overlay.  That should be enough
> for a deterministic display.

You raised this earlier, and I replied then: having just one overlay
has its downsides.  I think those downsides outweigh the advantages.

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.

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.