From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add notifications.el Date: Thu, 10 Jun 2010 08:33:46 +0200 Message-ID: <201006100833.47436.tassilo@member.fsf.org> References: <1275757657-15244-1-git-send-email-julien@danjou.info> <87631rzzxd.fsf@keller.adm.naquadah.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276151726 27989 80.91.229.12 (10 Jun 2010 06:35:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 Jun 2010 06:35:26 +0000 (UTC) Cc: Julien Danjou , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 10 08:35:24 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OMbMI-0001vG-Eh for ged-emacs-devel@m.gmane.org; Thu, 10 Jun 2010 08:35:22 +0200 Original-Received: from localhost ([127.0.0.1]:58006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMbMH-0002kH-KP for ged-emacs-devel@m.gmane.org; Thu, 10 Jun 2010 02:35:21 -0400 Original-Received: from [140.186.70.92] (port=40205 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMbKp-00023l-Ln for emacs-devel@gnu.org; Thu, 10 Jun 2010 02:33:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMbKo-0000mQ-17 for emacs-devel@gnu.org; Thu, 10 Jun 2010 02:33:51 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:16371) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMbKn-0000m3-Pj for emacs-devel@gnu.org; Thu, 10 Jun 2010 02:33:49 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 6CC5478A49A5; Thu, 10 Jun 2010 08:33:48 +0200 (CEST) Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14442-08; Thu, 10 Jun 2010 08:33:47 +0200 (CEST) X-CHKRCPT: Envelopesender noch tassilo@member.fsf.org Original-Received: from thinkpad.localnet (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id B632978A4917; Thu, 10 Jun 2010 08:33:47 +0200 (CEST) User-Agent: KMail/1.13.3 (Linux/2.6.34-gentoo; KDE/4.4.4; x86_64; ; ) In-Reply-To: X-Face: `TY6r/ws=N5uqO1E`M=Sups<}n%T[E^o_?MJj< =?iso-8859-1?q?O4j=265ljV6lU=7DcXU7oftH=26/x=5F=7EK=7B=26zv9=7D=0A=09sB?= =?iso-8859-1?q?=7D5/Ea=5BhU=7BCS=23=3F=3F0=3F=3Fn?=@sX+ft]?{(l?, mp"a`u List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125697 Archived-At: 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