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

And, because I apparently have nothing else to do on a weekend, here's a
version that just calls a function directly, nothing fancy. Some overlap
with `diary-anniversary', but nothing terrible. This is probably the
best approach.