[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add notifications.el

From: Tassilo Horn
Subject: Re: [PATCH] Add notifications.el
Date: Thu, 10 Jun 2010 08:33:46 +0200
User-agent: KMail/1.13.3 (Linux/2.6.34-gentoo; KDE/4.4.4; x86_64; ; )

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]