From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Error handling in notifications-notify (was: Proposed changes to gnus-notifications.el) Date: Sun, 21 Jul 2019 16:55:33 +0100 Message-ID: <87h87fjsay.fsf_-_@tcd.ie> References: <87y30s5hv4.fsf@tcd.ie> <87blxnke8f.fsf@gmx.de> <87wogbraj0.fsf@tcd.ie> <87wogbisby.fsf@gmx.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="207432"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Julien Danjou , Lars Ingebrigtsen , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 17:55:48 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hpEBg-000rtC-7k for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2019 17:55:48 +0200 Original-Received: from localhost ([::1]:56566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpEBf-0003wb-2W for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2019 11:55:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54494) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpEBW-0003wJ-Bs for emacs-devel@gnu.org; Sun, 21 Jul 2019 11:55:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hpEBV-0005mH-1Z for emacs-devel@gnu.org; Sun, 21 Jul 2019 11:55:38 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:33383) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hpEBU-0005m0-Pe for emacs-devel@gnu.org; Sun, 21 Jul 2019 11:55:36 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id h19so27059679wme.0 for ; Sun, 21 Jul 2019 08:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=cT1FKvgXFCXbEv522PfUnNyB7JEHjkxpL/ZsQtBIsIw=; b=WQd3FcsJCEJsKNidkUI7Z8ZukNAam5jKbmD6W09unwV6nqOeVse5NarNdeFORGyLrC C/Va3Xe/6M0LlZhdce4LXPanzAoYAb6fg9FMYTNrxWekmTgLY3mGzBtbUODR7qcTMBlR 1rsO9gITzog/Jh+KzVL18bHTwQq00jEuBHWQLCJ9aos9D67/aUyiV68RVO0Q8wqhLHpp WXvNfgLzLIlA8ETa2Z1BpA7jPsuB6lZLo79jdGhMXfPkdEpimnuQv9FRnBP5fJEpTcZT IRiOgTyzf+dBdiviPmnt/nVwY2IQ+KmibxyzpGUUjADv/dyc37nSabyQ06CW+dOiAZk4 EC5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=cT1FKvgXFCXbEv522PfUnNyB7JEHjkxpL/ZsQtBIsIw=; b=OVDtx5Auqn9EM9NUOAnguzY5QR/qlfH6fOx+AjkEU07HmktJeDo7YJq88yuD9ofHU4 9jIxel2mSPMbL4F197Ydefd5nZW4epF6M9QfeAgO6hWqs7ViCweknZt6wGBl54qYcNB6 R9F6APp/hLxcqz6eq+DARtHO3Fgdz2QAr4d1UJddC2/uX13GOB5ZLgrXH04ibll9l8R2 KUy97wm1ccnx2OVrMlbFoSjnxTMJN40vsX7o7lu6bArZwg2U1b7ffSNDg0ZGVN1peFqL 7WZsugkSaZhk3Ax1neoWqGXBLwKQfblhxg1K4/jgN6btSrRcGedF3QRWJnPfFWRwtNjK o5Ww== X-Gm-Message-State: APjAAAX3lGAx1XTWipGUAJipSRxjXXZuwYNLDUn0Ds9dYTNKOjOF8lky M3qu4uNMgTBvZcmA+hklcgj6Dw== X-Google-Smtp-Source: APXvYqwL3Hka6W7BQUPe6yGQSu50XGw/4PaFGdvSjAZkaMTxubfqWC3uD2LofV4GpQfIPu0SePuxww== X-Received: by 2002:a1c:5f09:: with SMTP id t9mr62312335wmb.112.1563724535542; Sun, 21 Jul 2019 08:55:35 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:92bd:1bfd:38fc:fae2]) by smtp.gmail.com with ESMTPSA id t13sm44566700wrr.0.2019.07.21.08.55.34 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 21 Jul 2019 08:55:34 -0700 (PDT) In-Reply-To: <87wogbisby.fsf@gmx.de> (Michael Albinus's message of "Sun, 21 Jul 2019 12:40:17 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::334 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238771 Archived-At: --=-=-= Content-Type: text/plain Michael Albinus writes: > "Basil L. Contovounesios" writes: > >> What is the best way to determine whether notifications are supported by >> the current Emacs instance? I skimmed through (info "(dbus) Top") and >> (info "(elisp) Desktop Notifications"), as well as through the syms of >> dbusbind.c, dbus.el, and notifications.el, but did not find any clear >> answers. > > (featurep 'dbusbind) > > checks, whether Emacs is configured to use D-Bus. This does not > necessarily tells you that notifications are supported, but it gives you > a strong indication for this. Thanks, I somehow missed this check littered all over the place. > You could also wrap the call of notifications-notify by dbus-ignore-errors. > > A better check would be to ping notifications-service, but this should > be done inside notifications.el, if needed. Indeed, these two alternatives sound like the responsibility of notifications.el, not its users. The patch I proposed does not change existing behaviour of gnus-notifications.el in this regard. However, I'm not sure what the best thing to do in notifications-notify is. So far, it has returned nil for any type of error (unless debug-on-error is non-nil), thanks to its use of with-demoted-errors. Would it be too backward-incompatible to change this to dbus-ignore-errors or pinging notifications-service, as you say? If so, how's the following docfix instead? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Document-value-of-notifications-notify-on-failure.patch >From 72e45056209f79d1a944ae7810b831cfc62f9d49 Mon Sep 17 00:00:00 2001 From: "Basil L. Contovounesios" Date: Sun, 21 Jul 2019 15:09:54 +0100 Subject: [PATCH 2/3] Document value of notifications-notify on failure * doc/lispref/os.texi (Desktop Notifications): * lisp/notifications.el (notifications-notify): Document return value of notifications-notify on failure, e.g. when D-Bus support is not available. --- doc/lispref/os.texi | 25 ++++++++++++++----------- lisp/notifications.el | 11 +++++++---- 2 files changed, 21 insertions(+), 15 deletions(-) diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index fef954eb7a..bc01f3722f 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -2644,22 +2644,25 @@ Desktop Notifications Which parameters are accepted by the notification server can be checked via @code{notifications-get-capabilities}. -This function returns a notification id, an integer, which can be used -to manipulate the notification item with -@code{notifications-close-notification} or the @code{:replaces-id} -argument of another @code{notifications-notify} call. For example: +If successful, this function returns a notification ID, an integer, +which can be used to manipulate the notification item with +@code{notifications-close-notification} or as the @code{:replaces-id} +argument of another @code{notifications-notify} call. Otherwise, if +sending the notification failed, this function returns @code{nil}. +This may happen when D-Bus or notification support is not available, +for example. + +Here is an example demonstrating the use of action callbacks: @example @group (defun my-on-action-function (id key) (message "Message %d, key \"%s\" pressed" id key)) - @result{} my-on-action-function @end group @group (defun my-on-close-function (id reason) (message "Message %d, closed due to \"%s\"" id reason)) - @result{} my-on-close-function @end group @group @@ -2667,15 +2670,15 @@ Desktop Notifications :title "Title" :body "This is important." :actions '("Confirm" "I agree" "Refuse" "I disagree") - :on-action 'my-on-action-function - :on-close 'my-on-close-function) + :on-action #'my-on-action-function + :on-close #'my-on-close-function) @result{} 22 @end group @group -A message window opens on the desktop. Press ``I agree''. - @result{} Message 22, key "Confirm" pressed - Message 22, closed due to "dismissed" +A message window opens on the desktop. Press @samp{I agree}. + @print{} Message 22, key "Confirm" pressed + @print{} Message 22, closed due to "dismissed" @end group @end example @end defun diff --git a/lisp/notifications.el b/lisp/notifications.el index 1d250e2d92..241f127b11 100644 --- a/lisp/notifications.el +++ b/lisp/notifications.el @@ -198,10 +198,13 @@ notifications-notify Which parameters are accepted by the notification server can be checked via `notifications-get-capabilities'. -This function returns a notification id, an integer, which can be -used to manipulate the notification item with -`notifications-close-notification' or the `:replaces-id' argument -of another `notifications-notify' call." +If successful, this function returns a notification ID, an +integer, which can be used to manipulate the notification item +with `notifications-close-notification' or as the `:replaces-id' +argument of another `notifications-notify' call. Otherwise, if +sending the notification failed, this function returns nil. This +may happen when D-Bus or notification support is not available, +for example." (with-demoted-errors (let ((bus (or (plist-get params :bus) :session)) (title (plist-get params :title)) -- 2.20.1 --=-=-= Content-Type: text/plain >> Currently, gnus-notifications.el checks a) directly whether >> notifications-notify is fboundp, and b) indirectly whether >> notifications-notify returns nil. Even without notification support, >> (a) should always be true after loading the library, right? So the >> question is whether (b) is a sufficient condition. >> >> PS Should gnus-notifications.el be extended to support >> w32-notification-notify? >> >> PPS Would it be possible/welcome to provide a common interface for both >> notifications-notify and w32-notification-notify? At the moment it >> sounds like programmers need to choose between the two depending on >> system-type. > > In ELPA, there are several notification libraries. alert.el seems to be > the most advanced one, although it doesn't support w32-notification-notify. Indeed, and it isn't in GNU ELPA either, though I seem to recall its inclusion being discussed somewhere. Thanks, -- Basil --=-=-=--