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

[Eric Abrahamsen]

On 08/15/21 07:28 AM, Eric Abrahamsen wrote:
> 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.

Just for fun, here's a version with closures. The need for
`calendar-dlet' (or something that does that job) is unfortunate, and
maybe sufficient argument for writing my own version of
`diary-anniversary'. But this was a fun experiment in understanding
lexical binding and closures.

ebdb-diary-closures.diff
Description: Text Data