Re: [PATCH] Add notifications.el

[Tassilo Horn <tassilo@member.fsf.org>]

On Thursday 10 June 2010 02:26:12 Stefan Monnier wrote:

> >> Just so I understand better the trade-off: what would it take to pass
> >> `id' to the on-close function?
> [... sample patch ...]
> 
> So it seems it's very straightforward.  Now, not having used anything
> closely (or even remotely) related, I don't have a good feel for
> whether that would be very useful.  So if someone else could help us
> make a choice, that would be good.

At least for my usecase, the backquoted lambda is even better than
having the id passed to the function.  In the latter case, I'd have to
search the hashtable for a value.

But I'm sure passing the ID to the function is good, too.  It seems to
me that the current approach is a good fit if the caller of
`notifications-notify' wants to control what to do on actions or close.
If you want to create a more generic wrapper around
`notifications-notify' in which you want to implement some default
behavior (like don't show dismissed notifications in the future), then
passing the ID would be more flexible, because there are no requirements
on the caller.

Currently I only have one caller (org-mode events triggering appt.el
appointments), so there's no immediate benefit here.  But I'm also in
favour of doing that interface change now, so long as only few people
are using this facility.

Bye,
Tassilo