When an event that is (or would be) included in a group's /events is added, removed, or modified, announce it in the group

[nmlorg]

I've noticed twice in the past week or so a bot posting its daily announcement and a group admin either sending a followup message with a correction or just manually issuing /events after the next hourly sync.

One possibility would be for the bot to keep track of the messageid of its most-recent events dump (either manually or by daily announcement) and simply edit the message if its content would now be different. (Potentially this could just be a message edit for every group every bot is in, updating whatever the most-recent events dump is, even if it's months old. Or it could keep track of the time as of the dump and re-run the dump as of that time, to keep the intent the same but reflect changes to the calendar.)

Instead of or in addition to that, the bot could also (still keeping track of the message id) send a new message in reply to its events dump calling out the change, either in text like "An event has been added/updated/...:" and just the updated info, or just the updated event's full info, or even the entire /events dump again.

[nmlorg]

Possible [initial] implementation:  Entirely within events (ignore #67 for now, focus just on daily announcements), keep a table mapping bot, groupid -> now, events. (Maybe persist this to disk, maybe just initially live with it resetting on bot restart.) During events.modinit._hourly, re-run _get_group_events (modified to accept now from the caller) for every bot/group combo. (Maybe consult persistence table also/instead?) If events has changed, do either in-place edit (preserving the original preamble), re-announce (with "something has changed" preamble), or in-place edit with a new "something has changed" message as a reply to the now-updated announcement.

For #67, we can potentially store the whole msg in addition to msg.reply's response (containing the id), and have events' various entry points store data like the raw events list and original now as extra attributes on msg.

[nmlorg]

I think I favor the idea of editing the original announcement. It might be confusing to some people if data they had seen earlier changes when they consult it later (which might suggest preserving the preamble but appending an "edited at XXX" to the end), but, especially for very busy groups, it's possible some people may have learned when the bot does its announcement and jump right to that time, and would miss a separate "something has changed" message. (It might even be worth having the "last edited XXX" notice be a link to the "something has changed" message?)

So this might look like:

8:00 <bot> 
 There's an event coming up:

 XXX
8:01 <user>
 That will be a fun event

...

8:00 <bot> · edited 9:00
 There are a couple events coming up:

 XXX
 YYY

 [Updated at 9:00]
8:01 <user>
 That will be a fun event
9:00 <bot>
 > There are a couple ...
 An upcoming event was just added:

 YYY

(assuming we want to be smart about calling out updates versus additions versus removals; there's also a question as to whether a change to an event's description, which is currently not visible in group chats (including daily announcements), should trigger an update announcement).

[nmlorg]

I have a basic implementation ready to go, but right now it'll trigger an update announcement whenever the interval label ("2 weeks on Fri...", "1 week on Fri...", "TODAY, Fri...", etc.) changes (which would mostly be a problem on TODAY/TOMORROW/YESTERDAY changes). I could pass now through about 4 layers of calls to keep that preserved properly, or do something like strip everything between the </b> and first , or something, but it might actually be worth rearchitecting it to preserve (and trigger changes based on) not just just the underlying (unformatted) event data, but actually use that opportunity to include the event description in what's triggered.

This leaves a question of whether the "Update:" message should actually include the updated event's description, or just call out when it's changed (since it otherwise would appear like noise).

Also, just another thought, my current implementation just looks for entries that difflib.ndiff marks as changed to include, silently stripping off the leading '+ ' or '- ', but it might be worth actually tracking if there are any pluses or minuses and using 'Update:' if there are both, 'New event:' if just pluses, etc.