bug#49995: 28.0.50; EBDB Anniversaries do not appear marked in calendar

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 08/15/21 15:18 PM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Okay, here's a version of how it might work. I've learned a little bit
>> more about the diary (and as a result will likely use it more! I'd
>> always thought it was just a poor cousin to Org, but I see it has its
>> own strengths), and have a solution that is a bit funky, but might be
>> okay.
>
> Looks quite good.

Thanks for checking!

> I would try to get rid of `diary-anniversary'.  All it does is checking
> the date and calling `format' - things that you already do.  You now
> effectively get `eval' inside `eval' when calling `diary', you have an
> extra layer.  I hope removing that will also get rid of the need to look
> at `original-date'.
>
> [BTW: The only nontrivial thing `diary-anniversary' does is handling of
> birthdays on 2/28, you may want to have a look if you need to handle
> that case specially.]

It seems to me that it isn't `diary-anniversary' that needs to be gotten
rid of, so much as `diary-sexp-entry' -- that's the function that's
basically just eval'ling a string. If I get rid of `diary-anniversary',
I'll basically just end up re-writing it.

At init time, instead of building up strings, I could just build up
closures holding the appropriate dynamic value for DATE and ENTRY, and
calling `diary-anniversary': essentially replace `diary-sexp-entry'.
That's at least one less layer.

I can get rid of the check for `original-date', but I'd still like to
know if we're in a calendar-marking situation vs a listing-the-diary
situation: how else would I do that?

Thanks again,
Eric